A private VCL application crashes, rarely and apparently spontaneously, and I strongly suspect that this is because the main form window handler is recreated in response to some external trigger from the operating system.
I know for sure that if the window handle of the main form changed, then, of course, there would be a problem (because background threads send messages to this handle).
But I would like to know how to reproduce this error before I begin to make code changes to fix it, if only because I can confirm that this is a plausible cause of the failure, that the symptoms are consistent with the messages, and that the code changes are indeed correct him. (Also, if the OS cannot call TCustomForm.RecreateWnd , I need to find another explanation for the failures. Yes, I could send CM_RECREATEWND to the main form, but that just asks the question.)
(I know that the correct way to send messages from background threads to a VCL stream is to create a hidden message box just for this purpose with AllocateHWnd - this is my suggested fix.)
I saw a similar error with a descendant of TCustomListView , where RecreateWnd started by changing the desktop style from Windows XP to Windows Classic. But I have not yet been able to find such a method to run RecreateWnd on TCustomForm . (I spent a considerable amount of time reading VCL code, and I must be missing something.)
Summary:
Under what incentives TCustomForm VCL end up calling RecreateWnd on TCustomForm ? (I'm especially interested in Windows 7, if that matters.)
If there is such a stimulus from the OS, I can prove whether this causes the observed symptoms. If not, then I can prove that the window is not the cause.
windows delphi delphi-xe2
Ian goldby
source share