iphone5型号是MD657LLA 序列号F18JP3WPF8GJ求激活时间,是否翻新机?

iphone5型号是MD657LLA 序列号F18JP3WPF8GJ求激活时间,是否翻新机?,第1张

激活信息

最近一次激活时间 2013-02-19

首次激活时间 2013-02-19

设备信息

产品型号 IPHONE 5 16GB 白色

产品序列号(SN) F18JP3WPF8GJ

出厂日期(参考) 2012-11-18 ~ 2012-11-24

iOS版本 6.0.1

保修信息

购买时间 2013-02-17

过保时间 2014-02-17

剩余保修时间 360 天

保修状态 有限保修

激活状态 已激活

注册状态 已注册

电话支持 过期时间:2013-05-19

延保状态 不符合AppleCare延保条件

*************************************

恭喜你了!全新正品!

糯米手机团为您提供最详细、最全权威的信息

*************************************

温馨提示:

百度搜索“苹果园查询”,进入后输入序列号即可查询。

通过手机选择:设置-通用-关于本机可察看型号(即销售地区或是版本号)。

最后两位:CH是国行,ZP是港版,LL是美版, ZA新加坡,TA是台湾,KH是韩国,

最后一位:B是英国,C是加拿大版,X是澳洲版,F是法国版,J是日本

新机激活当天开始算90天免费电话正冲指售后服务支持举配和一整年保修。

祝你新年快乐~

请点击我的回答下方【选为满意答案】按钮,你的采纳是我们回答的动力!判晌

其实这跟tabControl样磨凳式无关,跟tabItem样式有关。tabControl只是用来放tabItem和内容的容器。

用blend打开TabItem模板。去掉border的margin。去掉一些不必要的瞎高旅trigger值。调整下tabitem的padding属性使得留余地给三角。

假设

<Setter Property="Padding" Value="6,1,6,10"/>

然后在Grid里面加一个Pah

<Grid SnapsToDevicePixels="true">

<Border x:Name="Bd" BorderBrush="{TemplateBinding BorderBrush}" Background="{TemplateBinding Background}" Padding="{TemplateBinding Padding}">

<ContentPresenter x:Name="Content" ContentSource="Header" HorizontalAlignment="{Binding HorizontalContentAlignment, RelativeSource={RelativeSource AncestorType={x:Type ItemsControl}}}" RecognizesAccessKey="True" SnapsToDevicePixels="{TemplateBinding SnapsToDevicePixels}" VerticalAlignment="{Binding VerticalContentAlignment, RelativeSource={RelativeSource AncestorType={x:Type ItemsControl}}}"/>

</Border>

<Path x:Name="triPath" Data="M49,34 L56.5,16.5 64.5,33.5" Fill="blue" Visibility="Collapsed" HorizontalAlignment="center" Stretch="Fill" Stroke="Black" Width="20" Height="10" VerticalAlignment="Bottom"/>

</Grid>

最后在<Trigger Property="IsSelected" Value="true">念启里加

<Setter Property="Visibility" TargetName="triPath" Value="Visible"/>

WTL都算不上什么Framework,就是利用泛型特性对Win API做了层封装,设计思路也没摆脱MFC的影响,实际上用泛型做UI

Framework也只能算是一次行为艺术,这个思路下继续发展就会变得没法用了,比如 代码过于复杂,编译太慢,出错不好调试等问题难以解决。

而且封装得也不完全,还是随处仿铅可见 HWND HDC之类的东西。

用途主要是写一些很小的程序,或者作为其他UI框架的后端实现部分,比如我写过一个小框架用来做安装卸载程序,非常小,其中创建管理窗口部分是用WTL的。

MFC

是更高级点的Win API封装,比WTL封装彻底,很难见到HWND

HDC了,也提供了不少实用工具类,比如高级控件,泛型容器,IO访问,网络协议等。除此之外,还提供了一些基本框架,比如

Document/View,这就是个MVC的简化版本,只有MV,但是对于数据的管理,消息的传递等又没有什么约束,导致Doc/View被用得乱七八

糟。尤其是对事件处理的模型,消息映射是功能简陋,而且容易出错的方式,唯一优点是性能好。 从VC++

1.X就有MFC了,那时整个UI界的设计思想都比较落后(除了Apple),MFC又背负了沉重的兼容性包袱,比如vc++

1.52的MFC程序到了vc2003稍加修改都可以编译,导致MFC后期没有什么发展,就是沿着老的思路完善了些细节,添加了些组件,但是根本性的设计

问题没有改进。

GTK,这个吃了语言的亏,用C写面向对象实在是痛苦,虽然在思想上比MFC要先进了些,但是写出来的代码比MFC要罗嗦很多了。相比MFC,多了Layout的概念,事件处理上有了Signal/slot,虽然用起来很麻烦孝大如。

wxWidgets,

这个基本就是个跨平台的MFC,对各个平台的差异做了抽象,实际上后端大多还是用平台原生的API实现,好多控件都是直接用系统原生的。有

wxWidgets for

GTK+的版本,后端就是GTK+,wxWidgets就是一层壳。这也是wxWidgets的优点,它编译出来的程序发行包比较小,性能也不错。

以上这些就是上世纪90年代的UI Framework技术水平了,至今它们也依然没有太多进步。

下面来巧启谈谈21世纪的技术。

Qt,

虽然它也是上世纪90年代出现的,但是它在21世纪有了长足的进步。应该说它的起点就比较高,一开始就定位跨平台,而且不满足于简单封装系统API,而是

要自己创造出一套完整的API和框架,甚至要代替系统API,所以不仅仅是做UI,而是涉及到了APP开发所用到的所有东西,包括网络,数据库,多媒体,

脚本引擎等。signal/slot是Qt发明的,这是事件通知模型里C++语言的最佳实现了,甚至我都觉得这该写进C++标准,估计C++委员会的老顽

固们是从不写GUI的。

早期的QT也是没有DirectUI的概念的,每一个QWidget都对应一个原生窗口,从Qt4.4开始,只有顶层

QWidget才是原生窗口,而Child Widget是Alien

Widget,只是个抽象的图层不对应原生窗口,这就实现了DirectUI的概念,很多图形效果也就变得可能了,比如窗口层叠透明效果。

在4.8后实现了QPA(Qt Platform Abstraction),这就使移植Qt变得很容易,目前Qt是支持平台最多的框架没有之一。

由于早期授权的问题,Qt对于开源社区不是很友好,导致推广不太顺利,直到它改成了LGPL方式,如果Qt能早点想开了,恐怕就没有wxWidgets的生存空间了。

Qt的缺点也是有的,就是太大,不过可以自己剪裁,我可以把QT库剪裁到发行包压缩后2.5MB。

WPF,

微软在Win

Form的思路上走到死胡同后,终于痛下决心用正确的方法开发UI库了。21世纪的UI一定是定义出来的,绝对不能是代码写出来的,所以有了XAML这个

强大的定义工具,不但可以定义UI布局,还包括图形动画效果,消息响应方式等。配合C#这种优秀的语言,更是如虎添翼。但是问题也很明显,就是过于庞大,

不仅开发时要用到庞大的IDE和设计工具,发行的安装包也十分巨大,所以目前还是很少有人拿他写通用软件客户端的,大多是做企业项目时写专用客户端。

大概4-5年前吧疼讯曾经用WPF写了个QQ,但是只实现了基本功能就已经比C++客户端大好多了,而且运行缓慢,主要是太吃内存,而且那时WPF的优化还不充分。

最后我想补充下真正的UI库之王,cocoa。

Apple的成功有很多原因,其中之一就是cocoa,cocoa理念十分先进,而且出来得早,我都怀疑Qt和WPF有不少思想都是借鉴cocoa的。

定义式的UI,用xib就可以定义UI的绝大部分细节,而且提供所见即所得的可视化设计工具。

严格的MVC,而且定义非常清晰,分工明确。

signal/slot,虽然不叫这个名字,但思想就是,而且真的是拖动鼠标就能connect。

提供了ARC,闭包和反射,给UI开发带来巨大的便利性,当然这得益于Objective-C这个语言。

再补充下 Borland的OWL和VCL。

我是从Borland C++3.0和Delphi 1.0开始用的,那时的Borland看来很有前途的,可惜后来一系列决策失误导致现在这个公司几乎消失了,同学们不要再往这个坑里跳了。

OWL曾经和MFC是竞争对手,设计思想也差不多,个人感觉OWL的API设计更优雅一点,但是在市场上OWL被MFC彻底击败。

Delphi

是神作,它在RAD(快速应用开发)领域长时间没有对手,直到BS架构取代CS架构。Delphi的特点就是简单、开发快,单纯就写个基本可用的应用来

说,可能至今都没有比他更快的,但是缺点就是丑,基本大多数Delphi应用都是一大堆控件堆积在一起,很不美观,另外由于Pascal语言的限制无法和

现有大量的C/C++代码融合。虽然后来有C++

Builder,但是Builder里简单和快的优点也消失了。Borland的C++编译器越做越差,导致后来开源项目都不太愿意兼容这个编译器了。

VCL准确地说不是UI库,而是一套组件接口规范,类似COM ActiveX。delphi和C++builder都是基于这个规范构建了基础库。

UI库是个很大的话题,够写好几本书来探讨的,我这里就是随便写点自己的感受。

单纯讨论每个库的优劣是没有意义的,而是要放到具体的应用场景里来看,每个库都有自己擅长的场景。

如果仅在Windows下,追求程序小巧,用WTL,不足的地方自己实现去吧,但是视觉效果就呵呵了。

如果可以大一点,还要好看点,那就Qt。

如果完全不在乎大小,只要视觉效果华丽,就用WPF,如果把开发工具价格也考虑进来,那么土豪才会选WPF呢。

MFC就是个鸡肋了,除非你现有的工程师不会用别的,或者有历史遗留代码要保持兼容。

如果要求跨平台,那么就用Qt,wxWidgets和GTK+跟现在的Qt比起来没有什么优势了。

如果是iOS Android,那么最好用原生UI库,除非你写游戏。


欢迎分享,转载请注明来源:内存溢出

原文地址: http://outofmemory.cn/yw/12450379.html

(0)
打赏 微信扫一扫 微信扫一扫 支付宝扫一扫 支付宝扫一扫
上一篇 2023-05-25
下一篇 2023-05-25

发表评论

登录后才能评论

评论列表(0条)

保存