View Issue Details

IDProjectCategoryView StatusLast Update
0003588JEDI VCL00 JVCL Componentspublic2006-04-19 15:08
ReporterKiriakosAssigned Tojfudickar 
Status resolvedResolutionfixed 
Product Version3.10 
Target VersionFixed in Version3.30 
Summary0003588: JvProgramVersionCheck terminates an application in a way which causes troubles.
DescriptionThanks 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.
TagsNo tags attached.



2006-03-17 17:40

reporter   ~0008687

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?


2006-03-18 15:03

reporter   ~0008690

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(...);
  if SelectedLocation then begin
    Result := ... as it is
    fDownLoadError := SelectedLocation.DownLoadError;
  end else
    Result := '';

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.


2006-03-19 11:55

administrator   ~0008692

Application.Terminate is THE way to close an application, and it actually calls the PostQuitMessage API, so I see no problem here.


2006-03-19 12:26

reporter   ~0008694

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.


2006-03-19 14:43

developer   ~0008697

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.



2006-03-20 02:07

reporter   ~0008698

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.


2006-03-30 19:52

reporter   ~0008776

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.


2006-04-19 13:53

developer   ~0009145

I've made the last changes. (Updated to svn)

Please have a look and give me a feedback if we can close the issue.



2006-04-19 14:11

reporter   ~0009146

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.


2006-04-19 14:26

developer   ~0009147

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?


2006-04-19 14:40

reporter   ~0009148

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.


2006-04-19 14:51

developer   ~0009149

You have convinced me. I've changed the property to public, adding a virtual procedure SetDownloadError.



2006-04-19 15:05

reporter   ~0009150

Thanks! I guess you may close the issue now.


Issue History

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