Exception in IsFormSizeStored

[Kas Ob.]

Hi,

Zitat von ECHTERNMM:

Hi,

Thank you for your hints, but its difficoult to determin, where the strange SetFocus-Message come from.

The Problem is, that - as already mentioned by BlueStarHH - it does not occur for years but suddenly now.

Though, SetFocus might be not the cause as much as a symptom for a bug somewhere else.

Zitat von ECHTERNMM:

What do you mean by "decent logging"? Shall I catch all setfocus messages and write them to a logfile?
But that would also not show, where they come from...

Yes, logging will help greatly, and no, you don't need to catch all SetFocus occurrences,nor you do need to write everything to a file, you need to follow the lead from the stack, it all start with TMyComboBox.Destroy !

So, first about logging:
You don't need to log everything to a file, though logging everything and having the last few seconds of the life of an application before unexpected exception being raised is priceless, so what i would suggest is to build a log system that log to the memory instead of a file, in this case it is from the main thread, this will simplify the logging system as you don't need high performance and multithreaded logging system (could be a single class),

more detail on this, (and as food for thought) for simple logging that can help you in this case:
You will need a TStringList that store the log messages, as we talking main thread then we don't need SyncObjs like TCriticalSection or anything else, This list will reside in memory only, and when reaching some limit lets say 10k of lines, it will drop first 5k lines, and that is it, no ring buffer too, when an exception had being raised, then log the exception as usual and save that list (StringListLog) to a file, simple like that.
What do you really need to log ?, the answer is simple : everything !
You don't need to do it in one go, but over time it will be great for GUi debugging and bug reporting, start with this case .., but in the future you can add anything with compiler directives or without !, just keep expand on that and never delete them, you can't kno when they are needed.


Now to close look at the call stack :
It is all starts with TMyComboBox.Destroy and this is very strange case, here comes to mind that either the captured stack is limited or the reporting tool had failed, so you need more or longer stack as much as you can get, i have no experience with MadExcept but i know for sure EurekaLog will and can capture the stack no matter what size is it, as long it is not corrupted.

After this TMyComboBox.Destroy things get spicy, going through TElXPThemedControl, and this one although not familiar with by XP and theme trigger many memories for me, there was an is many software that hijack theming for windows or hook the interface for translation or whatever, these are the worst, worse than crazy and cheap AV, but this is not the case, and sorry for the ranting.
Back on the track, first thing to caught the eye the FreeAndNil, this is your code coming from TElSBController.Destroy, the FreeAndNil reach this one TElSBHandlerCustom to destroy and here the first of checkpoint and crucial one to follow in detail in you logging, (in case you took the advice on logging),
TElSBHandlerCustom.Destroy is blocking here in calling TElSBHandlerCustom.DestroyScrollTimer, so from what i see ScrollTimer responsible to destroy something (most likely TWomiTota), but instead of calling Free on it it send a message !
Now we can predict a path that can go wrong, remember that Windows in some cases can and might change the order of messages to deliver, also this information might not be relevant here, what is really relevant is this logic

Zitat:

00bae796 +05e My_Prog .exe Main 945 +14 TWomiTota.WndProc // another message
005c8118 +02c My_Prog.exe Vcl .Controls TWinControl.MainWndProc
00543edc +014 My_Prog.exe System.Classes StdWndProc
0040f6b0 +20c My_Prog.exe System 168 +0 DynArraySetLength
7751507b +04b ntdll.dll KiUserCallbackDispatcher
005c3f66 +2be My_Prog.exe Vcl.Controls TControl.WndProc
005c8b4b +63b My_Prog.exe Vcl.Controls TWinControl.WndProc
006ccc61 +64d My_Prog.exe Vcl.Forms TCustomForm.WndProc
00bae796 +05e My_Prog.exe Main 945 +14 TWomiTota.WndProc // a message handling coming form .Free somewhere, we except a cleaning up or just a notify

We are here from freeing TElSBHandlerCustom then DestroyScrollTimer

Your TWomiTota is sending message to either itself or to another instance of TWomiTota, while we are still handling the origin procedure of destroying TCustomElComboBox.Destroy.

Now after all of that, is SetFocus really the cause of this exception ?, most likely no, not directly responsible for it anyway and more like a victim here, but the faulty logic is there and it happens to fail on SetFocus.
What comes to mind and i had to ask : is there Application.ProcessMessages in any of the above walked code (orin a background thread), because if you are using it then i will blame it for this unpredictable behavior, Application.ProcessMessages is capable to generate nightmares.

What you really should do is debug or rethink how and why that code is sending message (namely this TWomiTota class may even be recursively) while it is in pending Destroying a simple combobox.

Hope that helps.


ps: in case you will build a logging system always add ThreadID to the lines, it will pay when needed.