1. Win32Lib Combo / Tabs
I've been working with Euman on his problems with getting tab stops into
combo boxes. I first traced the problem to database.e. Now I've determined
that any time some memory is allocated and not freed before the combo's are
created, the ChildWindowFromPointEx call fails. It also fails whenever the
trace window comes up before the combos are created.
As a work around, it seems fairly simple, in this case, to move the include
back (it doesn't matter where in the code the memory is allocated, just as
long as you don't free it), but if someone happens to be dynamically
creating controls, this will be a problem.
Rob (or anyone else), can you tell why this might happen? I have no idea
why this happens or how to fix it.
Matt Lewis
2. Re: Win32Lib Combo / Tabs
- Posted by Robert Craig <rds at ATTCANADA.NET>
Oct 02, 2000
-
Last edited Oct 03, 2000
Matthew Lewis writes:
> Now I've determined that any time some memory is allocated
> and not freed before the combo's are created, the
> ChildWindowFromPointEx call fails. It also fails whenever
> the trace window comes up before the combos are created.
> ...
> Rob (or anyone else), can you tell why this might happen?
First, copy euphoria\include\safe.e into the current directory,
and rename it as machine.e. Then run your program a few times,
in various ways, and see if safe.e catches anything.
If safe.e doesn't catch anything, send me the code
and I'll look into it.
Thanks,
Rob Craig
Rapid Deployment Software
http://www.RapidEuphoria.com
3. Re: Win32Lib Combo / Tabs
> I've been working with Euman on his problems with getting tab stops into
> combo boxes. I first traced the problem to database.e. Now I've
determined
> that any time some memory is allocated and not freed before the combo's are
> created, the ChildWindowFromPointEx call fails. It also fails whenever the
> trace window comes up before the combos are created.
Actually, this seems to fail whenever conagent.exe is running in the
foreground...
( ... noticed it failed every time safe.e is used, thanks Rob, 
)
... because the win32lib code uses CWP_SKIPTRANSPARENT, it is probably trying
to get the handle of the DOS box... and failing !
... which occurs in trace mode, or when using safe.e, or if another DOS box
is open because we're using something like printf(1,... , or ?... in our
code ???
Wolf
4. Re: Win32Lib Combo / Tabs
Robert Craig wrote
> First, copy euphoria\include\safe.e into the current directory,
> and rename it as machine.e. Then run your program a few times,
> in various ways, and see if safe.e catches anything.
>
> If safe.e doesn't catch anything, send me the code
> and I'll look into it.
I've tried that, and I've found a problem with using safe.e with windows.
Sometimes, you get handed a pointer from the OS (which won't be logged in
safe.e) such as NMHDR structures in WM_NOTIFY messages. safe.e tells me
I've got a 'Bad peek4s address', which isn't really true, of course.
However, I've done some more extensive testing, and I can't see a reason why
the call to ChildWindowFromPointEx should fail. It's not simply an open dos
box, although it does fail if the trace screen has been activated. And it
fails with safe.e (but no errors are reported by safe.e). I don't
understand why this should be, unless safe.e allocates some memory on it's
own (very possible--I didn't really examine safe.e too carefully) that isn't
freed before the controls are created.
It only takes a tiny bit of code to test:
-- Begin combo.exw
include win32lib.ew -- v0.53
constant
Win = create( Window, "Main Window", 0, 0, 0, 500, 500, 0),
WinCombo1 = create( Combo, "Combo", Win, 10, 20, 90, 90, 0),
WinCombo2 = create( Combo, "Combo", Win, 10, 60, 90, 90, 0)
WinMain( Win, Normal )
-- End combo.exw
For debugging purposes, I added a print at line 10174 of win32lib:
? hWnd
Whenever there's been an allocation or trace, hWnd will be 0. According to
MS, this should only happen when the point is outside of the parent
specified in the call to ChildWindowFromPointEx. That's clearly not what's
going on here, since the same point (0,0) is used successfully. I haven't
noticed any other API calls that are as selective as these (maybe someone
else has), so I have no idea what the problem is. Maybe someone (Rob?)
could try compiling the code to C to see if this still happens? I'd try it,
but I don't have Watcom. :)
Matt Lewis
