附注1:如何让 dcef3 和 CEF4Delphi 共存
严格来说这个和 cef 本身没有关系,但这毕竟是当前 delphi 语言下仅有的两种流行的 cef 封装,所以考虑再三还是作为附注加入进来.
解决办法说赤也简单,首先这种冲突只是由于相同的类名造成的,但并不需要像其他语言那样更改所有同名的类.其实只要保证窗体设计器上的类不重名就可以了.对于 dcef3 来说,修改 cefreg.pas
下的控件注册名就可以了,然后给几个空的新类即可,我的实现如下
//--------------------------------------------------
// 2019/4/27 11:53:35 //clq 为避免和 decf4 的同名控件冲突,只要在 cefvcl.pas 中加入这些代码即可
//(*
type
TChromium_Newbt = class(TChromium);
TChromiumDevTools_Newbt = class(TChromiumDevTools);
TChromiumOSR_Newbt = class(TChromiumOSR);
{$ifdef DELPHI16_UP}
TChromiumFMX_Newbt = class(TChromiumFMX);
{$endif}
//*)
//--------------------------------------------------
这就是 delphi 的强大之处,很多人都问我们这些还在用 delphi7 的人,质疑这是不是太落伍了,但我们一直喜欢着他. 对于我来说 d7 至少目前来说仍然有以下其他语言或者IDE工具无法替代的地方:
1.不需要 vc 那样附带另外的运行库包;
2.不需要庞大的运行库,例如 java python .net;
3.它是编译型的本地语言,不是脚本,不过我现在也越来越喜欢脚本语言;
4.d7的 ide 对比现在的开发环境,极度的小巧,占用内存极低,就像 vc6.不过这对于我来说不算但大的优点.
5.能在 xp/2003 下运行;
6.实在不行的时候,我们有开源版本可代替,它与 d7 代码的兼容性非常高.我个人觉得这一点是 d7 最大的优点! 这也是为什么 delphi 一直在进化却一直没代替 d7 的一个非常重要的原因;
7.还有一个对开其他人可能没想过,对于我来说却是至关重要的特性: delphi 的各个系统模块也就是各个系统的 pas dcu 文件都是可以自己重写代替的!至少到 d7 的时候还是这样,这就意味着我们能不停地
更新 delphi 的各个系统库本身,只要 d7 的原始编译器能用它就永远不会过时,因为d7对 dll 的调用是非常独立的,和语言本身并没有什么关系,只要 windows 系统 dl 调用的方式不变,我们就可以一直升级
它的系统调用能力,而这种 dll 调用方式在很长的未来里都不太可能改变.
举一个例子:d7 的拖放功能在 win10 下时是有很严重的闪烁的,我就是通过修改了基础常用控件 pas 就避免了这个问题.而且因为 delphi 对 pas 单元引用的灵活性,我只要把修改后的文件放在项目源码目录
中即可都不用修改 d7 本身的任何源码就可以实现了. 通过这种方式我甚至修改过 d7 的内存分配实现! 改天我放个示例到 github 上.
8.再有就是 delphi 的作者赋予 delphi 本身的强大的 rad 功能,说实在的现在的什么 xcode ,android studio 的界面设计器与 delphi 比都是笑话,唯一能和 delphi 比的就是 vb 和那个同样是 delphi 作者出品
的宇宙第一 ide - C# 在 vs 中的设计器. 说实在的 css 的布局方式升级了那么多次,仍然如此难用也实在是够蠢的. 还有什么 gtk qt 的设计器更是愚不可及.