1. RE: win32lib v0.57.6 released
Derek Parnell wrote:
> Thanks again to all the people who are helping make this library so
> useful.
>
> I've placed v0.57.6 onto the website for your inspection.
>
> http://www.users.bigpond.com/ddparnell/euphoria/w320576.zip
>
Derek:
The above link in this post is valid and works ok;
but the link on your WEB PAGE is still pointing
to the wrong file name.
Bernie
2. RE: win32lib v0.57.6 released
Bernie Ryan wrote:
>
> Derek Parnell wrote:
> > Thanks again to all the people who are helping make this library so
> > useful.
> >
> > I've placed v0.57.6 onto the website for your inspection.
> >
> > http://www.users.bigpond.com/ddparnell/euphoria/w320576.zip
> >
>
> Derek:
> The above link in this post is valid and works ok;
> but the link on your WEB PAGE is still pointing
> to the wrong file name.
Thanks Bernie, I hadn't realised. I'll see what I can do from here.
3. RE: win32lib v0.57.6 released
Dan Moyer wrote:
> Derek,
>
> I like the new, un-cluttered look of the 57.6!
>
> It does present a problem for running the demos, though, which is how I
> usually first test a new version of Win32Lib. Previously when you
> released
> a new version, it could be tested in its own directory without putting
> it &
> its includes into the Euphoria "include" folder. Now some demos won't
> run
> from their new folder without doing that first, and the ones that do run
> are
> not running the new version, but rather whatever is in the "include"
> folder.
>
> I'm not sure what would solve this, as you can't just hard code the
> "include
> win32lib.ew" into each demo with the path of the new win32lib, since
> it's
> not known where the user put it, and I don't *think* relative paths
> work,
> though I could be wrong.
>
> Any thoughts?
>
> One way this could be possibly be addressed is to put "RunDemos.exw"
> into
> the base folder with win32Lib.ew, & just run the demos from it, (since
> that's its purpose, grin), because it can store path info for running
> demos;
> but I'm not sure yet whether the demos themselves would run from the new
> Win32Lib or from the "include" folder. I'll look into what I could do
> with
> RunDemos to allow running the demos from sub-folders using the "base"
> version of Win32Lib rather than the "include" folder version.
>
> And I see that the "readme" file needs to inform the new user that
> win32lib.ew & its includes need to be put into the Euphoria include
> folder.
> Maybe that readme file also needs to be in the base folder? Just a
> thought,
> don't want to destroy the nice uncluttered look!
>
Hi Dan,
thanks for the comment about its appearance. I did actually meant to
mention that in the release notes but I was rushed (had to catch a
plane).
Anyhow, the solution is simple enough. Using Euphoria v2.3 onwards, add
to the DOS environment symbol EUINC, the directory where win32lib is
installed. For example mine looks like...
set EUINC=F:\Projects\EUInc;D:\Win32lib\Current;H:\EuContribs
and I install the latest version of the library under
D:\Win32Lib\Current
-------
Derek.
4. Re: RE: win32lib v0.57.6 released
- Posted by alexione at EUnet.yu
May 20, 2002
5/20/02 05:13:30, Derek Parnell <ddparnell at bigpond.com> wrote:
>Anyhow, the solution is simple enough. Using Euphoria v2.3 onwards, add
>to the DOS environment symbol EUINC, the directory where win32lib is
>installed. For example mine looks like...
>
> set EUINC=F:\Projects\EUInc;D:\Win32lib\Current;H:\EuContribs
>
>and I install the latest version of the library under
>D:\Win32Lib\Current
I have little suggestion here: since there is number of libraries I'd like to
have
"accessable" all the time, and use of EUINC "eats" environment space (plus
annoying Windows-restarting), maybe it would be nice if there is file called
INCPATH.LST, or something like that, in %EUDIR%\BIN (or, for Linux, $EUDIR/bin)
which would hold list of directories which contain include files. Paths in this
file
should, also, have support for environment variables, so if we have
set EU_LIBS=D:\Develop\Libs\Euphoria
we can say in INCPATH.LST something like
%EUDIR%\Include
%EU_LIBS%\Win32Lib
%EU_LIBS%\Strings
%EU_LIBS%\Graphics
...
One more thing - it could be usefull if EU has support for paths relative to
these
paths above. Example, if we have under %EU_LIBS%\Graphic directories Graph1
and Graph2 (two different libraries), we can say
include Graph1/main.e
or
include Graph2/main.e
and EU will look not just in the present directory, but also in all directories
in the
include path.
I know this all is not simple, I just say it could be usefull. Let it all be a
suggestion to
be considered for some of new versions of EU.
Best wishes
Alexa
5. RE: win32lib v0.57.6 released
Derek,
I'm working on a project that uses some of the drawing routines in
win32lib. When I switched to V57.5 I began having problems with these
routines.
Out of curiosity, how is this bug manifesting itself?
I don't use drawLines but I do use a lot of drawRectangle (both filled
and non-filled) so I wonder if the bug is in drawRectangle as well?
Thanks!
Jonas
Derek Parnell wrote:
> Known Bugs
> ----------------
> * There is a serious resource leakage with the drawLines() routine.
6. RE: win32lib v0.57.6 released
Hi Jonas (and Derek),
It seems that the lib is not freeing GDI objects for some (maybe all?)
drawing routines. I will look into this and hopefully submit a fix to
Derek. If somebody has already done this, please let me know.
Thanks,
-- Brian
Jonas Temple wrote:
> Derek,
>
> I'm working on a project that uses some of the drawing routines in
> win32lib. When I switched to V57.5 I began having problems with these
> routines.
>
> Out of curiosity, how is this bug manifesting itself?
>
> I don't use drawLines but I do use a lot of drawRectangle (both filled
> and non-filled) so I wonder if the bug is in drawRectangle as well?
>
> Thanks!
>
> Jonas
> Derek Parnell wrote:
> > Known Bugs
> > ----------------
> > * There is a serious resource leakage with the drawLines() routine.
>
>
>
7. RE: win32lib v0.57.6 released
I'd like to retract this mail... It seems the problem existed in
version 0.57.4 and maybe 0.57.5 but it appears to be fixed in 0.57.6.
This is what I observed with my own programs. If you have a demo that
exposes the bug, please send it to me.
-- Brian
Brian Broker wrote:
> Hi Jonas (and Derek),
>
> It seems that the lib is not freeing GDI objects for some (maybe all?)
> drawing routines. I will look into this and hopefully submit a fix to
> Derek. If somebody has already done this, please let me know.
>
> Thanks,
> -- Brian
>
> Jonas Temple wrote:
> > Derek,
> >
> > I'm working on a project that uses some of the drawing routines in
> > win32lib. When I switched to V57.5 I began having problems with these
> > routines.
> >
> > Out of curiosity, how is this bug manifesting itself?
> >
> > I don't use drawLines but I do use a lot of drawRectangle (both filled
> > and non-filled) so I wonder if the bug is in drawRectangle as well?
> >
> > Thanks!
> >
> > Jonas
> > Derek Parnell wrote:
> > > Known Bugs
> > > ----------------
> > > * There is a serious resource leakage with the drawLines() routine.
> >
> >
> >
8. RE: win32lib v0.57.6 released
Brian,
Thanks for the reply! I suspected it was a problem with resources not
being released but I didn't have the time to track it down.
I'll apply V57.6 tonight (or later) and see if that doesn't take care of
the problem. If it doesn't I'll provide an example.
Jonas
Brian Broker wrote:
> I'd like to retract this mail... It seems the problem existed in
> version 0.57.4 and maybe 0.57.5 but it appears to be fixed in 0.57.6.
> This is what I observed with my own programs. If you have a demo that
> exposes the bug, please send it to me.
>
> -- Brian
9. RE: win32lib v0.57.6 released
Jonas (and Brian),
I'm not too sure about drawRectangle() etc as I haven't really tested
them for this effect. I did some testing with drawLine() and taht seemed
okay, but the drawLines() routine would devour GDI and memory like it as
going out of style!
As an example program, look into the drawText.exw demo program. There is
some code there that I've commented out using the "if False then ... end
if" trick. It is a single call to drawLines() so if you uncommented it,
run the program, and start resizing the window a lot, you will see the
effect pretty soon.
I did some research on it, and I think I know where to look now.
Microsoft recommends that whenever you do a selectObject() to replace an
object in the hDC, you must restore the value returned in the initial
selectObject() to the hDC before releasing it. win32lib is almost doing
this but not quite. To fix it though might mean some careful analysis of
the library code to make sure we catch all attempts at this.
---------
Derek.
Jonas Temple wrote:
> Derek,
>
> I'm working on a project that uses some of the drawing routines in
> win32lib. When I switched to V57.5 I began having problems with these
> routines.
>
> Out of curiosity, how is this bug manifesting itself?
>
> I don't use drawLines but I do use a lot of drawRectangle (both filled
> and non-filled) so I wonder if the bug is in drawRectangle as well?
>
> Thanks!
>
> Jonas
> Derek Parnell wrote:
> > Known Bugs
> > ----------------
> > * There is a serious resource leakage with the drawLines() routine.
>
>
>
10. RE: win32lib v0.57.6 released
Dan Moyer wrote:
[snip]
> But I did have a problem: after I set EUINC to the directory with
> Win23Lib
> 57.6 in it, & re-booted, my system hung up. After some moments of
> panic, I
> used the emergency disk & rem'd that EUINC line out in autoexec.bat, &
> it
> booted fine. I had put the set EUINC line last in autoexec.bat, after a
> set
> PATH, and when I moved the set EUINC to *above* set PATH, it boots ok
> now.
>
> Is that a known problem that I missed seeing in the doc, or is it a not
> previously known problem, or has no one else ever had that problem
> besides
> me?
I haven't actually installed the software but with over 12 years of
experience playing with autoexec.bat and config.sys files it
shouldn't matter where the "SET EUINC=???" line is in your
autoexec.bat file.
Did you keep a copy of the autoexec.bat that failed to boot?
Possibly somehow your autoexec.bat became currupt after it was
modified???
When you say it failed to boot do you remember what the last piece
of information was that was displayed on the screen?
That might help indentify what the problem was.
I'm glad it's working now!
Regards,
Ray Smith
http://rays-web.com
11. RE: win32lib v0.57.6 released
Brian and Derek,
I indeed went home last night and applied v0.57.6 and am still seeing
the problem. If I run the program long enough I get the "Not enough
resources to run this program" message box. This problem also seems to
be more pronounced on Win98 (I haven't tried it on Win95). I also tried
it on Win2000 Pro and it takes much longer for the problem to happen.
I'll be happy to furnish my example if either or both of you want to
take a look at it.
Jonas
Brian Broker wrote:
> I'd like to retract this mail... It seems the problem existed in
> version 0.57.4 and maybe 0.57.5 but it appears to be fixed in 0.57.6.
> This is what I observed with my own programs. If you have a demo that
> exposes the bug, please send it to me.
>
> -- Brian
12. RE: win32lib v0.57.6 released
Yes, just send a sample to me privately. I'm running XP and I even
tested the drawText.exw demo with drawLines() enabled and I resized the
Window quite a bit but didn't see any leakage in memory or GDI
objects... Might have to test at home on the Win98 box.
-- Brian
Jonas Temple wrote:
> Brian and Derek,
>
> I indeed went home last night and applied v0.57.6 and am still seeing
> the problem. If I run the program long enough I get the "Not enough
> resources to run this program" message box. This problem also seems to
> be more pronounced on Win98 (I haven't tried it on Win95). I also tried
>
> it on Win2000 Pro and it takes much longer for the problem to happen.
>
> I'll be happy to furnish my example if either or both of you want to
> take a look at it.
>
> Jonas
> Brian Broker wrote:
> > I'd like to retract this mail... It seems the problem existed in
> > version 0.57.4 and maybe 0.57.5 but it appears to be fixed in 0.57.6.
> > This is what I observed with my own programs. If you have a demo that
> > exposes the bug, please send it to me.
> >
> > -- Brian
>
>
>
13. RE: win32lib v0.57.6 released
Brian,
Well...would like to send you the file but I don't know your address.
You can reach me at jktemple at yhti.net.
Thanks!
Jonas
Brian Broker wrote:
> Yes, just send a sample to me privately. I'm running XP and I even
> tested the drawText.exw demo with drawLines() enabled and I resized the
> Window quite a bit but didn't see any leakage in memory or GDI
> objects... Might have to test at home on the Win98 box.
>
> -- Brian
>
> Jonas Temple wrote:
> > Brian and Derek,
> >
> > I indeed went home last night and applied v0.57.6 and am still seeing
> > the problem. If I run the program long enough I get the "Not enough
> > resources to run this program" message box. This problem also seems to
> > be more pronounced on Win98 (I haven't tried it on Win95). I also tried
> >
> >
> > it on Win2000 Pro and it takes much longer for the problem to happen.
> >
> > I'll be happy to furnish my example if either or both of you want to
> > take a look at it.
> >
> > Jonas
> > Brian Broker wrote:
> > > I'd like to retract this mail... It seems the problem existed in
> > > version 0.57.4 and maybe 0.57.5 but it appears to be fixed in 0.57.6.
> > > This is what I observed with my own programs. If you have a demo that
> > > exposes the bug, please send it to me.
> > >
> > > -- Brian
> >
> >
> >
