1. Win32Lib bug
- Posted by Michael Sabal <mjs at OSA.ATT.NE.JP>
Nov 14, 1998
-
Last edited Nov 15, 1998
I don't know if this is what's causing the crash, but there is a problem =
with the program ex06.exw shared earlier today. In the show_it() =
procedure, list1 changes its state with the setText(..) procedure. This =
triggers and onChange event which calls show_it() looping continuously. =
Now, by my logic, this problem would cause a memory overflow or infinite =
loop and would thus be easy to track down. However, there is a problem =
with setText as reported in the documentation. The list is a sequence =
(thus in C, a structure). Because structures are sent to Windows =
manually, and not by Euphoria with a list box, there are a few =
possibilities I can see (but I'm sure they've already been tried):
1. The new structure is not being set on a 4-byte boundary (Windows =
law).
2. The new structure IS being set on a 4-byte boundary that's already =
occupied.
3. The list structure is exceeding the size of a page (usually 64K) by =
starting in the middle of it.
4. The new structure is longer than the allocated space for this =
structure.
With all the other structures used in Win32Lib, I think they are pretty =
static (watch me put my foot in my mouth :)), but to define the contents =
of a list box/combo box, we need a dynamic structure. Does this have =
anything to do with it?
Michael J. Sabal
mjs at osa.att.ne.jp
http://home.att.ne.jp/gold/mjs/index.html
2. Win32Lib bug
Michael Sabal wrote:
>I don't know if this is what's causing the crash, but there is a problem=
with the >program ex06.exw shared earlier today. In the show_it()
procedure, list1 changes >its state with the setText(..) procedure. This=
triggers and onChange event which >calls show_it() looping continuously.
I don't understand what you mean; the show_it() procedure is not affectin=
g
the list.
I've rewritten the code so the procedure show_it isn't even necessary.
-- Begin code
global procedure onChange_List1()
-- list item will be shown in the static line.
integer what
what =3D getIndex(List1)
if what >=3D 0 then
setText(Label1, getItem(List1, what))
end if
end procedure -- onChange_List1
-- End code
I can't see an infinite loop here. The onChange[] method can also be
rewritten as an onClick, onDoubleClick or onKeyPress method, maybe even a=
s
an onEvent method. The latter one I haven't tried yet. But in all these
cases, the problem keeps coming back. Maybe I can also have a go at tryin=
g
it without any method affecting the listbox.
But, maybe your guess about the allocation of structures is correct. For
the moment, that's too difficult for me, and I'll leave it to the real
gurus (David, Robert, ?).
>Now, by my logic, this problem would cause a memory overflow or infinite=
loop and >would thus be easy to track down. However, there is a problem
with setText as >reported in the documentation. The list is a sequence
(thus in C, a structure). >Because structures are sent to Windows
manually, and not by Euphoria with a list >box, there are a few
possibilities I can see (but I'm sure they've already been tried):
>1. The new structure is not being set on a 4-byte boundary (Windows law)=
.
>2. The new structure IS being set on a 4-byte boundary that's already
occupied.
>3. The list structure is exceeding the size of a page (usually 64K) by
starting in the >middle of it.
>4. The new structure is longer than the allocated space for this
structure.
>With all the other structures used in Win32Lib, I think they are pretty
static (watch >me put my foot in my mouth :)), but to define the contents=
of a list box/combo box, >we need a dynamic structure. Does this have
anything to do with it?
Maybe yes!
>Michael J. Sabal
>mjs at osa.att.ne.jp
>http://home.att.ne.jp/gold/mjs/index.html
Regards and thanks,
Ad Rienks
3. Re: Win32Lib bug
Ad Rienks, you are correct - there is still a bug in win32lib.ew.
I re-installed v2.0 and found that the original code
that you posted still dies when a 12-character string
is entered and clicked on. The code you posted
a few days later is what I debugged, and it seems to work fine now
along with every other example I've tried.
I'm almost certain there is another undersized data structure
lurking in win32lib.ew. I temporarily modified allocate()
in machine.e to always give the user 100 bytes more than he
asks for, and the 12-character bug went away. Furthermore,
I've found that heap corruption occurs in this program when
the extra 100 bytes are not provided. (maybe less than 100
would work - I didn't try).
David, maybe you can ask yourself which structures are used
in the following code, that aren't used in your other examples.
You might not be allocating quite enough space for them.
include win32lib.ew
constant
Win = create( Window, "List ++", 0, Default, Default, 160, 170, 0 ),
List1 = create( List, "", Win, 10, 10, 120, 60, 0 ),
Label1 = create(RText, "", Win, 10, 60, 120, 20, 0),
Sle1 = create( EditText, "", Win, 10, 80, 110, 20, 0 ),
Button1 = create( PushButton, "ADD", Win, 70, 110, 60, 20, 0 )
procedure onLoad_Win()
-- add these items to the list-box
addItem( List1, "one" )
addItem( List1, "two" )
addItem( List1, "three" )
addItem( List1, "four" )
setIndex(List1,0)
setFocus(Sle1)
end procedure
procedure show_it(integer here)
-- show the selected list item in the text window.
sequence this
this=getItem(List1,here)
setText(Label1, this)
end procedure
procedure onChange_List1()
-- get the latest index from the list-box, then show it.
atom where
where=getIndex(List1)
show_it(where)
end procedure
procedure onClick_Button1( integer mouseX, integer mouseY )
sequence entry
entry = getText( Sle1 )
addItem( List1, entry )
setText(Sle1, {} )
setFocus(Sle1)
end procedure
onLoad[ Win ] = routine_id( "onLoad_Win" )
onChange[List1] = routine_id("onChange_List1")
onClick[ Button1 ] = routine_id("onClick_Button1")
WinMain( Win )
Regards,
Rob Craig
Rapid Deployment Software
http://members.aol.com/FilesEu/
4. Re: Win32Lib bug
- Posted by David Cuny <dcuny at LANSET.COM>
Nov 19, 1998
-
Last edited Nov 20, 1998
Robert Craig wrote:
>David, maybe you can ask yourself which structures are used
>in the following code, that aren't used in your other examples.
>You might not be allocating quite enough space for them.
Thanks. I'll try to go over the code some time this weekend.
-- David Cuny
5. Re: Win32Lib bug
I've found the cause of the 12-character string bug in win32lib.ew.
Using an enhanced version of safe.e, it was easy to locate.
In getItem() we have:
iLength = sendMessage( id, msg, item, 0 )
-- extra line I added:
iLength = iLength+1 -- temporary fix, - David?
-- NEW! 0.14c
if iLength = 0 then
warnErr( "Get item text length is zero." )
return ""
end if
-- allocate a buffer
buffer = allocate( iLength ) -- not quite enough space!
-- get the message, based on control type
if window_class[ id ] = LISTBOX then msg = LB_GETTEXT
elsif window_class[ id ] = COMBO then msg = CB_GETLBTEXT
end if
-- move the text to a buffer
ok = sendMessage( id, msg, item, buffer )
I found that the buffer allocated above was one character too small.
It did not allow for the 0 that C always adds to strings (but Euphoria
doesn't require). As a result, Windows would write the extra 0, sometimes
corrupting the next block of storage. If the string was an exact multiple
of 4 in length (such as 12) then Euphoria would allocate exactly the
number of bytes requested, but if it wasn't, Euphoria would round up
to the next multiple of 4 bytes, thereby protecting against the extra 0.
Maybe the fix should just be:
buffer = allocate(iLength+1)
instead. I don't know. David should consider it.
There are other calls to SendMessage that should also be checked.
* * *
safe.e:
I've enhanced safe.e to make detection of these errors much easier.
safe.e now allocates extra space before and after each block that
you allocate and fills it with a known pattern. This makes it possible
to check for blocks of memory where data has been written just
before or just after the allocated block. Euphoria code can't
write out of bounds, because of safe.e checks in poke, mem_copy etc.,
but machine code, or Windows can do it.
Regards,
Rob Craig
Rapid Deployment Software
http://members.aol.com/FilesEu/
6. Re: Win32Lib bug
Robert Craig wrote:
> I've found the cause of the 12-character string
> bug in win32lib.ew.
...
> iLength = iLength+1
When you mentioned that you changed allocate() and it got rid of the bug, I
had a suspicion that under-allocated strings were the culprit - especially
after I went through the structures and didn't see any more that seemed
under-allocated.
I'll look at the invocations of allot, allocate, fetch and store, and make
sure they are all accounting for the extra byte.
I also need to make another pass through the structures. The structures from
the VB file don't take into account your suggested fix. That puts them in
doubt, so I'm also am going through the Win32 help file, checking for arrays
and other items which might not be accounted for in the VB API listing.
Thanks again!
-- David Cuny
7. Re: Win32Lib bug
Robert Craig wrote:
> Maybe the fix should just be:
> buffer = allocate(iLength+1)
This is a better fix; I've adjusted the code in getText (which *did* account
for the '/0') to look the same. The other major changes in the next release
are:
increased size of PAINTSTRUCT
increased the size of the LOGPALETTE
increased size of BITMAPINFO
changed structure name WNDCLASS to WNDCLASSEX
increased iLength size in getItem
These should *hopefully* correct some of the problems in Win32Lib. I'll try
to get a posting of the 0.15 version out later today.
Thanks again for all your help!
-- David Cuny
8. Re: Win32Lib bug
Hey! That's why that password program was screwing up!!!
> Robert Craig wrote:
>
> > Maybe the fix should just be:
> > buffer = allocate(iLength+1)
>
> This is a better fix; I've adjusted the code in getText (which *did* account
> for the '/0') to look the same. The other major changes in the next release
> are:
>
> increased size of PAINTSTRUCT
> increased the size of the LOGPALETTE
> increased size of BITMAPINFO
> changed structure name WNDCLASS to WNDCLASSEX
> increased iLength size in getItem
>
> These should *hopefully* correct some of the problems in Win32Lib. I'll try
> to get a posting of the 0.15 version out later today.
>
> Thanks again for all your help!
>
> -- David Cuny
>
--
James Begley
We're all stars now.
9. Win32Lib bug
- Posted by David Cuny <dcuny at LANSET.COM>
Mar 30, 2001
-
Last edited Mar 31, 2001
I ran into a problem porting my Minesweeper clone to the latest version of
Win32Lib. It's also tripped me up with other games I've written. The problem
is that Win32Lib doesn't allow the creation of zero-sized pixmaps.
In a number of my programs, I would 'create' a zero-sized pixmap as a
placeholder, and later replace it with a 'real' pixmap once I had calculated
the pixmap.
In the old version of Win32Lib, you could create a zero-sized pixmap, and
the library would just set the handle to null. Resizing a 'real' pixmap
would discard the old version and replace it with a new version. Resizing a
'null' pixmap should simply create a new pixmap, and ignore the old value.
The behaviour in the current release is a bit different. I can create the
zero-sized pixmap, but I can't resize it. So when I try drawing to it later
(after it's been resized) I get lots of errors, and no image.
Other than identifying the general problem, I haven't bothered to find out
what has changed, or why. The temporary fix is to create a non-zero sized
pixmap. But I'm still curious how the behavior changed, and why.
Thanks!
-- David Cuny
10. Re: Win32Lib bug
I'll check it out tonight. Can't think of anything of hand that wold have
targeted pixmap behaviour. I remember testing the Black Box games etc and
they all worked fine though. In the new v0.56 I had to move some
initialization out of the onOpen handler to the new onActivate handler but
that was all.
------
Derek Parnell
Melbourne, Australia
"To finish a job quickly, go slower."
----- Original Message -----
From: "David Cuny" <dcuny at LANSET.COM>
To: "EUforum" <EUforum at topica.com>
Sent: Saturday, March 31, 2001 5:32 PM
Subject: Win32Lib bug
>
>
> I ran into a problem porting my Minesweeper clone to the latest version of
> Win32Lib. It's also tripped me up with other games I've written. The
problem
> is that Win32Lib doesn't allow the creation of zero-sized pixmaps.
>
> In a number of my programs, I would 'create' a zero-sized pixmap as a
> placeholder, and later replace it with a 'real' pixmap once I had
calculated
> the pixmap.
>
> In the old version of Win32Lib, you could create a zero-sized pixmap, and
> the library would just set the handle to null. Resizing a 'real' pixmap
> would discard the old version and replace it with a new version. Resizing
a
> 'null' pixmap should simply create a new pixmap, and ignore the old value.
>
> The behaviour in the current release is a bit different. I can create the
> zero-sized pixmap, but I can't resize it. So when I try drawing to it
later
> (after it's been resized) I get lots of errors, and no image.
>
> Other than identifying the general problem, I haven't bothered to find out
> what has changed, or why. The temporary fix is to create a non-zero sized
> pixmap. But I'm still curious how the behavior changed, and why.
>
> Thanks!
>
> -- David Cuny
>
>
>
>
11. Re: Win32Lib bug
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
12. Re: Win32Lib bug
Okay, I tracked this one down.
If a Pixmap is created with a size of 0,0 then win32lib does not actually
create one, instead it flags the internal structures for the pixmap with an
special invalid hWnd value. Later, in a couple of places, if an invalid ID
is passed to a routine, the routine assumes that its not actually an ID but
a hWnd to a bitmap instead. There are further checks in the library to cater
for PIXMAPs with the special invalid hWnd, but these are only used if the
"invalid id" test fails.
The recent changes to win32lib has tightened up on what constitutes an
invalid ID. This means that the previous trick of delaying the pixmap
creation using a 0,0 size now causes these Pixmap ids to be detected as
"invalid". The library would then assume that they were bitmaps instead,
thus the errors would be reported.
I've fixed the library (v0.56) to use a different special invalid hWnd value
that no longer triggers the invalid id test.
What I'm not sure about is why bother? Why bother to not create a 0,0 sized
pixmap? What does it gain? The other way I could have fixed this was to not
take any special action for pixmaps of 0,0 size, just go ahead a create one
anyway. This worked fine.
------
Derek Parnell
Melbourne, Australia
"To finish a job quickly, go slower."
----- Original Message -----
From: "David Cuny" <dcuny at LANSET.COM>
To: "EUforum" <EUforum at topica.com>
Sent: Saturday, March 31, 2001 9:08 PM
Subject: Re: Win32Lib bug
>
>
> 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
>
>
>
>
13. Re: Win32Lib bug
Derek Parnell wrote:
> What I'm not sure about is why bother? Why bother to
> not create a 0,0 sized pixmap? What does it gain?
You're right, of course. I was hoping to save some resources, but this gets
rid of the special handling for empty pixmaps, which would make the code
much cleaner and easier to maintain.
Thanks!
-- David Cuny
14. Re: Win32Lib bug
Brian Broker wrote:
> 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.
Please post it when it's ready! Thanks again. 
-- David Cuny
15. 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.
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.
typedef struct {
LONG x;
LONG y;
} POINT;
What you should do, is define an extra argument for these
routines in define_c_func(), and pass the two fields
of the POINT structure as if they were separate arguments.
something like:
ChildWindowFromPoint(handle, x, y)
This will push the values of x and y onto the call stack just like
a POINT structure would be pushed, when passed by value.
There may be other cases in Win32Lib where
it's necessary to pass a structure by value, but I
believe this not very common in the WIN32 API.
Regards,
Rob Craig
Rapid Deployment Software
http://www.RapidEuphoria.com
16. Re: Win32Lib bug
Matt Lewis writes:
> However, while the latest version (0.51.1) registers
> ChildWindowFromPoint/Ex, it should never
> call the function (apps might do so themselves).
I was testing Judith's IDE, and ChildWindowFromPointEx
was called via these calls:
..
WinList = create( Combo, "", Tools, 323, 2, 160, 32*6, 0 ),
TheTabItemCombo = create( Combo, "", Tools, 485, 2, 160, 32*6, 0 ),
..
The exw interpreter seemed to run ide.exw ok, as did the
translated C code compiled by Watcom or Lcc.
Only when I compiled with Borland did it crash.
Something on the call stack got corrupted as a result
of the incorrect C call using Borland. After fixing the call
in the way I described, ide.exw runs fine now
with the interpreter, Watcom, Lcc and Borland.
So I guess I'll be ready to release the beta translator soon.
Regards,
Rob Craig
Rapid Deployment Software
http://www.RapidEuphoria.com
17. Re: Win32Lib bug
At 12:05 14/02/01 -0800, you wrote:
>Matt Lewis writes:
>> However, while the latest version (0.51.1) registers
>> ChildWindowFromPoint/Ex, it should never
>> call the function (apps might do so themselves).
>
>I was testing Judith's IDE, and ChildWindowFromPointEx
>was called via these calls:
>...
> WinList = create( Combo, "", Tools, 323, 2, 160, 32*6, 0 ),
> TheTabItemCombo = create( Combo, "", Tools, 485, 2, 160, 32*6, 0 ),
>...
Halalujah!
Hopefully this is the demise of the eteranal combo-box bug
that has been plagueing the IDE propbox and tab-control/combo
box combinations for a long time.
Graeme
18. Re: Win32Lib bug
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.
