View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0003588 | JEDI VCL | 00 JVCL Components | public | 2006-03-17 10:09 | 2006-04-19 15:08 |
| Reporter | Kiriakos | Assigned To | jfudickar | ||
| Priority | normal | Severity | major | Reproducibility | always |
| Status | resolved | Resolution | fixed | ||
| Product Version | 3.10 | ||||
| Target Version | Fixed in Version | 3.30 | |||
| Summary | 0003588: JvProgramVersionCheck terminates an application in a way which causes troubles. | ||||
| Description | Thanks for implementing my earlier feature request in JvProgramVersionCheck. Here is another one. DownloadThreadOnFinishAll terminates the application by calling Application.Terminate. This shuts down the application abruptly and without calling MainForm.CloseQuery causing potentially crashes during the Application shutdown and preventing proper cleanup. I would suggest instead the more gentle PostMessage(Application.Handle, WM_CLOSE, 0, 0) You would need of course to add Messages to the uses statement. | ||||
| Tags | No tags attached. | ||||
|
|
Also currently if there is no newer version Execute returns quietly and there is no ease way to tell that no newer version was fount. Could you make IsRemoteProgramVersionNewer public? |
|
|
More suggestions: - Make DownLoadError property of TJvCUstomProgramVersionLocation public, so that for decendendents implemented with events such as JvProgramVersionHTTPLocation the user can set DownLoadError if an error occurs in the event handler. - Also provide read access to the JvProgramVersionCheck fDownloadError, so that the error information can be shown to the user. - And modify JvProgramVersionCheck.LoadRemoteVersionInfoFile as follows: function JvProgramVersionCheck.LoadRemoteVersionInfoFile(...); begin if SelectedLocation then begin Result := ... as it is fDownLoadError := SelectedLocation.DownLoadError; end else Result := ''; end; As it stands JvProgramVersionCheck.Execute will return quietly when an error occurs in LoadRemoteVersionInfoFile making the user believe that there is no newer version. I don't think there is currently another way to check. |
|
|
Application.Terminate is THE way to close an application, and it actually calls the PostQuitMessage API, so I see no problem here. |
|
|
With due respect... Application.Terminate (through the handling of WM_QUIT) shuts the application down immediately without calling CloseQuery or the OnClose event! Imagine this scenario. In editor application with open and unsaved files the user calls "Check For Updates". He is asked whether (s)he wants to install the new version, says yes and sudently all work is lost. Moreover many applications use the OnCloseQuery and OnClose events for cleanup operations. So I think that the suggested solution or even Application.MainForm.Close is better. |
|
|
You seemed to be right with the PostMessage. I've changed the code and added the public procedures/properties. The only i've not done is the public "DownLoadError" property of TJvCUstomProgramVersionLocation. This should be possible. Please have a look for the changes at the cvs. Greetings Jens |
|
|
Thanks a lot. I think Thread and ThreadDialog should be read-only properties. And for the reason explained earler the DownLoadError property of TJvCUstomProgramVersionLocation should be made public. Otherwise is great. |
|
|
And since I seem to have your attention another small request. Is it possible to show scrollbars in the Verion Info dialog when needed. Currenlty if the version information is long you can only scroll by dragging the mouse. But also it is not easy to tell that there is more text than what can fit in the memo. |
|
|
I've made the last changes. (Updated to svn) Please have a look and give me a feedback if we can close the issue. Greetings Jens |
|
|
Many thanks. Still outstanding: - Make DownLoadError property of TJvCUstomProgramVersionLocation public, so that decendendents implemented with events such as JvProgramVersionHTTPLocation can set DownLoadError if an error occurs in the event handler. - Optionally Thread and ThreadDialog should be made read-only properties as opposed to read-write. |
|
|
For the Thread*-properties you're right, i've forgotten to save the file :-( But the Downloaderror property, i'm not shure if it is the best way. I think not for the base object, maybe for some dependent objects. Or should we enhance the events to give the possibility to change the errorstate? |
|
|
You may add a var DownloadError : string parameter to the TJvLoadFileFromRemoteHTTPEvent or you can add a SetDownloadError(ErrorStr : string); public method to TJvCustomProgramVersionLocation, which is the same as making the property writable. |
|
|
You have convinced me. I've changed the property to public, adding a virtual procedure SetDownloadError. Greetings Jens |
|
|
Thanks! I guess you may close the issue now. Regards Kiriakos |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2006-03-17 10:09 | Kiriakos | New Issue | |
| 2006-03-17 17:40 | Kiriakos | Note Added: 0008687 | |
| 2006-03-18 15:03 | Kiriakos | Note Added: 0008690 | |
| 2006-03-19 11:55 | obones | Note Added: 0008692 | |
| 2006-03-19 12:26 | Kiriakos | Note Added: 0008694 | |
| 2006-03-19 14:39 | jfudickar | Status | new => assigned |
| 2006-03-19 14:39 | jfudickar | Assigned To | => jfudickar |
| 2006-03-19 14:43 | jfudickar | Note Added: 0008697 | |
| 2006-03-19 14:43 | jfudickar | Status | assigned => feedback |
| 2006-03-20 02:07 | Kiriakos | Note Added: 0008698 | |
| 2006-03-30 19:52 | Kiriakos | Note Added: 0008776 | |
| 2006-04-19 13:53 | jfudickar | Note Added: 0009145 | |
| 2006-04-19 14:11 | Kiriakos | Note Added: 0009146 | |
| 2006-04-19 14:26 | jfudickar | Note Added: 0009147 | |
| 2006-04-19 14:40 | Kiriakos | Note Added: 0009148 | |
| 2006-04-19 14:51 | jfudickar | Note Added: 0009149 | |
| 2006-04-19 15:05 | Kiriakos | Note Added: 0009150 | |
| 2006-04-19 15:08 | jfudickar | Status | feedback => resolved |
| 2006-04-19 15:08 | jfudickar | Resolution | open => fixed |
