分享
 
 
 

解决ActiveForm无法自动更新

王朝delphi·作者佚名  2006-01-08
窄屏简体版  字體: |||超大  

ActiveForm Updates

ActiveForms are a quick way to create a browser-based application and still be able to use all of Delphi's visual components and design-time support. If you have an existing Win32 GUI application and want to move to the web with it, then ActiveForms are certainly an option to consider (although you must be aware of the downsides: it only runs natively inside Internet Explorer, and really requires Win32 as client operating system). And apart from the code signing (security!) issue, which can take some time to setup, ActiveForms are really a quick solution to put a first version of your app in the browser. Until you want to deploy an updated version, that is, at which time you may find that the client (running Internet Explorer) not always automatically uses the new version of the ActiveForm. In fact, the current way Delphi generated ActiveForm deployment files and Internet Explorer "interact", it would be a miracle if your real-world ActiveForm would be automatically updated even once at the client side. Fortunately, I've found an easy workaround, but let's take a closer look at the cause of this problem first...

Before we start looking at the problem, I assume you've all started an ActiveForm with the "include version information" enabled, as well as all other "auto-increment build number" and "auto-increment release number" options inside the Project Options and Deployment options dialogs. If you don't include version information with your ActiveForm, then you don't even need to read the remainder of this little article, as there will be no way where-ever that Internet Explorer on the client will be able to determine that a new version of the ActiveForm exists. Which means clients need to stick with the original version (unless you can instruct them to either manually delete either the old one, or download and install the new one - yeah, right, and maybe Borland will buy Microsoft to fix these miscommunication problems next time).

Anyway, when deploying an ActiveForm, Delphi (and C++Builder) generates a number of files. If you do not use .CAB file compression and also do not deploy any packages or additional files, then Delphi generates a single .HTM file and a single .OCX files (both with filenames equal to your projectname). The .HTM file will contain a section that identifies the ActiveForm to be loaded, which also includes the version number, as follows: <OBJECT

classid="clsid:42424242-4242-4242-4242-424242424242"

codebase="./DrBob42X.ocx#version=1,0,0,0"

width=640

height=480

align=center

hspace=0

vspace=0

>

Now, if you either specify that you want to use .CAB file compression (always a good idea) or you need to deploy packages or additional files, then Delphi will generate an .HTM file that will not directly specify the ActiveForm with a version number, but rather an .INF file (without a version number - that's the problem). This .INF file will in its turn contain the specifications of the ActiveForm and all other deployed files, including detailed version information, for example as follows: [Add.Code]

DrBob42X.ocx=DrBob42X.ocx

VCL50.bpl=VCL50.bpl

[DrBob42X.ocx]

file=./DrBob42X.cab

clsid={42424242-4242-4242-4242-424242424242}

RegisterServer=yes

FileVersion=1,0,4,2

[VCL50.bpl]

file=./VCL50.cab

FileVersion=5,0,6,18

DestDir=11

The problem when using an .INF file (which you get - again - even if only using .CAB file compression), is that Internet Explorer only looks at the version information inside the HTM file in order to determine whether or not to download a new set of files from the server. Even if we supply a new INF file with higher version numbers, Internet Explorer will not check these version numbers and download a new ActiveForm. This has been a problem for a long while now, and a potential showstopper for real-world applications using ActiveForms.

Fortunately, there's an easy workaround I discovered: just specify the version number inside the HTM file again. When using an INF file, the HTM file will originally contain the following snippet: <OBJECT

classid="clsid:42424242-4242-4242-4242-424242424242"

codebase="./DrBob42X.inf"

width=640

height=480

align=center

hspace=0

vspace=0

>

As soon as you enter a version number to this ./DrBob42.inf file, then Internet Explorer will be triggered to compare it to the local version, and download a new ActiveForm (and if needed packages and additionally deployed files as well). In short, the "working" OBJECT code snippet would look as follows (for the same 1.0.4.2. version number inside the DrBob42.inf file): <OBJECT

classid="clsid:42424242-4242-4242-4242-424242424242"

codebase="./DrBob42X.inf#version=1,0,4,2"

width=640

height=480

align=center

hspace=0

vspace=0

>

The only downside is that you need to manually adjust the HTM file everytime you deploy your ActiveForm. But that's not really a problem, since I doubt you'd want to use the HTM file generated by Delphi (or C++Builder) in a real-world situation anyway. It only means you need to look into the .INF file to find out the actual version number (which in my case increases after every build and every deployment) and modify the HTM file to reflect that new version. And that will make sure all my clients will get the right new version of the ActiveForm next time they load Internet Explorer, as they should.

One final word of caution: if you've selected the "auto-increment build number" and "auto-increment release number" options, then you should know that the release number will be auto-incremented right after you've deployed the ActiveForm. In other words: right after you've deployed it for the first time, the ActiveForm version on disk (and on the server) will be 1,0,0,0. However, the file version information in your current project will then show 1,0,1,0 - i.e. the release number (third number of the series) in the IDE will always be one higher than the release number of the actually deployed ActiveForm. This is not so with build numbers (fourth number of the series) - these will always be in sync. Remember this when you client calls and specifies the version number (and it might also be a good idea to have the ActiveForm display the version number somewhere in a lower-left corner, for example)...

那位大虾有空翻译下 ^_^.

其实说白了就一句话,修改delphi自动产生(当然你也可以手工做一个)的测试ActiveForm的html文件,在原codebase所在行追加一句"#version=1,0,4,2",此版本号ocx文件的版本号

 
 
 
免责声明:本文为网络用户发布,其观点仅代表作者个人观点,与本站无关,本站仅提供信息存储服务。文中陈述内容未经本站证实,其真实性、完整性、及时性本站不作任何保证或承诺,请读者仅作参考,并请自行核实相关内容。
2023年上半年GDP全球前十五强
 百态   2023-10-24
美众议院议长启动对拜登的弹劾调查
 百态   2023-09-13
上海、济南、武汉等多地出现不明坠落物
 探索   2023-09-06
印度或要将国名改为“巴拉特”
 百态   2023-09-06
男子为女友送行,买票不登机被捕
 百态   2023-08-20
手机地震预警功能怎么开?
 干货   2023-08-06
女子4年卖2套房花700多万做美容:不但没变美脸,面部还出现变形
 百态   2023-08-04
住户一楼被水淹 还冲来8头猪
 百态   2023-07-31
女子体内爬出大量瓜子状活虫
 百态   2023-07-25
地球连续35年收到神秘规律性信号,网友:不要回答!
 探索   2023-07-21
全球镓价格本周大涨27%
 探索   2023-07-09
钱都流向了那些不缺钱的人,苦都留给了能吃苦的人
 探索   2023-07-02
倩女手游刀客魅者强控制(强混乱强眩晕强睡眠)和对应控制抗性的关系
 百态   2020-08-20
美国5月9日最新疫情:美国确诊人数突破131万
 百态   2020-05-09
荷兰政府宣布将集体辞职
 干货   2020-04-30
倩女幽魂手游师徒任务情义春秋猜成语答案逍遥观:鹏程万里
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案神机营:射石饮羽
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案昆仑山:拔刀相助
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案天工阁:鬼斧神工
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案丝路古道:单枪匹马
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案镇郊荒野:与虎谋皮
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案镇郊荒野:李代桃僵
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案镇郊荒野:指鹿为马
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案金陵:小鸟依人
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案金陵:千金买邻
 干货   2019-11-12
 
推荐阅读
 
 
 
>>返回首頁<<
 
靜靜地坐在廢墟上,四周的荒凉一望無際,忽然覺得,淒涼也很美
© 2005- 王朝網路 版權所有