1. RE: Win32Lib bug
David Cuny wrote:
> Derek Parnell wrote:
>
> > I'll check it out tonight. Can't think of
> > anything of hand that would have targeted
> > pixmap behaviour.
>
> I'm guessing that there used to be a test on the pixmaps that checked
> for
> nulls. That was probably removed, and replaced with an error check
> routine.
>
> Another possibility is that the order of execution has been changed
> slightly, so it tries to paint the window before setting up the pixmap.
>
> In any event, I've posted the new Minesweeper clone on my site. Thanks
> to
> Brian Broker for the updated version! The source is included with the
> install:
>
> http://www.lanset.com/dcuny/home.htm
>
> If you change the 10's in the Pixmap declaration to zeros, you'll see
> the
> behavior.
>
> Thanks!
>
> -- David Cuny
This is interesting news because I've recently reconnected with Gabriel
Boehme to polish off that port of your Mines game that he and I had
started over a year ago. It really kicks butt and my fiancee loves it
but real-life issues that developed with both of us stopped the project
before near-completion. My next step was to update using the current
version of Win32Lib, finish up the program, and make a help file.
Unfortunately, I'm still getting sidetracked with 'real-life' issues and
other unrelated projects but I appreciate the "heads-up".
-- Brian
2. RE: Win32Lib bug
> -----Original Message-----
> From: Robert Craig [mailto:rds at RapidEuphoria.com]
> While testing the beta release translator,
> I came across a bug in Win32Lib.ew.
>
> There are a couple of places where the
> Windows API routines ChildWindowFromPoint() and
> ChildWindowFromPointEx() are called incorrectly.
>
> The second argument is supposed to be a POINT structure.
> Euphoria does not allow you to pass a C structure by
> value. You can only pass the address of a structure.
> In Win32Lib.ew an attempt is made to pass the *address*
> of a POINT structure, but this is not what the C routine expects.
Weird--never even occured to me. That explains why I had so much trouble
with it. However, while the latest version (0.51.1) registers
ChildWindowFromPoint/Ex, it should never call the function (apps might do so
themselves). Derek found another method to find children windows.
We'll have to update the register call, though...
Thanks,
Matt Lewis
3. RE: Win32Lib bug
>-----Original Message-----
>From: Robert Craig [mailto:rds at RapidEuphoria.com]
>Sent: Thursday, February 15, 2001 5:47 AM
>To: EUforum
>Subject: Win32Lib bug
>
>
>While testing the beta release translator,
>I came across a bug in Win32Lib.ew.
>
>There are a couple of places where the
>Windows API routines ChildWindowFromPoint() and
>ChildWindowFromPointEx() are called incorrectly.
>
>The second argument is supposed to be a POINT structure.
Thanks Robert,
this problem with ChildWindowFromPoint had all of us perplexed. I didn't
even suspect a structure needed to be passed! I read the WinAPI manual so
many times and completely glossed over that very important detail. Its a
moot point now because the latest version(s) of the library do not use this
method of getting a child window's hWnd but maybe I could now reinstate this
method.
-----
cheers,
Derek Parnell
4. RE: Win32Lib bug
> From: CK Lester [mailto:cklester at yahoo.com]
> Has Judith made sure the IDE is fixed in this regard?
>
> > Hopefully this is the demise of the eternal combo-box bug
> > that has been plagueing the IDE propbox and tab-control/combo
> > box combinations for a long time.
This shouldn't be an issue anymore. As I mentioned earlier, in v0.51.1 of
Win32Lib, ChildWindowFromPoint is no longer called. I think Rob must have
used an old version of Win32Lib with the IDE, in which ChildWindowFromPoint
was called from createEx. Derek changed this some time ago to a call to
GetWindow.
If you are using an old version of Win32Lib, you'll want to change the
linkFunc and c_func calls to reflect the calling convention Rob suggested
(do a search in Win32Lib for ChildWindowFromPoint/Ex).
Matt Lewis
