软件业发展到今天，我们的用户早已不满足简单的界面。于是，一部分软件设计师便以UI设计师的身份从开发人员的队伍里分化出来，他们借鉴消费心理学的经验，就像走在夜都市的绚烂街道上，就像陶醉在超市里花花绿绿的货架前，通过精心设计，使软件产品在展示屏幕前，带给人们瞳孔放大的强烈视觉冲击力。
对于VFP无法支持基于子窗体设计原理来实现的流行Skin的情形，使得不少程序员伤透了脑筋，伴随过无数个失眠的夜晚。原因是VFP的控件是“自绘”的，而不是象其它的开发工具那样从MicroSoft Common Controls Libs里调用基于子窗体风格的控件。
为什么会这样呢?为了解开答案，我们就必须了解历史——Foxpro for Windows及Visual Foxpro开发小组的产品架构理念及设计思想。
自从MircoSoft买断Foxpro1.0后，一方面为了保护原用户，另一方面为了与Borland的dBase相竞争，Dos时代下的Foxpro所有版本，都具有相应的跨平台版。
当历史的步伐迈入图形操作界面的产品时代后，VFP依然有Macintosh操作系统版，这一传统一直保持到VFP6.0。当年，Excel作为先驱，是Microsoft的第一个支持苹果公司的Macintosh操作系统的产品。与地球史上任何先驱一样，Excel付出了惨痛的代价。
并不象盖茨当初想象的那样：Excel for Windows在经过简单有效的修改后，就能运行在Macintosh操作系统中的。最后的结果是：程序员为此修改了95%的代码!
在随后的版本中，都需要修改65%左右的代码来完成for Macintosh，使得微软最后不得不放弃Excel for Macintosh版。
在Microsoft的图形界面操作领域里，Foxpro与微软其它开发工具所不同的是，由于历史上广积的用户善缘、以及来自dBase的竞争，使它必须要有for Macintosh版。一方面，Fox作为内镶数据库操作引擎性质的产品，它的几乎所有常用的控件，必须要配备数据、数据字段捆绑的相应属性。而MicroSoft Common Controls Libs里的控件，不能满足要求。
另一方面，FoxPro开发小组借鉴了Excel的历史教训，为了尽量减少跨平台代码修改的工作量，他们选择开发了“自绘”的界面控件。所谓“自绘”风格的控件，就是把MicroSoft Common Controls经过相应的修改，直接内嵌到自己的动态解释库中。这样做的优点是：1、由于不依赖于Common Controls Libs，能使往后的VFP版本升级工作变得简单灵活，也让用户的应用产品发布工作没有冗余的负担;2、从可视化的角度上看，For Windows与For Macintosh没有什么不同，开发人员可以在Windows(或Macintosh)中开发产品，然后发布到Macintosh(或Windows)中去，界面的样式不会有什么改变。这在当时(网络时代没有兴起时)几乎是完美的设计理念，没有任何的缺点。我们甚至看到，这一设计方案比同时代的Java(每个操作系统界面都不同)要高出不少。可是Internat的飞速发展，促使用户界面的概念不断推陈出，VFP为此而付出了史料未及的代价!
我们知道，对于一个Skin开发人员来讲，他必须要精懂MicroSoft Common Controls的设计和开发原理、Windows操作系统底层原理、消息机制、Windows APIs、C\\C++，纵然具备这些能力对于常人来讲是相当困难的，但是其回报也是成正比的，因为他们的Skin产品可以在多种开发工具开发出的产品上通用。
然而VFP却缺少这样的人才——为了支持VFP“自绘”风格的控件，必须要以VFP的代码来重写Skin。三个原因在妨碍他：1、他的代码是基于脚本性质的VFP代码，就没办法通过发行通用产品的方式来挣钱——代码会被反编译，无法保密;2、除了具备正常Skin开发人员的能力外，他不仅要精懂VFP，更要深刻理解VFP产品本身的关于可视化层面的底层设计原理;3、市场小。
对于普通VFP程序员来讲，如果想要美化自己产品的界面，可以采用美观整体布局的方式来掩盖局部控件的丑陋，通过合理的配色方案、界面布局的人性化等，将用户的眼球更多地吸引到整体的视觉效应里，尽量避免出现局部粗陋控件的视觉反差。
对于公司来讲，世上具备Skin开发能力、又具备UI设计能力、还精懂VFP底层的人员真是少之甚少，如果遇到了，应珍惜机遇，与其合作。
