1. Win32Lib Combo / Tabs
- Posted by Matthew Lewis <MatthewL at KAPCOUSA.COM> Oct 02, 2000
- 339 views
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
- 341 views
- 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
- Posted by wolfgang fritz <wolfritz at king.igs.net> Oct 03, 2000
- 359 views
> 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
- Posted by Matthew Lewis <MatthewL at KAPCOUSA.COM> Oct 03, 2000
- 339 views
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