|
|
err.png (26,226 bytes) |
|
|
Exception and Access violation are 2 different things. Access violation is always wrong and means you should fix the code. Looks like yet another crappy bug report. |
|
|
I have reported (on ML I think) similar problems with raising exceptions in an OnTimer event on Windows. Currently if I raise an exception in an OnTimer event, the exception does NOT bubble up. Nothing happens at all, the program simply continues. Just a simple form with a button and a timer. procedure TForm1.FormCreate(Sender: TObject); begin end; procedure TForm1.Timer1Timer(Sender: TObject); begin writeln('Timer1: raising an exception'); raise exception.create('foo'); end; procedure TForm1.Button1Click(Sender: TObject); begin Timer1.Enabled := True; end; It will continously spit out: Timer1: raising an exception Timer1: raising an exception Timer1: raising an exception Timer1: raising an exception Timer1: raising an exception Timer1: raising an exception Timer1: raising an exception Timer1: raising an exception etc. etc. |
|
|
Running the same program from my note abov on Linux GTK2 gives exactly the errormessage that is attached to this bugreport. |
|
|
Juha, no, not crap report, look at the demo code. I must see my own exception. in reality I see "AV". |
|
|
customtimer.pas: CustomApplication is nil. procedure TCustomTimer.Timer; begin {$IFDEF VerboseTimer} DebugLn(['TCustomTimer.Timer ',dbgsName(Self),' ',FEnabled,' ',FInterval]); {$ENDIF} if (FEnabled) and (FInterval > 0) then try DoOnTimer; except CustomApplication.HandleException(nil); end; end; |
|
|
added the fix! note - 'Forms' must be used in 'implementation'. (otherwise- circular reference). fix.diff (669 bytes) |
|
|
Ok, it was a real bug. I synchronized CustomApplication with Application instead of using variable Application and creating a circular reference. I think it is logically correct. Please test. |
- Anonymous
