King_David
asked on
FormResize Event
I've FormResize and FormDestroy Events on my Main Form.
Strangly, when closing the form the FormResize Event
is triggered after my FormDestroy Event.
What could be the cause of this behaviour?
Sometimes, not allways, the application ends with an
access violation on exiting the FormResize.
Thanks, David.
Strangly, when closing the form the FormResize Event
is triggered after my FormDestroy Event.
What could be the cause of this behaviour?
Sometimes, not allways, the application ends with an
access violation on exiting the FormResize.
Thanks, David.
ASKER
Even if I comment all the code in the FormDestroy it
still happens.
still happens.
And if you comment all the code in FormResize?
It's difficult to see what the problem is without a listing of your unit.
However there is a quick way to prevent your FormResize firing after the form has started to destroy itself. Just make this the first line of your FormResize event handler.
If csDestroying in ComponentState then
exit;
However this just avoids the problem rather than actually fixing it.
Jo
Another quick fix (without knowing the reason why FormResize is triggered) would be to set the OnResize handler in your OnDestroy handler to nil:
procedure TForm1.FormDestroy(...);
begin
OnResize := nil;
[...]
end;
If you want to know who triggers the FormResize event, you should go through all your code step by step in the debugger, starting at FormDestroy. Maybe one component on your form does something weird when being destroyed. Who knows?
Maybe it also helps you to set a breakpoint to FormResize, and if you get there after FormDestroy, look at the callstack, it maybe also shows you who is responsible for triggering the FormResize event...
Regards, Madshi.
procedure TForm1.FormDestroy(...);
begin
OnResize := nil;
[...]
end;
If you want to know who triggers the FormResize event, you should go through all your code step by step in the debugger, starting at FormDestroy. Maybe one component on your form does something weird when being destroyed. Who knows?
Maybe it also helps you to set a breakpoint to FormResize, and if you get there after FormDestroy, look at the callstack, it maybe also shows you who is responsible for triggering the FormResize event...
Regards, Madshi.
ASKER
If I add OnResize := Nil; as the first line of my
FormDetroy Event, the FormResize is not triggered but
my application end with runtime error 216.
These solutions are work-arounds, I would like to solve
this bug.
FormDetroy Event, the FormResize is not triggered but
my application end with runtime error 216.
These solutions are work-arounds, I would like to solve
this bug.
It's also an access violation !
if you post your code if would be much easier.
if you post your code if would be much easier.
Out of interest, did you try my solution?
>> These solutions are work-arounds, I would like to solve
this bug.
Then you're a real programmer. In that case reread the last two paragraphs of my previous comment:
"If you want to know who triggers the FormResize event, you should go through all your code step by step
in the debugger, starting at FormDestroy. Maybe one component on your form does something weird when
being destroyed. Who knows?
Maybe it also helps you to set a breakpoint to FormResize, and if you get there after FormDestroy, look
at the callstack, it maybe also shows you who is responsible for triggering the FormResize event..."
I can add a third possibility to find the real bug: Where does the access violation occur (runtime error 216 = access violation), when you do that "OnResize := nil"? This might exactly be the guilty code location. Use "Find runtime error" to find the source line. (This function works only if the process is running, so press F7 once to get into the debugger, then click "Find runtime error", then give in the address with a leading "$").
this bug.
Then you're a real programmer. In that case reread the last two paragraphs of my previous comment:
"If you want to know who triggers the FormResize event, you should go through all your code step by step
in the debugger, starting at FormDestroy. Maybe one component on your form does something weird when
being destroyed. Who knows?
Maybe it also helps you to set a breakpoint to FormResize, and if you get there after FormDestroy, look
at the callstack, it maybe also shows you who is responsible for triggering the FormResize event..."
I can add a third possibility to find the real bug: Where does the access violation occur (runtime error 216 = access violation), when you do that "OnResize := nil"? This might exactly be the guilty code location. Use "Find runtime error" to find the source line. (This function works only if the process is running, so press F7 once to get into the debugger, then click "Find runtime error", then give in the address with a leading "$").
If you destroy the form with FormX.Free, change it to FormX.Release.
Hi all!
This is just my opinion. Maybe, when form is being freed, you access the components which no longer exists in OnResize event handler. Try to encapsulate your code in TForm.OnResize event handler like:
procedure TForm1.FormResize(...);
begin]
if not (csDestroying in ComponentState) then
begin
// put here your original code
end;
end;
Best regards, Ivo.
This is just my opinion. Maybe, when form is being freed, you access the components which no longer exists in OnResize event handler. Try to encapsulate your code in TForm.OnResize event handler like:
procedure TForm1.FormResize(...);
begin]
if not (csDestroying in ComponentState) then
begin
// put here your original code
end;
end;
Best regards, Ivo.
begin
if Application.Terminated then exit;
...
...
...
if Application.Terminated then exit;
...
...
...
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
alx512, you have a point.
Here is what I found so far:
Look at procedure TCustomForm.WMDestroy
pay attention to the line "if (FMenu <> nil)..."
If I set in my FormDestroy
MainMenu.Free;
MainMenu := Nil;
then the event is not triggered and I'm happy.
Here is what I found so far:
Look at procedure TCustomForm.WMDestroy
pay attention to the line "if (FMenu <> nil)..."
If I set in my FormDestroy
MainMenu.Free;
MainMenu := Nil;
then the event is not triggered and I'm happy.
ASKER
I'm giving the points to alx but I thank all you for your
help.
the solution:
My form has many components with their Align set.
When the form is detroyed, the MainMenu gets destoyed
and a lot of activities are going on to resize
the form.
And the solution is: in FormCloseQuery I destroy
the MainMenu and set it to nil, this triggers the
FormResize event and when the FormDestroy is triggered
FormResize remains calm.
Regards, David.
help.
the solution:
My form has many components with their Align set.
When the form is detroyed, the MainMenu gets destoyed
and a lot of activities are going on to resize
the form.
And the solution is: in FormCloseQuery I destroy
the MainMenu and set it to nil, this triggers the
FormResize event and when the FormDestroy is triggered
FormResize remains calm.
Regards, David.
May be you call something in your Destroy-Event that will
be change the size of your form?