Mattias wrote

I also added 'BeforeDestruction' to TForm.Destroy, which is a workaround for the missing BeforeDestruction call of the 1.0.x compiler. This fixes for example your mem leaks in cbtracker. So, you can now use heaptrc without garbage.

ah... this was one of my modifications to be committed before my internet connection broke down 2 weeks ago :)

I've moved the beforedestruction call to Tcustomform.Destroy.

When doing so I found out that tform had no real code so I removed form.inc and references to it.

Marc

FYI, TCustomForm.BeforeDestruction fires the OnDestroy event. Since it was never called, the event didn't fire.

I had noticed a few days ago that this seemed to be happening and added it to my list of things to investigate. I wasn't positive that it wasn't firing on EVERY form, so I hadn't reported it as a bug yet.

-Tony

In CBTracker when clicking from Account to Bills to Cash Flow, sometimes things will hang and my CPU usage goes to 100%. The interface does not update.

Fixed.

Mattias

Mattias Gaertner wrote

I did only some small tests and found some mem leaks and a double canvas, which I fixed.

I'm not sure I follow you - is this something wrong in my code, or in the LCL?

Your description makes clear that one message creates the next in an endless loop. Clicking outside the application creates mouse and focus out messages. So we can start looking here.

But wouldn't that require a message handler to trigger another message? I checked my handler routines and none of them were repeating...

I also added 'BeforeDestruction' to TForm.Destroy, which is a workaround for the missing BeforeDestruction call of the 1.0.x compiler. This fixes for example your mem leaks in cbtracker. So, you can now use heaptrc without garbage.

I have absolutely no idea what you're talking about unless this is why the onformdestroy didn't work.

Thanks,

Tony

In the LCL.

yep

I checked my handler routines and none of them were repeating...

Ok. But since you get the error very quickly you could find out, which message it is. I will send you some code.

This was explained by Marc.

Mattias

The gtk interface sends paint messages not before all other messages are sent. This is because other messages can create new paint messages and paint messages are very expensive.
So, as long as something is generating messages, no paint message will be sent to the application.
I did only some small tests and found some mem leaks and a double canvas, which I fixed.
The bug did not yet appear with my tests. Perhaps it will only appear with more cbtracker data. I will do more tests.
Your description makes clear that one message creates the next in an endless loop. Clicking outside the application creates mouse and focus out messages. So we can start looking here.

I also added 'BeforeDestruction' to TForm.Destroy, which is a workaround for the missing BeforeDestruction call of the 1.0.x compiler. This fixes for example your mem leaks in cbtracker. So, you can now use heaptrc without garbage.

Mattias

I don't THINK this is my code causing this. Looks like something in the LCL. But then again, I've been wrong before ;-) I've exhausted everything I can think of to find this.

It just started with my latest build as of yesterday working off of Friday's CVS. I have since done the CVS update for Lazarus 0.8.5 and the problem continues.

In CBTracker when clicking from Account to Bills to Cash Flow, sometimes things will hang and my CPU usage goes to 100%. The interface does not update.

But, all I have to do is click anywhere in my desktop environment (on or off the application) and the endless loop stops.

It's odd because the button click event for the button finishes completely before the loop, and the paint event for my custom control (TCheckBookSchedule) never fires off, and nothing else on the form gets a paint either. So it's between showing the controls on the form and the first paint message. And it doesn't totally crash the program or anything - all you have to do is click the mouse anywhere - and it doesn't even have to be within the program - for it to unhang.

I'm doing a little trick to resize my scrollbar that when these buttons are clicked I resize the custom control. I've confirmed that my WM_SIZE event is processed correctly, but it never goes on to trigger a WM_PAINT event for controls on the form. Other than that, all these buttons do is hide and show controls.

In case you want them, sources with a built executable is at:

http://members.telocity.com/~tonymaro/cbbad.tgz

Note: It's intermittent - maybe one out of every 5-10 times you click between Bills and Cash Flow. I've traced through all of the code of mine that I believe could be running at that point, which is all message handlers. None of my code appears to be running when this happens. It never seems to happen when you click TO the Account view though. And it happens on both the bills and the cash flow views, so I know it's not related to the graph control I made, but the TCheckBookSchedule IS visible in both views.

Anyway, like I said I'm not POSITIVE it's not my code, especially considering that's the only two places it happens and both contain the TCheckBookSchedule control, but there's no handling I do that would be affected by a click anywhere else. If I were generating an endless loop within my code, it wouldn't stop looping when the user clicked on the desktop. That's why I'm guessing it's GTK+ related.

Thanks,

Tony

FYI, TCustomForm.BeforeDestruction fires the OnDestroy event. Since it was never called, the event didn't fire.