1. win32lib.ew .41
David,
These are problems I've encountered in my programs between version .40 and
.41 of win32lib.ew.
1. A getFontSize function on MainWindow gets a type check on the atom saved.
Does this on any font I may have used in a prior setFont. Also if I do not
do a setFont at all.
2. This one is a bit hard to describe but here goes....
Enter program MainWindow. LText field prints normally, switch to a
secondardy window and LText fields and radial button text have text in dark
green background box (my button color is green but not THAT green). When I
return to the MainWindow the LText field there is now ALSO in a dark green
background box.
3. The above senario also happens if the secondary window contains a list
in which case every item in the list appears in a dark green background box.
4. I move my mouse into a list field -- program fails (I do not have
registered copy and this program > 300 stmts).
I have onMouse[listfield] routine and in that routine my first
statement is to check for LEFT_DOUBLECLICK. I put in a message_box right
before the if event=LEFT_DOUBLECLICK to try to find out where the error is
located. I do not get the message_box so this is something to do with the
onMouse itself?. This also happens in several other programs.
Judith Evans
2. Re: win32lib.ew .41
Judith Evans writes:
<slew of bugs in Win32Lib 4.1>
Argh. I'll see what can be done.
Thanks, and sorry for any inconvenience.
-- David Cuny
3. Re: win32lib.ew .41
In thinking about the problems Judith encountered with the latest release of
Win32Lib, I'm not sure what to do. I test the code before posting it, but
obviously bugs get through, especially when new features have been added.
Perhaps I should designate two versions of Win32Lib - an older, "stable"
version, and the "most recent" version. That way, if people run into major
problems with a new release, they could easily fall back on an older
version. Otherwise, I guess I'd have to start using beta testers - that
requires the kind of coordination that I just don't have the time or energy
for.
Robert, is this possible?
Thanks!
-- David Cuny
4. Re: win32lib.ew .41
David-
I'm sure that Robert would be able to accomodate your request but on the
other hand, I would be more than happy to help coordinate a Win32Lib bug
bashing site and relay bug specifics (or fixes if possible).
Just a thought. I'd like to do what I can to contribute...
-- Brian
On Fri, 10 Sep 1999, Cuny, David wrote:
> Perhaps I should designate two versions of Win32Lib - an older, "stable"
> version, and the "most recent" version. That way, if people run into major
> problems with a new release, they could easily fall back on an older
> version. Otherwise, I guess I'd have to start using beta testers - that
> requires the kind of coordination that I just don't have the time or energy
> for.
>
> Robert, is this possible?
>
> Thanks!
>
5. Re: win32lib.ew .41
- Posted by Robert Craig <rds at ATTCANADA.NET>
Sep 10, 1999
-
Last edited Sep 11, 1999
David Cuny writes:
> Perhaps I should designate two versions of Win32Lib
> - an older, "stable" version, and the "most recent" version.
Sounds good to me.
Maybe the bleeding edge version would have an
entry in Recent User Contributions, and the
stable version would have an entry in Archive/WIN32 files.
The two entries would point to each other.
Whenever you felt that the bleeding edge version was
stable enough, you could tell me to copy the file to
the Archive section.
You could also set up your own Web page.
(there are tons of free sites around.)
That would allow you to communicate better
with your users.
Regards,
Rob Craig
Rapid Deployment Software
http://www.RapidEuphoria.com
6. Re: win32lib.ew .41
Robert Craig wrote:
>Sounds good to me.
Great.
>You could also set up your own Web page.
I've got a site with my account; I guess I could make a stab at it.
-- David Cuny
7. Re: win32lib.ew .41
- Posted by simulat <simulat at INTERGATE.BC.CA>
Sep 10, 1999
-
Last edited Sep 11, 1999
Just a thought - why not use the Linux method? Use odd numbered versions for
untested programs, and even numbered versions for tried and tested programs.
ie win32libv4.0 - A tried and stable version
win32libv4.1 - A new version still under development
win32libv4.2 - When 4.1 becomes stable change it's name to this and
start
win32libv4.3 - As the new development version.
That way people get to choose between the latest beta version if they are
adventurous, or they could take the latest stable version instead.
Bye
Martin
----- Original Message -----
From: Cuny, David <David.Cuny at DSS.CA.GOV>
To: <EUPHORIA at LISTSERV.MUOHIO.EDU>
Sent: Friday, September 10, 1999 4:51 PM
Subject: Re: win32lib.ew .41
> In thinking about the problems Judith encountered with the latest release
of
> Win32Lib, I'm not sure what to do. I test the code before posting it, but
> obviously bugs get through, especially when new features have been added.
>
> Perhaps I should designate two versions of Win32Lib - an older, "stable"
> version, and the "most recent" version. That way, if people run into major
> problems with a new release, they could easily fall back on an older
> version. Otherwise, I guess I'd have to start using beta testers - that
> requires the kind of coordination that I just don't have the time or
energy
> for.
>
> Robert, is this possible?
>
> Thanks!
>
> -- David Cuny
>
8. Re: win32lib.ew .41
Martin suggested:
>Just a thought - why not use the Linux method?
Not a bad thought, but a bit complex. I think I'll just go with thinking of
new releases as 'unstable', and once they've been out for a while without
complaint, move them to the 'stable' category.
I'm still scratching my head over the bugs that Judith encountered (I've had
no time to do any testing, and won't likely until Monday); I didn't *think*
that I did anything that dangerous in the code, or I obviously wouldn't have
released it in that state. My general impression was that with the bug
fixes, it should have been *more* stable than the prior release.
Judith - there are only two things I can thing of off the top of my head
that might be at fault. The first is the added mouse traps in subclassed() -
you might want to try commenting that section out and seeing if that takes
care of the problem. If it's not that, then perhaps pushSelf/popSelf are to
blame. You could dummy them out like so:
procedure pushSelf( integer id )
end procedure
function popSelf()
return 0
end function
and see if they are to blame. Even better, you could send me some erring
code - it would be a great help.
On an unrelated note, has anyone gotten tooltip to work for general
controls? I could create the tooltip control and register tooltips with
controls, but nothing popped up. The only thing that I could figure was that
I was supposed to be sending events to the Tooltip. If that was the case, I
decided it would be much easier to simply emulate them than to use the
common controls. I'm equally unhappy with the Toolbar and Status Bar - for
tha amount of code that it takes to get the controls to work, I could just
as easily render them myself - witness the emulated toolbar in design.exw.
Thanks!
-- David Cuny
9. Re: win32lib.ew .41
Brian Broker offered:
> I would be more than happy to help coordinate
> a Win32Lib bug bashing site and relay bug
> specifics (or fixes if possible).
Keeping a list of known bugs (and a wish list) sounds like something I
should start, and include with the documentation. I get sent stuff to look
at, and occasionally ^h^h^h^h often ^h^h^h^h ok, just about always seem to
lose track of it. I'll try to start that up with the next release.
For anyone that's curious about the status of Llama, it's still alive and
kicking. The latest model discards a lot of the OOP stuff for a much simpler
class model. GtkLib uses the new model, and I've just started the Win32
port. Hopefully I'll have something useful to post in the near future.
-- David Cuny
10. Re: win32lib.ew .41
On Fri, 10 Sep 1999, you wrote:
> Robert Craig wrote:
> Great.
> >You could also set up your own Web page.
>
> I've got a site with my account; I guess I could make a stab at it.>
> -- David Cuny
Dave:
It would be better if you would let Rob post a stable version,
and put any development versions on your own web or ftp site. That way,
anyone who wants to test could do so, and you could update the package as
often as needed without bothering Rob. I'm sure Rob also wants everything on
the official Euphoria site to be as stable as possible.
Regards
Irv
11. Re: win32lib.ew .41
Here's the status of the known bugs in Win32Lib v0.41:
[ Controls Not Responding To Mouse ]
This is due to a 'fix' in the subclassed() routine. I noticed that only
right button events were being trapped, and, despite a nagging feeling that
it was coded that way by design and not mistake, I changed the code. Bad
idea!
If you attach an onMouse() trap to a control, all the mouse events are then
routed through the onMouse code, and exit through a return statement. The
result is that Windows never processes mouse events for these controls.
I've changed the code back to only trap right button clicks, which are OK to
trap because there is no default processing for these events.
[ getFontSize Type Check Error ]
Stupid mistake. The variable 'saved' should have been declared as a
sequence, not as an atom.
[ Strange Color Settings ]
In prior versions, each window was registered as a seperate class. It was
suggested (quite reasonably) that this was redundant, and I only needed to
register the class once for application, and have all Windows inherit that
class.
Enter the setWindowBackColor() routine, which uses the Win32 call
SetClassLong to change the GCL_HBBRBACKGROUND to a custom colored brush.
Since all the windows share the same class, it changes the colors for all
the windows.
I've changed the code back to registering a new class for each window.
Thanks again to Judith Evans and Wolfgang Fritz (did I miss anyone?) for
reporting these problems, and apologies for any inconvenience they has
caused. Keep those bug reports coming in!
-- David Cuny
