In reply to your message of August 30, 2003
> Something else. But I think you are on the wrong track with HWND.
This is a possibility I've considered. It might be something else entirely...
but it is definately something related to my program...
Another possibility, and one I've tested for, is that there are problems with
my proggy picking up window messages it's not supposed to... but commenting
out the suspect code did nothing to improve the situation.
> What you could do is increase the granularity of windows API checking.
> I'm no Windows hero, but the WinAPI must have some checking (return values,
> a function like GetLastWinError or something), and try to check that after
> _each_ winapi call.
Every winapi call has a return value, which can indicate error states. I
check every single one of them and produce message boxes for them all. The
one thing I did learn from my earlier programming experience is that ignoring
errors is how you get yourself into trouble...
Here's a code fragment showing what I mean:
//register the main window
With MDRClass do
begin
Style := cs_hRedraw or cs_vRedraw; // Set styles
lpfnWndProc := @MainProc; // point to main procedure
cbClsExtra := 0; // no extra class space
cbWndExtra := 0; // no extra window space
hInstance := MDRProg; // main program handle
hIcon := loadicon(MDRprog,'AppIcon');// title bar icon
hCursor := 0; // use standard cursor
hbrBackground := 1 + COLOR_BTNFACE; // background colour
lpszMenuName := nil; // no predefined menus
lpszClassName := 'mdrplay'; // text name of class
end;
if RegisterClass(MDRClass) < 1 then
begin
MessageBox(0, 'Main window registration failed',
'Fatal', mb_Ok or mb_iconstop);
Halt(0);
end;
Every Api call is done like this... But I'm not getting my descriptive little
message boxes... all I get is either Range Check errors (201 followed by
dozens of references) or the screen scattering effect I've already described.
All my programs are compiled with range, stack and overflow checking
enabled... that's how I found the bad declarations in the windows unit.
> This is an approach that works both when you are wrong about HWND, (and it
> is something else) but also if I'm wrong and it is HWND.
Yep... it certainly should. This is what's leading me to believe the problem
is someplace beyond the reach of any error trapping I might personally
enact... someplace far more intimate to FP than my code.
> If somewhere something corrupted is delivered to the winapi, there is a fair
> chance the winapi will give some errorcode back, sooner or later.
In a weird way it does... when things go strange, it mangles my desktop
scattering bits of the program all over the place... The window frame will
draw in the top left corner, the "menu context" numbers will appear on the
button faces, the title bars disappear, etc. But only on this one program,
which is written in FP. The program itself continues running and will still
do most things if I estimate button locations... it's only the visual aspect
of it that gets mangled... which is how I first concluded it was a redraw
problem involving handles.
-----
L D Blake
_______________________________________________
fpc-pascal maillist - [EMAIL PROTECTED]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
