Sorry if this is in the wrong forum, but I can't seem to find anything specific to TWebUpdate.
When updating an application and help file (*.chm) this works fine in most cases, and the *.chm file updates correctly.
if I have viewed the help file in any way within the application before then checking for updates and performing the update, then the help file will not update. Unhelpfully, this is silent and there is no indication of any problem in the log file. It simply appears to work, but does not.
I have looked in the Delphi TApplication source code, and my best guess is that through the interface FHelpSystem: IHelpSystem that it is holding an open copy of the help file (and thus that file can not be overwritten). Unfortunately I can see no way of getting the application to flush its help system interface. This is only done when the application closes down (when an application starts it grabs the help system interface, but presumably does not lock the help file in to memory until it is used).
While at some level this seems like a Windows/Delphi issue, it feels like it might be quite a common issue to people using the TWebUpdate tool and I was wondering if anyone has dealt with this, and how?
Unfortunately the way my script is set up, once the application has updated (but not the help file) there is no easy way to trigger an update just for the help...
Thanks
Dave
This issue hasn't been reported before. It appears that indeed something keeps locking the help file in memory and therefore, the file cannot be overwritten. Is this the default Microsoft Windows CHM file viewer you're using? How exactly do you launch the help file?
Thanks Bruno
I believe it is the default viewer. It is simply being activated as the default context-sensitive help out of our Delphi appplication (using the Vcl.HTMLHelpViewer include in our main form module).
Open a file move to a feature and hit F1.
----
We also have some other issues on another system. The autoupdate will run fine if we only update the executable, but if we leave the check box checked to update the chm file we get a system error when trying to download the chm. I have checked that this works fine from some other systems (an old XP system for example)
This from the log file (it is on a Japanese system, so I had to get a translation of the system error message from our Japanese colleague). Urls changed to something generic below...
02/05/2017 11:04:49 : [915] Download : ftp://www.www.www/Dir1/Dir2/SomeHelp.chm (Status:3) (Error:0)
02/05/2017 11:04:50 : [976] System error : connection to the server was reset
(Status:1) (Error:12031)
02/05/2017 11:04:50 : [917] File not found : ftp://www.www.www/Dir1/Dir2/SomeHelp.chm (Status:2) (Error:1)
When we get this error the whole update process stops. It won't even update the exe which had already successfully downloaded to the temp directory.
I am wondering whether maybe this is a Windows security issue blocking chm files. I just don't know quite how to prove that at the moment.
I'm not sure there is an easy or straightforward solution to the chm update issue when the chm viewer keeps locking the file. A brute force method could be to kill the chm viewer process, but I'm not sure there is a generic way to find the process. If this is a chm viewer will multiple tabs, this means the user will also have lost the other tabs.
For the 2nd problem, have you looked at usual suspects like firewall / antivirus for blocking access to your app to the FTP server where the update is?
Thanks. I can't think of a sensible option as things stand. I think the only way that is reliable will be to move the chm file to something like a cab file and have it processed after the application has closed.
With regard to the download issue, it is tricky as the system is in Japan with language barriers and no easy direct access to be able to try and look. It may be that also moving this to a CAB file will get around the downloading issue. I just need to look at how easy it will be to do a number of files with user selectable downloading out of a single cab, or maybe each file will have to be cab'd and then post-processed...
Anyway thanks for the response
With respect to the chm file, a possible idea could be to use the app version number in the CHM filename, so that with each version, a new CHM file gets used?
Interesting idea. Not sure how I would deal with the fact that the installer puts a short cut on the start menu to the help file too (not absolutely necessary, but not uncommon). On each update we would need to also change the start menu short cut... Thanks for the thought, I will think on it some more.