1. Win32Lib Update
I've sent Robert the latest version of Win32Lib.
[The Good News]
The new code contains the bug fixes that should take care of the memory
leaks.
[The Bad News]
Prior code will *break* under the new version. In particular, I've created a
new event for handling the mouse:
onMouse( iEvent, iXPosition, iYPosition )
The iEvent values can be:
MOUSE_MOVE
LEFT_UP
LEFT_DOWN
LEFT_DOUBLECLICK
RIGHT_UP
RIGHT_DOWN
RIGHT_DOUBLECLICK
This makes the following routines obsolete:
onRightClick
onDoubleClick
With onMouse handling LEFT_DOWN, I can remove the {x,y} parameter from:
onClick()
to make it match VB. I can also remove:
onMenu()
since onClick() now handles that function - again, aligning it with VB.
[Feedback Time]
Instead of the onMouse routine, I could instead create:
onMouseMouse( iXPosition, iYPosition )
onMouseUp( iButton, iXPosition, iYPosition )
onMouseDown( iButton, iXPosition, iYPosition )
onMouseDoubleClick( iButton, iXPosition, iYPosition )
which is more in line with VB, or even:
onMouseMove( iXPosition, iYPosition )
onLeftUp( iXPosition, iYPosition )
onLeftDown( iXPosition, iYPosition )
onLeftDoubleClick( iXPosition, iYPosition )
onRightUp( iXPosition, iYPosition )
onRightDown( iXPosition, iYPosition )
onRightDoubleClick( iXPosition, iYPosition )
There is an addition parameter that I'm not yet including, which holds the
state of the Ctrl and Shift keys. I could include those as parameters, or
place them in a global variable.
What would people prefer?
-- David Cuny
2. Win32Lib Update
- Posted by Ad Rienks <Ad_Rienks at COMPUSERVE.COM>
Nov 26, 1998
-
Last edited Nov 27, 1998
A small bugling is showing up in getText. You add 1 to iLength to allocat=
e
buffer space. But iLength is used again thereafter. As it stands now, it
doesn't return the last text character. IMO the best solution is to add 1=
directly in the line where iLength is calculated for the first time. Then=
you don't have to bother about string sizes in the lines that follow it.
So, change the line that reads:
iLength =3D c_func(xGetWindowTextLength, {hWnd}) + 1 -- directly addi=
ng
1!
BTW, your header says it's version 0.14b
Ad
3. Win32Lib Update
The function reverse() is missing from v 0.15a.
Here's my attempt at a reverse() function. Before you start a new thread,=
I
know this one probably isn't the fastest and doesn't reverse sequences
within sequences.
But it is useful, short and clean, IMO.
---
function reverse(sequence x)
integer len
sequence temp
len =3D length(x)
temp =3D repeat("", len)
for n =3D 1 to len do
temp[n] =3D x[len - n + 1]
end for
return temp
end function
-- testing
sequence name
name =3D "Ad Reinks" -- misspelled
name =3D name[1..4] & reverse(name[5..6]) & name[7..9]
puts(1, name)
-- please, fix this bug too?
4. Re: Win32Lib Update
>The function reverse() is missing from v 0.15a.
>Here's my attempt at a reverse() function. Before you start a new thread, I
>know this one probably isn't the fastest and doesn't reverse sequences
>within sequences.
>But it is useful, short and clean, IMO.
Why not start a thread ? 
function reverse_flat (sequence s)
-- Reverses only the top level
sequence result
result = {}
for index = 1 to length(s) do
result = prepend(result, s[index])
end for
return result
end function
-- The above is the most clean and fastest, as far as I can tell.
function reverse (object x)
-- Reverses all levels in the sequence
sequence result
if atom (x) then
return x
end if
result = {}
for index = 1 to lenght(s) do
result = prepend (result, reverse (s[index]))
end for
return result
end function
-- This too is the fastest (and cleanest possible). I know I can avoid one
level of recursion, however Euphoria's
for-statement-block-containing-only-one-statement-optimization will be
missed. And for larger sequences (those who need the extra speed the most)
this will make a significant difference.
However, the above is all speculative, until some one starts benchmarking on
this.
Ralf
5. Win32Lib Update
I've sent Robert the latest version of Win32Lib. New controls, and fixes,
and changes that people have suggested over the past week.
I've also sent in a game called Stones. It's a clone of same-gnome from
Gnome, which in turn is a clone of same game from KDE. Not much of a
challange, but nice eye candy.
-- David Cuny
6. Win32Lib Update
It looks like the update to Win32Lib has been posted. It *should* take care
of the bugs that have been reported. Let me know if there are any remaining.
I've also sent Robert an update of the Design program, which now supports
menus. It probably won't be posted until late tomorrow.
-- David Cuny
7. Re: Win32Lib Update
- Posted by TheSkaMan0 at AOL.COM
Sep 15, 1999
David, how come I can't use onLoad anymore?
8. Re: Win32Lib Update
Hi,
I'm obviously not David, but I have an answer for you: onLoad was changed to
onOpen some releases back of win32lib.ew.
Hope this helps,
Judith
9. Re: Win32Lib Update
"TheSkaMan" wondered:
> David, how come I can't use onLoad anymore?
As Judith noted, it's now called onOpen. I *think* it was because onLoad
implied that the code was triggered only once happened (when the window was
'loaded'), instead of every time the window was displayed with openWindow().
-- David Cuny
10. Win32Lib Update
I've sent Robert the latest version of Win32Lib. Features include:
HTML documentation
Printing
Screen graphics bug fix
onPaint DC caching
getSelf corrected
Support for 24 bit bitmaps
For those who are interested, the bleeding edge edition at my site contains
a (rough) version of multiple windows for the IDE:
www.lanset.com/dcuny/win32.htm
I've also added a screen shot.
-- David Cuny
11. Win32Lib Update
- Posted by David Cuny <dcuny at LANSET.COM>
Dec 28, 1998
-
Last edited Dec 29, 1998
I've sent Robert the latest and greatest version of Win32Lib, which is
guaranteed to break all prior applications. 
There are a lot of changes, but the main one is changing the words "load"
and "unload" into "open" and "close". For example, "onLoad" is now "onOpen",
"unloadWindow" is now "closeWindow", and "closeWindow" is now
"minimizeWindow".
Apologies for the inconvenience (especially to Visual Win32Lib!), but the
old name was causing a bit of confusion. I almost went with "showWindow" and
"hideWindow", but it seemed a bit less natural (although more accurate).
I haven't had much chance to look at the programs, but kudos to Stephen
Spencer (Visual Win32Lib) and Ian Burleigh (Edith). They both look like
excellent programs.
-- David Cuny
12. Win32Lib Update
I've just sent Robert an update to Win32Lib. New features:
- Control text matches window background - finally!
- Controls built dynamically.
There are a number of other improvements, but they are mainly internal
changes - handling of tab stops, cleaning up old code, etc.
Please let me know if you encounter any bugs. Remember, it's still only in
Alpha. 
Thanks to everyone who's sent in bug reports and requests!
-- David Cuny
13. Win32Lib Update
I send Robert the latest version of Win32Lib (pre-Alpha 0.12). It adds more
graphics commands, edit functions (cut/copy/paste/clear/undo) and better
resource tracking (so there are less memory leaks). I've also restructured
the code a bit.
As always, feedback is welcome.
-- David Cuny
dcuny at lanset.com
14. Win32Lib Update
The latest version of Win32Lib is now posted at the Euphoria website.
Perhaps the most significant code changes have been made to the menus. Menus
now use the same function calls as the rest of the controls (create,
setCheck, isActive, etc.). Additionally, I have added simple support for
bitmaps.
Version 0.13 Alpha Main Features
--------------------------------
1. Menu bars and menu items use the create() function.
2. Menus use setCheck/setActive/isChecked/isActive.
3. Alter font, size and style of text in controls.
4. Load and display bitmaps.
5. Create monochrome bitmaps.
There are two new demos included to show off the graphic features.
Expect the graphic functions to undergo some changes in the future. At a
minimum, I need to get rid of the flicker that occurs on a screen refresh
(caused by having to redraw the entire screen). Additionally, I'd like to
support being able to write directly into bitmaps using the existing graphic
functions - something not currently supported.
As usual, feedback is appreciated.
-- David Cuny
15. Re: Win32Lib Update
- Posted by Isabel Navarrina <inavarrina at REDESTB.ES>
Oct 20, 1998
-
Last edited Oct 21, 1998
>3. Alter font, size and style of text in controls.
GREAT!!!!
Now it's time to upgrade all that socket demos...
Jesus-
16. Win32Lib Update
- Posted by David Cuny <dcuny at LANSET.COM>
Oct 23, 1998
-
Last edited Oct 24, 1998
I've just sent the latest version of Win32Lib to Robert. It includes a
number of bug fixes, as well as some new features.
As with the last update, this version will cause your old programs to break.
I try to keep this to a minimum, but sometimes it becomes clear that changes
have to be made. In this case, it's with the onPaint event.
This post is long, to explain a bit about Windows graphics, and how Win32
handles them, and what brought about the change. All this is subject to
change, but I figured that some sort of explanation would be helpful (we'll
see).
Prior versions of the event pass no parameters; the function prototype now
looks like:
Window_OnPaint( integer x1, integer y1, integer x2, integer y2 )
As you might imagine, the procedure now receives the area of the window that
needs to be updated. This is sometimes called the "damaged region" of the
window. Windows can be "damaged" by resizing, being obscured, and so forth.
Anyone who's tried it knows that programming Windows graphics is a bit
different than programming DOS graphics. In DOS, things you write to the
screen remain there. In Windows. areas of the screen can be "damaged" and
require repainting. So it's the job of the onPaint routine to repair any
damage to the window.
That means that onPaint needs to know how to draw *any* part of the window,
on demand. This usually requires that applications be written a bit
differently.
Prior versions forced the *entire* window to be updated with the call:
repaintWindow( iWin )
As you can imagine, this is more than a bit inefficient. I've added a new
procedure:
updateRect( iWin, integer x1, integer y1, integer x2, integer y2 )
No surprise here - the parameters that it passes are those received by the
onPaint procedure. I'm doing more than simply attaching parameters to the
onPaint routine, though. Windows had *always* passed a clipping window to
onPaint. It just happened that Win32Lib (though repaintWindow) always forced
it to be the same size as the window, so it could be ignored.
Note the words "clipping window" - this means that within the onPaint event,
there is no way to put graphics *outside* the clipping window (that's why
it's called a clipping window - graphics are clipped to the bounds of the
rectangle).
All this may seem a bit abstract, so I've created a couple of demos to show
off the features. One particular problem I encountered while writing the
code may help explain the issue. But first, some background (and details on
Win32Lib's inner workings):
If you have the 0.13 alpha version of Win32Lib, there is a tile demo (ex17)
that shows off the new createMonochromeBitmap() feature (which doesn't work
in NT, sorry). When a bitmap is clicked, the tile is "turned over". This is
how this is accomplished:
1. The array holding the bitmaps is updated.
2. repaintWindow() is called, to force the window to be redisplayed.
3. repaintWindow scans through the array, and redraws the all the bitmaps.
So the only routine that knows how to write to the window is onPaint.
You may notice that there is a bit of flickering as this happens.
When repaintWindow() is called, it tells Windows that the *entire* window is
damaged (see a couple of paragraphs back).
One of the things that Windows does automatically in onPaint is to repaint
the damaged portion of the window using the window's background color. Since
repaintWindow said that the *entire* window was damaged, the entire window
is erased, and you see a flash of white.
Then the onPaint routine is called, and it has to redraw *all* the tiles in
the window. This happens *every time* it needs to update the window. Very
inefficient, and very slow.
In the 0.14 version of Win32Lib, I've re-written the code to use
repaintRect() to pass the location of the bitmap that needs to be repainted.
Since only that portion of the window is erased, only that portion needs to
be redrawn. The result is a *much* cleaner.
Enough background. Both of the demos are modeled around the above process.
The only routine that does any writing to the window is the onPaint routine.
The other routines update data structures, and then tell onPaint what part
of the window needs to be drawn by calling updateRect.
Now onto the problem: I needed to write information to a "status line".
Initially, I just placed the line:
setPosition( Win, 1, 1 )
wPrintf( Win, "Score: %d", {score} )
into the onPaint routine. Much to my suprise, the text *didn't* show up.
That's because it didn't fall any of the the clipping rectangles that was
passed to onPaint. Since the text fell outside the clipping region, Windows
didn't bother to display it. I finally hacked a solution, by adding this
call *outside* of onPaint, whenever I wanted to redisplay the status line:
repaintRectangle( Win, 1, 1, 200, 20 )
This created a call to onPaint that "uncovered" the score.
There are better solutions to the above scenario, but I thought that people
might be interested in getting some feel for what graphics in Win32Lib looks
like in v0.14. I'm certain things will become better as time goes on...
Well, now people should have some idea why I haven't tried writing a
Win32Lib tutorial myself...
-- David Cuny
17. Win32Lib Update
- Posted by David Cuny <dcuny at LANSET.COM>
Aug 02, 1999
-
Last edited Aug 03, 1999
I've posted an update for Win32Lib. There are only some small changes -
drawPolygon is fixed, and setIcon is changed.
David Ouderdorp suggested the change to setIcon, noting that the current
version is incompatible with WinNT. The fix no longer allows icons to be
associated with Icon objects, but you can attach them to Windows. I figured
that was what most people wanted to do with the routine anyway. If someone
has a better fix, I'd be happy to hear it.
-- David Cuny
18. Re: Win32Lib Update
On Mon, 2 Aug 1999 21:18:53 -0700, David Cuny <dcuny at LANSET.COM> wrote:
>David Ouderdorp suggested the change to setIcon, noting that the current
>version is incompatible with WinNT. The fix no longer allows icons to be
>associated with Icon objects, but you can attach them to Windows.
It doesn't work at all. You made a mistake. The first parameter of
ExtractIcon must be the instance handle. Not the handle of the control.
19. Re: Win32Lib Update
On Wed, 4 Aug 1999 09:24:51 -0400, David Ouderdorp <davidfant at DOLFIJN.NL>
wrote:
>It doesn't work at all.
Sorry. Only ex14.exw doesn't work. But better still fix that mistake.
20. Re: Win32Lib Update
David Ouderdorp wrote:
>Sorry. Only ex14.exw doesn't work.
That's right - just like the documentation says. I can associate the icon
with a Window, but not with an Icon. At least, it seemed to work on my
machine.
-- David Cuny
21. Win32Lib Update
I've sent Win32Lib v.30 to Robert. It takes care of a number of graphics
bugs, and adds the ability to open windows in normal, maximized, minimized
or modal states. This will cause pre-existing code to break, but the fix is
trivial.
The feature list:
- added style parameter to WinMain()
- added style parameter to openWindow()
- fixed Brown and Yellow color constants
- graphics calls work correctly when fill flag is zero (no fill)
I'm also finally working on design.exw, my Win32Lib IDE. It's still in
pre-alpha stage, but you can now drag and resize controls in the window. I
hope to add more features in the near future.
I'm a bit stuck on some points in GtkLib. Anyone out there have any
experience with GTK?
Thanks!
-- David Cuny
22. Win32Lib Update
I've sent Robert the latest release of Win32Lib, v0.31. Features include:
- Tabs work in MleText (use Ctrl+Alt to exit)
- Tabs work in Combos
- onClose works for child windows
It also has the latest public release of design.exw, my Win32Lib window
designer. It's got enough features to perhaps be useful. You can design
windows, add code, and generate EXW files. It also saves PRJ files, so you
can re-edit designs without having to start from scratch.
-- David Cuny
23. Win32Lib Update
I've posted a minor update to Win32Lib, v0.31a.
It's actually only an update to the Design program that comes along with it.
I borrowed a couple of ideas from other IDEs (including VB 6), and I think
it looks a *whole* lot better than the original.
Features include:
- visual screen design (moving and resizing)
- integrated design window (emulated button bar)
- save both source code and project file
- execute projects from ide
There are still a number of missing features (menu editor, error
integration, missing controls, multiple windows), but I think it's taking a
look at.
Feedback is appreciated.
Thanks!
-- David Cuny
