VCL已死,RAD已死
——SD2C中未能尽言的话题
<<<-- 上一节
这个插播,是Shaofei Cheng在MSN跟我的一段聊天记录。关于这个话题,我在会后休息的时
候,与很多朋友都谈到过,但限于现场,无法记录。正好Shaofei Cheng与我又一次沟通了这
个,得以形成记录,也能反映一些我在“VCL已死,RAD已死”这个论题中有关架构的思想。故
此公众,大家可以狂批……
建议整篇文章从头读起,在这里在这里 -->>>
Shaofei Cheng 说:
UI设计师设计了界面,然后开发人员说:荒唐!这样的界面用Delphi根本做不出来!
Shaofei Cheng 说:
我觉得这段蛮有意思
Aimingoo 说:
是啊,真的常常这样。
Aimingoo 说:
在WIMP模型上做UI是受限的。而在块+层的模型上做,跟PS的实现过程非常接近,所以基本
就不受限。
Aimingoo 说:
这个,才是WEB UI流行的根本原因之一。当然,WEB自己的力量也是原因之一。
Shaofei Cheng 说:
我觉得没有做不出来的界面 只有工期内做不出来的界面
Shaofei Cheng 说:
所以最后程序员能做出来的界面 是和底层依赖的库/开发工具/框架关系很大的一个范围
Shaofei Cheng 说:
我一直觉得这一点很有问题的
Aimingoo 说:
是的。
Shaofei Cheng 说:
很多人都感叹 要是能同时用prototype和Jquery多好
Shaofei Cheng 说:
有些问题在prototype里面一句话就解决了 有些问题在Jquery里只要几个字母
Aimingoo 说:
哈哈哈~~
Aimingoo 说:
不需要,在我看来,应用逻辑的开发人员,与UI及控制逻辑的开发人员应该是两个。
Aimingoo 说:
如果是一个,这个人就得向superman靠齐。
Shaofei Cheng 说:
嗯
Shaofei Cheng 说:
关于这个 不知道你了解过WPF的开发模式没有
Shaofei Cheng 说:
VisualStudio + Expression Blend
Shaofei Cheng 说:
VisualStudio给程序员用
Shaofei Cheng 说:
Expression Blend给UI Designer用
Shaofei Cheng 说:
我猜你会有点兴趣
Aimingoo 说:
我了解过。。。
Aimingoo 说:
后来还提到了。只是你没明白 ,我认为这样根本解决不了问题。
Shaofei Cheng 说:
哦?
Shaofei Cheng 说:
你怎么看呢?
Aimingoo 说:
横向分层,划分领域。
Shaofei Cheng 说:
界面和程序分开么?
Aimingoo 说:
是。
Aimingoo 说:
真正、彻底地分开。
Shaofei Cheng 说:
那么现在WPF已经是这样了
Shaofei Cheng 说:
XAML是由UI Designer出的
Aimingoo 说:
但是,在没领域的情况下,用WPF+分层思想做产品的仍然是同一个或同一批人。
Aimingoo 说:
这是提高不了效率的。
Aimingoo 说:
这篇文章有三节,你看了几节了?
Shaofei Cheng 说:
都看了
Shaofei Cheng 说:
感觉不是特别catch你的观点
Aimingoo 说:
你应该去了解一下,有几个UI设计师是用Expression Blend的?有几个是了解XAML的?
Shaofei Cheng 说:
呃 我们Team现在的UI......
Shaofei Cheng 说:
被逼迫着学呢
Aimingoo 说:
在一个使用了Expression Blend的团队中,UI设计师在哪里?在不在团队里?
Aimingoo 说:
他与团队是什么关系?
Shaofei Cheng 说:
在团队里啊
Aimingoo 说:
如果UI设计师被逼迫着放弃PS,而使用EB,你应该这是合理的吗?你认为开发人员团队,对
UI设计师称“他们”,是合理的吗?
Aimingoo 说:
不对的。UI设计师应该是我们,是与开发人员在一起的一个团队成员,是一个体系下的。而
且,他们应该使用不同的工具,使用不同的语言交流交互。
Aimingoo 说:
没必要要求他们在工具上趋同。关键在于他们如何配合,而不是是否使用相同的工具。
Aimingoo 说:
在盛大,设计师是在“设计中心”的,而开发人员是在“技术中心”。所以,事实上在某个
具体团队里,设计师是“外来户”。
Shaofei Cheng 说:
然而工具总是必须一致的
Shaofei Cheng 说:
就好像我们现在的Team 开发必须用VS一样
Aimingoo 说:
哈哈~~
Aimingoo 说:
Team为什么“必须”用VS呢?
Aimingoo 说:
是team的需要吗?或是公司高管们需要?
Shaofei Cheng 说:
因为要协同工作
Aimingoo 说:
给你们选择,如果能有自主的环境,你们是否一定会选择VSTS
Aimingoo 说:
协同的是人,不是工具。工具只是辅助来做这件事的。
Aimingoo 说:
我们可否有别的选择?
Aimingoo 说:
一个例子是,你让UI设计师如何用VSTS来跟“你们的”团队协作?
Shaofei Cheng 说:
嗯 可是Team必须在某些东西上统一
Shaofei Cheng 说:
你没法追求绝对自由
Shaofei Cheng 说:
比如假如一个Delphi团队里我突然说 我想用C++
Shaofei Cheng 说:
这是不可能的
Aimingoo 说:
你误会了我的意思。。。。
Aimingoo 说:
我那天在会场里讲,我说:混合语言的真实意义,不是在于让Delphi里面能用上内嵌汇编,
或用上C的二进制对象文件。这个是早期的混合语言开发。
Aimingoo 说:
这种混合语言,是以个体开发为核心的。
Shaofei Cheng 说:
嗯
Aimingoo 说:
我所讲的混合语言,是在领域分层上,在不同的层次上用不同的、最适合的语言来开发。
Aimingoo 说:
我看到的,例如UI上,我们用JS+DHTML或Flash来做,我们使用这种环境下最适合的开发工
具;在客户端,我们选Delphi,当然如何你的团队擅长VC,没关系,用就好了;
Aimingoo 说:
在服务器端,我们用Erlang,或是python,ruby。没关系,用就是了。
Aimingoo 说:
我们要把这三种不同的角色混合在一个团队中——解决一个大型体系的团队中,这才是混合
语言开发:在不同层面上使用最佳的方案。
Shaofei Cheng 说:
Markup+ Scripting+ Programming?
Shaofei Cheng 说:
你是指这种结构?类似这种的切分么?
Aimingoo 说:
不是确定的语言结构“Markup+ Scripting+ Programming”,而是层次隔离的思想。
Shaofei Cheng 说:
嗯
Shaofei Cheng 说:
我就是说 类似于这种的切分方式
Aimingoo 说:
对的。
Aimingoo 说:
类似的。
Aimingoo 说:
从架构师的层面上来讲,关注的是某种具体切分的合理性。
Aimingoo 说:
比如你切成“Markup+ Scripting+ Programming”,我就需要考虑markup上是否有合理的表达。
Aimingoo 说:
是否能够能Script交互,是否能够在当前项目中切实可行。等等于此。
Shaofei Cheng 说:
嗯
Shaofei Cheng 说:
那你觉得跟现在WPF做的有何不同呢?
Shaofei Cheng 说:
Markup有可能被替换成某种Binary
Shaofei Cheng 说:
Scripting也可能被替换成某种 Markup
Aimingoo 说:
WPF是要求了团队的结构,或解决方案的单一性。
Shaofei Cheng 说:
WPF应该说是一种具体的解决方案
Aimingoo 说:
我的意见是:用什么(例如WPF/XXX)并不是关键,而是在你决策之前,看看你的团队以及
目标是什么。
Aimingoo 说:
对的,WPF只能说是一个具体方案。而且我个人认为,传统的思想下会导致其成本更高,而
不是更低。
Shaofei Cheng 说:
嗯 取决于使用方式
Shaofei Cheng 说:
如果还是让一个程序员去写XAML 然后再写程序的话......
Aimingoo 说:
对了。从这个角度上思考,你就知道我在想什么了。
Shaofei Cheng 说:
尽管WPF在暗示大家把界面和程序分开
Aimingoo 说:
如果仍然是程度A去写XAML,然后A再去写程序,A再去关心部署,事情就根本上未有变化。
Aimingoo 说:
对了,WPF做了这种暗示,M$也在产品结构上做了调整。但是,商业利益问题决定了他们不
愿意向“开发团队”推动这种思想。
Shaofei Cheng 说:
从language和tool上都在暗示 但它本身并不是一个团队结构的约束
Aimingoo 说:
当一个使用PS的界面设计师进入团队时,他就成了外来户。
Aimingoo 说:
他用既有工具做不了任何事情,用自己的工具,又与团队的模式存在冲突。这是两难的事情。
Aimingoo 说:
真正分层体系上,比如说建筑领域里,砖工与瓦工是分开的,使用不同的工具与技艺,包括
交流的语言。
Aimingoo 说:
但这不妨碍他们在一起建筑。
Shaofei Cheng 说:
这个的话 我觉得是另外一个问题
Shaofei Cheng 说:
任何Team进了新人都会有类似问题
Shaofei Cheng 说:
但是你所说的这个分层 一定要有一个平台来实现
Aimingoo 说:
平台,可以是流程,可以是规则。
Aimingoo 说:
你还是开发人员思维。平台一定是VSTS吗?
Aimingoo 说:
一定是一个工具吗?
Aimingoo 说:
一定是一个软件产品吗?
Aimingoo 说:
平台,就是人+人+人+人~~
Aimingoo 说:
以及其上的一套规则和流程。如同建筑、工地、包工队。
Shaofei Cheng 说:
每一层的产品呢
Aimingoo 说:
对了,“每一层的产品”是个问题。但为什么“每一层的产品”都是M$出的呢?
Aimingoo 说:
M$想做这件事情~~只是他想做而已,为什么最终变成了开发人员的依赖呢?
Shaofei Cheng 说:
问题是 如果这个产品是文档
Shaofei Cheng 说:
一个夸张点的例子
Shaofei Cheng 说:
假如UX出了一份厚厚的 设计说明书 包括颜色、位图、交互的各种说明
Shaofei Cheng 说:
那么开发人员如何去用?
Aimingoo 说:
这是另一个思想。
Shaofei Cheng 说:
不 很相关的
Shaofei Cheng 说:
每一层之间用什么来交换信息 会直接决定这个结构是否可行
Aimingoo 说:
在人月神话里讨论过。
说到A团队与B团队的产品输出,早期的观点是B一定要看到A的全部东西,而后期、以及更合
理的观点是:不要看到A的全部东西,而只是关注如何使用它。
Aimingoo 说:
换言之,你上面的这个列表:厚厚的 设计说明书 包括颜色、位图、交互的各种说明等等,
基本上都不是要给开发人员看的。
Aimingoo 说:
基本上,那是UI设计人员的思想,以及思想的过程。
Shaofei Cheng 说:
对 是和这也也有关系 但是重点在于你提出的问题
Shaofei Cheng 说:
就是分层次解决方案
Aimingoo 说:
一个具体的UI实现者,应该与UI设计者一起工作,实现者问:这里要怎么动?设计者说,慢
慢地,由快到慢地……等等等等。
Aimingoo 说:
UI人员对“快和慢”是一种感觉,你不能要求他把这个写成一个公式或者数字,而且既然这
样做了,终有一天,体验人员会反对。
Aimingoo 说:
所以开发人员只需要在一个阶段满足他(UI设计师)的需要就可以了。通过这种对称的工作,
完成原始的模型,然后进入第一个开发迭代。
Shaofei Cheng 说:
那么 我觉得在你这个例子里 UI设计者成为了顾问的角色
Shaofei Cheng 说:
他的产品是持续供应的语言帮助
Aimingoo 说:
应该是顾问+素材提供者+需求方
Shaofei Cheng 说:
这个有点太具体了 你能让每一层都这样么?
Shaofei Cheng 说:
比如 一个专门作交互的程序员 和做业务的程序员 也如此协做?
Aimingoo 说:
用IVAR的例子,一个“骨架产品”是要花大量时间和交互成本、设计成本来建设的。
Aimingoo 说:
当骨架完成之后,具体施工时就只剩下了规则和具体业务逻辑。
Aimingoo 说:
举例来说,你认为现在城市施工中的“塔笼式建筑”,是一夜建成的么?
Shaofei Cheng 说:
当然我只能回答不是
Aimingoo 说:
当然不是,那是架构师、设计师、工程精英们在几十年的时间里总结出来的。
Shaofei Cheng 说:
赫赫
Aimingoo 说:
在这个框架之下,施工人员们现在只剩下了一套可复制的流程。
Shaofei Cheng 说:
这样的话 我觉得你所说的分层次思想就退化成了一种UX和dev协作方式而已
Shaofei Cheng 说:
我觉得UX需要一种自己的语言 可以被UX和dev接受的
Aimingoo 说:
所以,在我们上面的讨论中,UI设计人员与开发人员之间这种对称的、直接的沟通会发生在
某些原型的、骨架的阶段,但不是所有的阶段。
Aimingoo 说:
>>> Shaofei Cheng 说:
>>> 这样的话 我觉得你所说的分层次思想就退化成了一种UX和dev协作方式而已
这就是你的思想中最关键的逻辑问题了。
Aimingoo 说:
要注意,思想是思想,方法是方法。
Aimingoo 说:
你不能用思想去对等地讨论方法。
Aimingoo 说:
你只能强调:一种UX和dev协作方式,是分层次思想的一种实现方法。
Aimingoo 说:
明白了吗?
Aimingoo 说:
讨论某种实施方法的正确或错误是很简单的事:正确的东西换个背景就错误了。
Shaofei Cheng 说:
嗯
Shaofei Cheng 说:
需要一个具体的场景
Aimingoo 说:
但是,分层的思想,以及清楚地认识到分层思想与纵向切分的不同。
Aimingoo 说:
最后,理解厂商们为什么做现在这些事,以及他们将来会怎么做……这一切与一个具体的场
景是无关的。
Shaofei Cheng 说:
嗯
Shaofei Cheng 说:
但我觉得你说地UX跟dev那种模式并不好
Shaofei Cheng 说:
分层的优势应该是独立工作吧
Shaofei Cheng 说:
我是说 对于分层来说 非常不好
Aimingoo 说:
好,或不好,是要放在场景上去讨论的。
Aimingoo 说:
比如你的观点是基于你的现有工作场景,或工作经历。
Aimingoo 说:
分层的优势,是领域的推动。劣势,是沟通成本的增加。
Aimingoo 说:
层间交互的代价是极高的。必须在一个可以承受这种代码的环境中,才能使用它。
Shaofei Cheng 说:
领域的推动 就是更专业化吧?
Aimingoo 说:
我再举个例子。
Shaofei Cheng 说:
好
Aimingoo 说:
Erlang是用“节点、进程”这样的单位来切分一个项目的。
Aimingoo 说:
进程内,根据Erlang的设计,通过函数界面来交互;进程间,通过消息界面来交互;节点间,
通过端口界面来交互。
Aimingoo 说:
这各级之间的交互成本,是渐次递增的。
Aimingoo 说:
到了节点间交互时,端口交互成本就取决于网络环境。以Erlang早期的应用场景,也就是手
机平台来说,发个短信两分钟后收到,是很正常的事。
Aimingoo 说:
所以节点间交互导致的时延是可以接受的。对吧?
Shaofei Cheng 说:
嗯
Aimingoo 说:
但是,这样的系统不能用在PC环境中,因为如果一个企业的应用逻辑需要2分钟来交互——例
如老板按下一个按钮,要两分钟才反馈,大概是不成的。
Aimingoo 说:
这种情况下,ErLang并不胜任企业级的业务逻辑。尽管它并发、高负载……等等优势,他不
适合就是不适合。
Shaofei Cheng 说:
呃嗯
Shaofei Cheng 说:
然而这是程序间不同层的协作
Shaofei Cheng 说:
不是人之间吧?
Aimingoo 说:
但是,二十年后,环境变了。现在的端口交互的成本越来越低。
Aimingoo 说:
两台机器之间,光纤连接的成本都很低了。一张千兆卡,传输速度远远超过本机的硬盘I/O。
两台机器之间传递数据,比从本地硬盘读数据还要快。
Shaofei Cheng 说:
嗯
Aimingoo 说:
那么,端口交互的成本低到这种可接受的程度,所以ErLang渐渐地就被服务器端开发者们
看好了。
Aimingoo 说:
所以,我说“层间交互的代价是极高的。必须在一个可以承受这种代价的环境中,才能使用
它”。Erlang通过节点来分层,这种思路导致的交互代价可以被接受了,他就被接受了。同
时,他的其它优势才发挥了出来。
Shaofei Cheng 说:
嗯
Shaofei Cheng 说:
great sample
Aimingoo 说:
同样的道理,我现在在讨论我们开发中的横向分层,必须是一个可以接受他的工程环境才能
用的。
Aimingoo 说:
你可用在一个RAD团队中使用横向分层,结果仍然是一个开发人员去做所有层上的事情,他愿
意去做,而且还很Happy。即使如此,他也要有消化层间交互代价的能力,他的项目或团队也
要有这种能力。
Aimingoo 说:
否则还是要做砸锅。
Shaofei Cheng 说:
所以说这个环境很重要
Aimingoo 说:
然而我之视见,我认为,消化层间交互的代价,可能不是一个开发人员能做的,而是领域推
动才能实现的。比如,我们有专业的设计人员,知道如何跟开发人员交互,如何构建原型——
但我要强调,这个设计人员一定不是开发人员!
Aimingoo 说:
只有具有了这样领域能力,他才能在这个团队中工作好。否则,我们就要给出时间,行业也
要给出时间来实现这些。
Aimingoo 说:
就好象在“塔楼式”建筑方式出来之前,我们还得用旧方法造楼一样。
Shaofei Cheng 说:
其实整理一下思路
Shaofei Cheng 说:
我一直在提WPF
Shaofei Cheng 说:
WPF是一个UI和dev协作的环境
Shaofei Cheng 说:
理论上讲 或者这个系统设计的初衷 就是让UX层跟dev层交互的代价变为0
Shaofei Cheng 说:
当然实际上他没有做到
Aimingoo 说:
是。
Aimingoo 说:
而且他还违背了UI设计者的初衷,他必须迁就开发团队地去学习VSTS。
Shaofei Cheng 说:
但是这是一个权衡的问题
Shaofei Cheng 说:
UI设计者被强迫用EB 也是一个限制
Aimingoo 说:
是的。如果这个团队的开发目标,锁定在VSTS可控的范围内,那么这样是可以接受的。
Shaofei Cheng 说:
或者说抛开工具
Shaofei Cheng 说:
UI designer必须提交一份XAML
Shaofei Cheng 说:
XAML工具有不少
Aimingoo 说:
你要具有架构师的思想,你必须认识到VSTS适合不适合,以及UI设计者被强迫用EB正不正确,
是一个具体场景的具体问题
。
Aimingoo 说:
他是一种权衡,这本身不具有正确性。
Shaofei Cheng 说:
嗯
Shaofei Cheng 说:
或者说WPF本身对项目来说是一个选择
Shaofei Cheng 说:
其附带的分层效果只是一个附加工具
Shaofei Cheng 说:
没法因为它的这种能力而选择它是吧?
Aimingoo 说:
我们再举一个例子。我在《大道至简》里面就讲过这个。
Aimingoo 说:
我说,我们的项目总有需求方,从开发人员的角度上来看,我们希望我们的需求提出者使用
C语言来描述它的需要。最好用C给开发人员写个框架。
Aimingoo 说:
对吧。但是,我们知道,我们的需求方大概不会用C,比如大企业的项目负责人,你不可能让
他用C。
Shaofei Cheng 说:
嗯
Aimingoo 说:
于是我们的工程界就说,我们需要一个标准的需求描述语言,例如说UML。这样一来,客户要
会用例图,开发团队(中的设计师)也要能懂它。
Aimingoo 说:
看起来一切美好。然而,客户不会用C,难道他就会用UML吗?
Shaofei Cheng 说:
嗯
Aimingoo 说:
你的问题和这个一样。UI设计师不会用C,难道他就会用XAML吗?
Shaofei Cheng 说:
嗯
Shaofei Cheng 说:
但是团队内和团队外不同
Aimingoo 说:
什么是最简成本的沟通?
Aimingoo 说:
注意,你的目标是UI设计师的设计可以被开发,你的目标仅仅是这个。
Aimingoo 说:
那么沟通的目标,就是“开发者+设计者=一个可开发的产品”。那么让他们去保证这一点好了。
Aimingoo 说:
哪怕拿出来只是一个骨架,只要证明这个骨架可以持续开发就好了。
Aimingoo 说:
完全没必要通过一种XAML来保证。那是极大无聊的事情。
Shaofei Cheng 说:
那么至于究竟开发者去把位图写成XAML 还是UX去把设计写成C 其实只是一个开发时候的协作?
Aimingoo 说:
GOOD!GOOD!
Aimingoo 说:
我终于成功了,这太重要了。你必须明白,那只是开发时协作的一个可选工具!
Shaofei Cheng 说:
假如就有这么个变态UX 喜欢用C写设计 也是可以的
Aimingoo 说:
至于这个协作过程中,是用白板,还是在PS界面上画,或者是别的什么,并不重要啊。
Shaofei Cheng 说:
当时我想说 工具影响成本
Aimingoo 说:
所以,我从来不说我反对XAML,或反对UML。因为那原本就是一种可选工具。他是备选的,所
以我不能否定它。但是,我不能一叶障目地说我必须用它。
Aimingoo 说:
说必须用它的,是M$,是厂商,是业务代表。
Shaofei Cheng 说:
在工具设计者设想的场景中 这个东西保证了可行
Aimingoo 说:
>>> Shaofei Cheng 说:
>>> 在工具设计者设想的场景中 这个东西保证了可行
Aimingoo 说:
我同意。
但,那是他们的预想。
Aimingoo 说:
他们的预想只是一头猪或一群猪的代价。
Shaofei Cheng 说:
比如如果电脑上没有PS 图形技术没有出现
Shaofei Cheng 说:
UX只能把纸上的东西给开发者
Shaofei Cheng 说:
那么UX for software这个职业可能就不会出现了
Shaofei Cheng 说:
也不会有人提议将 软件的界面设计分成一层了吧
Aimingoo 说:
这个职业呵~~~ N早先就有。
Aimingoo 说:
要不你认为Windows是怎么做出来的?Mac?
Aimingoo 说:
哈哈。
Aimingoo 说:
基本上,到这里吧,我觉得你已经了解我想说的了。
Shaofei Cheng 说:
嗯
谢谢
Aimingoo 说:
对了,winter,我想把这段讨论贴出来。可?
Shaofei Cheng 说:
当然没问题
Shaofei Cheng 说:
跟你谈谈架构方面的东西很有收获
Aimingoo 说:
我整理下下。会比较清楚。
Shaofei Cheng 说:
嗯
下一节-->>
分享到:
相关推荐
标题中的"FastReport VCL 5.0 (RAD Studio XE4) 下载"表明这是针对RAD Studio XE4版本的FastReport VCL 5.0组件的下载资源,适用于那些使用Embarcadero RAD Studio集成开发环境的开发者。 FastReport VCL的主要特性...
- CodeGear RAD Studio 2007 (also known as Delphi 2007 for Win32, C++Builder 2007); - Borland Developer Studio 2006 (also known as Delphi 2006, C++Builder 2006); - Borland Delphi 2005; - Borland Delphi...
FastReport VCL 5是一款强大的报表生成工具,专为RAD Studio、Delphi和C++Builder 10 Seattle用户设计。这个版本的FastReport提供了一系列先进的报告设计和开发功能,极大地提升了开发人员在创建、编辑和分发报表时...
FastReport VCL 5是一款强大的报表设计和生成工具,专为RAD Studio、Delphi和C++Builder XE7开发环境而设计。这个版本发布于2014年11月11日,提供了对XE7版本的全面支持,旨在帮助开发者在他们的应用程序中创建、...
不想麻烦或者想用源码自己编译请移步:https://download.csdn.net/download/pp_haitun/13114619,下载DevExpress VCL 19.1.2 源码和DxAutoInstaller2.3.1编译。 This version has no any dcu files so Built .exe ...
InfoPower VCL是一款专为RAD Studio 10 Seattle设计的组件库,它是Delphi开发者的重要工具,用于构建高效、功能丰富的应用程序。此压缩包“InfoPower_VCL_for_RAD_Studio_10_Seattle_Downloadly.ir.rar”包含了适用...
TeeChart Pro 2011 for Delphi RAD XE2 crack Support 32bit and 64bit OS 絕對可用
FastReport VCL 5.5.12 是一款强大的报表设计和生成工具,专为RAD Studio Delphi和C++ Builder 10.2 Tokyo开发环境设计。它在Delphi和VCL(Visual Component Library)环境中提供了高效、灵活的报表解决方案,帮助...
RAD Studio VCL Reference (VCL参考) ContentsActnColorMaps Namespace Classes TStandardColorMap Class TStandardColorMap Members TStandardColorMap Methods TStandardColorMap.SetColor Method ...
DevExpressVCL 15.2.2 XE-RAD10.2 FullSource 自动编译安装 带汉化包 百度网盘下载
RAD Studio 11.1安装包 DevExpressVCL 21.1.6[CS]
《TMS VCL UI Pack for RAD Studio 10.4 Sydney 10.5.5.0:提升 Delphi 应用程序的用户界面设计》 TMS VCL UI Pack 是一个专门针对 Embarcadero RAD Studio 开发环境的组件库,特别是针对 10.4 Sydney 版本。这个...
FastReport VCL For Embarcadero RAD Studio 2009 试用版 FastReport VCL For Embarcadero RAD Studio 2010 试用版 FastReport VCL For Embarcadero RAD Studio XE (Delphi/C++Builder) 试用版 FastReport VCL ...
就是原来的的Raize Vcl Controls,带RAD10.2.1编译文件,其他版本自行编译 WELCOME TO KONOPKA SIGNATURE VCL CONTROLS VERSION 6 CONTENTS - Completing the Installation - What's New - Moving the Component ...
DevExpressVCL 14.2.2 D7-RX10 FS 自动编译安装 带汉化包 V2.zip 是一个针对 Delphi 开发者的压缩包,包含了一系列重要的工具和组件,主要目的是帮助用户在 Delphi XE7 至 RAD Studio 10 (RX10) 的环境中自动编译并...
《InfoPower VCL for RAD Studio 10 Seattle:深度解析与应用指南》 InfoPower VCL for RAD Studio 10 Seattle是一款专为Embarcadero RAD Studio 10 Seattle开发的组件库,它为Delphi开发者提供了丰富的可视化控件...
著名的条码及二维码控件:Barcode studio,本资源虽然不是最新版本,但是根据源代码修改,具有更好的兼容性,谢谢老猫的②FireMonkey[移动开发] 165232328的共享,下载解压后,进入DelphiXE\Packages目录,打开...