Project JEDI - Issue Tracker
Mantis Bugtracker

Viewing Issue Simple Details Jump to Notes ] View Advanced ] Issue History ] Print ]
ID Category Severity Reproducibility Date Submitted Last Update
0004078 [JEDI VCL] 00 JVCL Components crash random 2007-03-06 13:35 2007-10-12 06:52
Reporter Traptak View Status public  
Assigned To obones
Priority normal Resolution fixed  
Status resolved   Product Version Daily / GIT
Summary 0004078: Access Violation on closing JvDesktopAlert forms
Description From time to time my application show me Access Violation after closing JvDesktopAlert forms. Exception was raised in procedure TJvExCustomForm.WndProc(var Msg: TMessage); in line:

if DotNetHighlighting then
  HandleDotNetHighlighting(Self, Msg, MouseOver, Color);

It happends once on hundred closes. I have check component code and I think I found bug.

So, if AutoFree property is set to True and user close form then JvDesktopAlert component post message JVDESKTOPALERT_AUTOFREE to his form. In JvDeskTopAlertAutoFree procedure there are two actions:

procedure TJvFormDesktopAlert.JvDeskTopAlertAutoFree(var Msg: TMessage);
  // WParam is us, LParam is the TJvDesktopAlert
  if Msg.WParam = WPARAM(Self) then

At first desktop form is released and after that TJvDesktopAlert object is destroyed. It looks like correct code but TJvDesktopAlert object is owner of JvDesktopForm, so form is destroyed before it has receive CM_RELEASE message.

I think TJvDesktopAlert cannot be form owner in this moment. So I made following changes in TJvDesktopAlert procedures:

destructor TJvDesktopAlert.Destroy;
  // when AutoFreeing, Delphi doesn't like the component having an owner, so remove the Owner here
  if FAutoFree and (Owner <> nil) and not (csDesigning in ComponentState) then
  if (FDesktopForm <> nil) then
    if FDesktopForm.Showing then
    FDesktopForm.OnClose := nil;
      // Here is one line added

    FDesktopForm := nil;
  inherited Destroy;

procedure TJvDesktopAlert.InternalOnClose(Sender: TObject;
  var Action: TCloseAction);
  if (csDestroying in ComponentState) then
  if Location.Position = dapCustom then
    Location.Top := FDesktopForm.Top;
    Location.Left := FDesktopForm.Left;
  if Assigned(FOnClose) then
  if AutoFree and (FDesktopForm <> nil) and not (csDesigning in ComponentState) then
    FDesktopForm.OnClose := nil;
    // post a message to the form so we have time to finish off all event handlers and
    // timers before the form and component are freed
    PostMessage(FDesktopForm.Handle, JVDESKTOPALERT_AUTOFREE, WPARAM(FDesktopForm), LPARAM(Self));

      // Here is one line added

    FDesktopForm := nil;

After this changes were made problem still exist but exception raise on CM_RELEASE message handling. So I have change problematic line on:

      // Don't make any action after CM_RELEASE message
    if (Msg.Msg <> CM_RELEASE) and DotNetHighlighting then
      HandleDotNetHighlighting(Self, Msg, MouseOver, Color);

I think that after handling CM_RELEASE message object does not exist so object's property cannot be used. After this change was made exception never occur.
Additional Information Here is attached patch with changes I have made in JVCL code.
Tags No tags attached.
Attached Files ? file icon JvDesktopAlert AV patch.patch [^] (1,366 bytes) 2007-03-06 13:35

- Relationships

-  Notes
kata322 (reporter)
2007-05-14 08:05

No one take a look to this issue? (more than two month passed)
obones (administrator)
2007-06-20 02:19

Could you provide the zipped sources of a sample application showing this?
AHUser (developer)
2007-06-24 07:44

I have added the "message" check to the "if DotNetHighlighting then". Could you try if this now works for you. Or if the TJvDesktopAlert.Destroy is really necessary?
obones (administrator)
2007-10-12 06:51

No news, I believe this is fixed in SVN

- Issue History
Date Modified Username Field Change
2007-03-06 13:35 Traptak New Issue
2007-03-06 13:35 Traptak File Added: JvDesktopAlert AV patch.patch
2007-03-06 13:37 Traptak Issue Monitored: Traptak
2007-05-14 08:05 kata322 Note Added: 0012786
2007-06-20 02:19 obones Note Added: 0013482
2007-06-20 02:19 obones Status new => feedback
2007-06-24 07:44 AHUser Note Added: 0013535
2007-10-12 06:51 obones Status feedback => resolved
2007-10-12 06:51 obones Fixed in Version => Daily / SVN
2007-10-12 06:51 obones Resolution open => fixed
2007-10-12 06:51 obones Assigned To => obones
2007-10-12 06:51 obones Note Added: 0013918
2010-02-08 17:24 kata322 Issue Monitored: kata322

Mantis 1.1.6[^]
Copyright © 2000 - 2008 Mantis Group
Powered by Mantis Bugtracker