1. Win32Lib bug?
I've finally gotten around to playing with the newest Win32Lib release (and
changing my programs accordingly).
Question: Does 'create' still process flags?
This works on version .50:
constant
NoSizeWin = or_all( {WS_DLGFRAME,
WS_SYSMENU,
WS_MINIMIZEBOX} )
constant
Win = create( Window, "Win", 0, 0, 0, 640, 480, NoSizeWin )
-- Win is a Window that cannot be resized
This no longer works in the latest release. I don't have time to track it
down because there have been so many changes lately...
Any help?
Thanks,
-- Brian
2. Re: Win32Lib bug?
Brian,
This is the same kind of thing I was referring to in an earlier post! Glad
someone else noticed it too. :)
I said:
"One possible problem to look out for with regard to style setting for
windows, unless Derek has changed it in Win32Lib, is that as far as I
understand, in (a) recent version, the default style setting does *not* get
"over-ridden" by user specified style, the user spec just gets *added* to
the default, so you can't be completely sure that you have "rolled your own"
(window style) as you intended."
I had been making modal windows deliberately without a minimize box, (so as
to work-around a bug which allowed a modal window's main window to be
wrongfully closed before the modal was, by minimizing the modal window
first), by using a create similar to yours,
constant aModalWindow = create( Window, "This is a Modal Window", TheWindow,
50, 80, 400, 200, or_all({WS_DLGFRAME, WS_SYSMENU}) )
which *did* make the window without the minimize box in v.50, but made it
*with* the minimize box in .54
Dan
----- Original Message -----
From: "Brian Broker" <bkb at CNW.COM>
To: <EUPHORIA at LISTSERV.MUOHIO.EDU>
Sent: Wednesday, November 15, 2000 3:21 PM
Subject: Win32Lib bug?
> I've finally gotten around to playing with the newest Win32Lib release
(and
> changing my programs accordingly).
>
> Question: Does 'create' still process flags?
>
> This works on version .50:
>
> constant
> NoSizeWin = or_all( {WS_DLGFRAME,
> WS_SYSMENU,
> WS_MINIMIZEBOX} )
>
> constant
> Win = create( Window, "Win", 0, 0, 0, 640, 480, NoSizeWin )
>
> -- Win is a Window that cannot be resized
>
> This no longer works in the latest release. I don't have time to track it
> down because there have been so many changes lately...
>
> Any help?
>
> Thanks,
> -- Brian
3. Re: Win32Lib bug?
On Wed, 15 Nov 2000 17:40:25 -0800, Dan B Moyer wrote:
>Brian,
>
>This is the same kind of thing I was referring to in an earlier post! Glad
>someone else noticed it too. :)
>
>I said:
>
>"One possible problem to look out for with regard to style setting for
>windows, unless Derek has changed it in Win32Lib, is that as far as I
>understand, in (a) recent version, the default style setting does *not* get
>"over-ridden" by user specified style, the user spec just gets *added* to
>the default, so you can't be completely sure that you have "rolled your
>own" (window style) as you intended."
Dan,
Sorry I missed that post, but thanks for bringing it up again. But my
question still stands: Is this a bug or a feature? If this is a feature,
then how should I go about making a non-sizeable window?
-- Brian
4. Re: Win32Lib bug?
Brian Broker wrote:
>the default style setting does *not* get
>"over-ridden" by user specified style, the
> user spec just gets *added* to the default,
> so you can't be completely sure that you
> have "rolled your own" (window style) as
> you intended."
If Derek chooses to implement various flavors of windows, the addition of a
'no attribute' window would take care of that.
-- David Cuny
5. Re: Win32Lib bug?
- Posted by Dan B Moyer <DANMOYER at prodigy.net>
Nov 16, 2000
-
Last edited Nov 17, 2000
Brian,
Well, I think it is a bug, but it may be intended as feature? :)
And I think there is supposed to be a new command to re-set the style of a
window, (Wolf says Derek mentioned them in a post earlier, & I think I do
remember that, now), addStyle() and removeStyle(), but I couldn't find them,
maybe they are upcoming; the best I could do was to hack Win32Lib as
follows:
in "procedure createWindow",
after "if flags!=0 then"
find "lFlags=or_bits(flags,lFlags)",
and change it to:
"lFlags= flags --or_bits(flags,lFlags)";
that will allow whatever *you* set as flags to be accepted and created,
without regard for the default setting (which is what I *think* lFlags is or
was), that is, without "or'ing" the default with the user specified
styles(which amounts to adding all the styles together). However, I have
*no* idea if this will make other problems or not!!
Maybe there's a better way, but that's all I could find. Hopefully Derek
will CHANGE THIS BACK, so the programmer can specify window styles easily??
Dan
----- Original Message -----
From: "Brian Broker" <bkb at CNW.COM>
To: <EUPHORIA at LISTSERV.MUOHIO.EDU>
Sent: Thursday, November 16, 2000 10:47 AM
Subject: Re: Win32Lib bug?
> On Wed, 15 Nov 2000 17:40:25 -0800, Dan B Moyer wrote:
>
> >Brian,
> >
> >This is the same kind of thing I was referring to in an earlier post!
Glad
> >someone else noticed it too. :)
> >
> >I said:
> >
> >"One possible problem to look out for with regard to style setting for
> >windows, unless Derek has changed it in Win32Lib, is that as far as I
> >understand, in (a) recent version, the default style setting does *not*
get
> >"over-ridden" by user specified style, the user spec just gets *added* to
> >the default, so you can't be completely sure that you have "rolled your
> >own" (window style) as you intended."
>
> Dan,
>
> Sorry I missed that post, but thanks for bringing it up again. But my
> question still stands: Is this a bug or a feature? If this is a feature,
> then how should I go about making a non-sizeable window?
>
> -- Brian
6. Re: Win32Lib bug?
> From: Dan B Moyer
> in "procedure createWindow",
> after "if flags!=0 then"
> find "lFlags=or_bits(flags,lFlags)",
> and change it to:
> "lFlags= flags --or_bits(flags,lFlags)";
The code that's there shouldn't stop the user specified styles from taking
effect. The problem is that the default style for a window is
WS_OVERLAPPEDWINDOW, which contains the WS_SIZEBOX/THICKFRAM style, allowing
sizing. You need to use classDefaults() to modify this:
--begin code
include win32lib.ew
constant
NoSizeWin = or_all( {WS_DLGFRAME,
WS_SYSMENU,
WS_MINIMIZEBOX} )
junk = classDefaults(Window, { {CCflags, {NoSizeWin}}, {}})
constant
MyNoSizeWin = create( Window, "No Size Window", 0, 20, 20, 200, 200, 0)
WinMain( MyNoSizeWin, Normal)
-- end code
> Maybe there's a better way, but that's all I could find.
> Hopefully Derek
> will CHANGE THIS BACK, so the programmer can specify window
> styles easily??
You could also use removeStyle() and addStyle() after window creation, but
classDefaults() seems a bit cleaner. Since classDefaults() returns the old
setting, you can easily reset the defaults:
junk = classDefaults(Window, junk )
right after you create the window. Unfortunately, I don't see an easy way
around this type of conflict. I think it's just part of the learning curve
with windows. No matter how many different window classes are created,
someone will find a new combination that doesn't work (although it would be
simpler in many cases).
Matt Lewis
http://www.realftp.com/matthewlewis
7. Re: Win32Lib bug?
Hi Brian,
I've been away on business, so sorry for the slow response.
>
> Question: Does 'create' still process flags?
Yes it does. In fact it works the same for all control types now. The
previous versions treated create() flags one way for Window controls and
another for other types. For Window, it used to replace the default flags
with any you might have specified, for others, it combined supplied flags
with the defaults. Now, Window works like the other controls.
> This works on version .50:
>
> constant
> NoSizeWin = or_all( {WS_DLGFRAME,
> WS_SYSMENU,
> WS_MINIMIZEBOX} )
>
> constant
> Win = create( Window, "Win", 0, 0, 0, 640, 480, NoSizeWin )
>
> -- Win is a Window that cannot be resized
>
> This no longer works in the latest release. I don't have time to track it
> down because there have been so many changes lately...
>
To allow people complete flexibility when dealing with more complex flag
combinations, a new function, classDefaults() was set up. This function
allows you to set the default flags for a given control type. This can set
both the normal style flags and the extended style flags.
Given your example above, there are two basic ways to achieve what you want
to do.
1) --------------------
sequence oldFlags
atom NoSizeWin
NoSizeWin = or_all( {WS_DLGFRAME,
WS_SYSMENU,
WS_MINIMIZEBOX} )
-- Set default flags for Window to NoSizeWin
oldflags = classDefaults(Window, {{CCflags, NoSizeWin} })
-- Create a window using the (new) defaults
Win = create( Window, "Win", 0, 0, 0, 640, 48, 0)
2) -------------------
sequence oldFlags
atom NoSizeWin
NoSizeWin = or_all( {WS_DLGFRAME,
WS_SYSMENU,
WS_MINIMIZEBOX} )
-- Set defaults for Window to zero (no flags at all)
oldflags = classDefaults(Window, {{CCflags, 0}} )
-- Create a window combining defaults (zero) with NoSizeWin
Win = create( Window, "Win", 0, 0, 0, 640, 480, NoSizeWin)
To make this commonly used functionality easier to use, I'm packaging some
of the more useful Window flag combinations into reserved Win32Lib words.
David Cuny wants me to use these new words as Control Types but I would
rather them being used as Style Flags. So I'm very tempted to do both,
unless persuaded otherwise.
David's method:
Win = create(NoSizeWindow, "Win", 0, 0, 0, 640, 480, 0)
Derek's method:
Win = create(Window, "Win", 0, 0, 0, 640, 480, w32NoSizeWin)
My reasoning is that the first create() parameter describes a basic
behaviour, whereas the flags parameter describes a basic interface. Also,
having a "new" control type is adds more complexity in the library that I
don't think is justified for things that are essentially the same. For
example, there are many places in the library that does this sort of thing
...
if window_type[id] = Window then ....
this might have to be changed to ...
if find(window_type[id], {Window, NoSizeWindow, ...}) != 0 then ....
or maybe ...
if and_bits(classAttr[window_type[id]], w32IsWindow) != 0 then ...
however, if we use these new words as predefined Window styles, the current
code is unchanged except in the create() function, with something like ...
if equal(styleflag, w32NoSizeWin) then
flags = or_bits(....)
elsif ...
else
flags = or_bits(defaultflags, styleflags)
end if
What does anybody else think?
------
Derek Parnell
Melbourne, Australia
(Vote [1] The Cheshire Cat for Internet Mascot)
8. Re: Win32Lib bug?
Derek Parnell wrote:
> if window_type[id] = Window then ....
>
> this might have to be changed to ...
>
> if find(window_type[id], {Window, NoSizeWindow, ...}) != 0 then ....
>
> or maybe ...
>
> if and_bits(classAttr[window_type[id]], w32IsWindow) != 0 then ...
or just:
if window_class[ID] = WINDOW then ...
> if equal(styleflag, w32NoSizeWin) then
> flags = or_bits(....)
> elsif ...
> else
> flags = or_bits(defaultflags, styleflags)
> end if
For that matter, you could code the new Window classes as:
if equal(class, NoSizeWin) then
class = Window
flags = or_bits(w32NoSizeWin)
elsif ...
else
flags = or_bits(defaultflags, styleflags)
end if
but I think it's a bad plan.
A cleaner solution would be to create a Window class that has *no*
defaultflags, so that you could write:
win = create( GenericWin, ..., myWindowFlags )
-- David Cuny
9. Re: Win32Lib bug?
- Posted by Dan B Moyer <DANMOYER at PRODIGY.NET>
Nov 17, 2000
-
Last edited Nov 18, 2000
I like this idea best, because it allows the *easiest* way to "roll your
own" windows styles, and is almost exactly like it was before, so users can
most easily fix broken code.
Dan Moyer
David Cuny wrote, in relation to different ways to allow windows to accept
user
specified styles:
<snip>
>
> A cleaner solution would be to create a Window class that has *no*
> defaultflags, so that you could write:
>
> win = create( GenericWin, ..., myWindowFlags )
>
> -- David Cuny
10. Re: Win32Lib bug?
- Posted by Dan B Moyer <DANMOYER at PRODIGY.NET>
Nov 17, 2000
-
Last edited Nov 18, 2000
Matt,
Sorry to disagree, but I *tested* my suggestion, and it *did* work.
A program with the following style (the modal example in Win32Lib):
"constant aModalWindow = create( Window, "This is a Modal Window",
TheWindow, 50, 80, 400, 200, or_all({WS_DLGFRAME, WS_SYSMENU}) )",
used to create a window which was not resizeable, but with recent version of
Win32Lib it *is* resizeable; with my suggested alteration it is now again
*not* resizeable.
I don't have any idea whether this is a *good* way to do it or not, just
that it does work; it allows the programmers selected window styles to in
fact be applied, just them, and *not* be "added" to the default styles, but
rather *replaces* them for a single window.
Dan
----- Original Message -----
From: "Matthew Lewis" <MatthewL at KAPCOUSA.COM>
To: <EUPHORIA at LISTSERV.MUOHIO.EDU>
Sent: Friday, November 17, 2000 9:14 AM
Subject: Re: Win32Lib bug?
> > From: Dan B Moyer
>
> > in "procedure createWindow",
> > after "if flags!=0 then"
> > find "lFlags=or_bits(flags,lFlags)",
> > and change it to:
> > "lFlags= flags --or_bits(flags,lFlags)";
>
> The code that's there shouldn't stop the user specified styles from taking
> effect. The problem is that the default style for a window is
> WS_OVERLAPPEDWINDOW, which contains the WS_SIZEBOX/THICKFRAM style,
allowing
> sizing. You need to use classDefaults() to modify this:
>
> --begin code
> include win32lib.ew
> constant
> NoSizeWin = or_all( {WS_DLGFRAME,
> WS_SYSMENU,
> WS_MINIMIZEBOX} )
> junk = classDefaults(Window, { {CCflags, {NoSizeWin}}, {}})
> constant
> MyNoSizeWin = create( Window, "No Size Window", 0, 20, 20, 200, 200, 0)
>
> WinMain( MyNoSizeWin, Normal)
> -- end code
>
> > Maybe there's a better way, but that's all I could find.
> > Hopefully Derek
> > will CHANGE THIS BACK, so the programmer can specify window
> > styles easily??
>
> You could also use removeStyle() and addStyle() after window creation, but
> classDefaults() seems a bit cleaner. Since classDefaults() returns the
old
> setting, you can easily reset the defaults:
>
> junk = classDefaults(Window, junk )
>
> right after you create the window. Unfortunately, I don't see an easy way
> around this type of conflict. I think it's just part of the learning
curve
> with windows. No matter how many different window classes are created,
> someone will find a new combination that doesn't work (although it would
be
> simpler in many cases).
>
> Matt Lewis
> http://www.realftp.com/matthewlewis
11. Re: Win32Lib bug?
--- Dan B Moyer <DANMOYER at PRODIGY.NET> wrote:
> Matt,
>
> Sorry to disagree, but I *tested* my suggestion, and it *did* work.
Yeah, I didn't mean to say that it didn't work. I just wanted to explain what
was going on, and to offer a more 'proper' solution given the current win32lib.
=====
Matt Lewis
http://www.realftp.com/matthewlewis
__________________________________________________
Do You Yahoo!?
Yahoo! Calendar - Get organized for the holidays!
http://calendar.yahoo.com/
12. Re: Win32Lib bug?
Matt,
OkyDoky; it turns out my suggestion messed up how other controls were
handled, so I guess even if it did work(partly), it also didn't work
(wholly) :)
Dan
----- Original Message -----
From: "Matt Lewis" <matthewwalkerlewis at YAHOO.COM>
To: <EUPHORIA at LISTSERV.MUOHIO.EDU>
Sent: Monday, November 20, 2000 1:20 PM
Subject: Re: Win32Lib bug?
> --- Dan B Moyer <DANMOYER at PRODIGY.NET> wrote:
> > Matt,
> >
> > Sorry to disagree, but I *tested* my suggestion, and it *did* work.
>
> Yeah, I didn't mean to say that it didn't work. I just wanted to explain
what
> was going on, and to offer a more 'proper' solution given the current
win32lib.
>
>
>
> =====
> Matt Lewis
> http://www.realftp.com/matthewlewis
>
> __________________________________________________
> Do You Yahoo!?
> Yahoo! Calendar - Get organized for the holidays!
> http://calendar.yahoo.com/
13. Win32Lib bug?
I am having a problem with Win32Lib v .60.6, although it might possibly be my
code.
In any case this is the situation:
My application opens a modal dialog box with a listview control. The first
time it opens and closes with no errors or warnings. But if the dialog is
opened a second time I receive the following warning from Win32Lib:
Error code 497
getHandle: Object is destroyed
The Listview requires no images and none have been added with addIcon but
it does use the LVS_EX_CHECKBOXES extended style.
The problem only occurs when the dialog window is destroyed, not if it is
simply closed.
When I use setWarning(2) I get the following in the error file (partial).
... called from D:\euphoria\win32lib\include\win32lib.ew:7841 in function
getHandle()
id = 177
hWnd = <no value>
... called from D:\euphoria\win32lib\include\win32lib.ew:14270 in procedure
setImageList()
id = 178
IL = 177
size = 0
message = <no value>
... called from D:\euphoria\win32lib0\include\win32lib.ew:16975 in function
createEx()
pControl = 39'''
pCaption = {}
pOwner = 163
pLeft = 5
pTop = 5
pWidth = 230
pHeight = 180
styleFlags = 16389
exFlags = 0
id = 178
at = <no value>
hotkey = <no value>
bgControl = <no value>
style = <no value>
result = <no value>
hWnd = 1508342
flags = 1417756741
extendedflags = 512
lParenthWnd = 852932
szClassName = 9150460
szCaption = 9261060
hMenu = 163
newhWnd = <no value>
pstr = <no value>
struct = <no value>
ok = <no value>
newobj = <no value>
lvcol = {
{{},18,0},
{{},192,0}
}
BBox = {5,5,230,180}
sbPanels = <no value>
lHintText = {}
lIconInfo = <no value>
autoclose = 0
lBGColor = {{}}
lUserPre = {}
lUserPost = <no value>
lTemp = <no value>
i = 2
It appears to me that the Image list is being destroyed when the Listview
is destroyed. I know that I can avoid the warning with setWarning(0) but
this doesn't deal with the underlying problem.
Is this normal behaviour for Win32Lib or am I doing something wrong?
Larry Miller
14. Re: Win32Lib bug?
- Posted by Brian Broker <bkb at cnw.com>
Jan 28, 2005
-
Last edited Jan 29, 2005
Larry Miller wrote:
>
> I am having a problem with Win32Lib v .60.6, although it might possibly be my
> code.
> In any case this is the situation:
>
> My application opens a modal dialog box with a listview control. The first
> time it opens and closes with no errors or warnings. But if the dialog is
> opened a second time I receive the following warning from Win32Lib:
> Error code 497
> getHandle: Object is destroyed
>
> The Listview requires no images and none have been added with addIcon but
> it does use the LVS_EX_CHECKBOXES extended style.
> The problem only occurs when the dialog window is destroyed, not if it is
> simply closed.
<snip>
If you are opening the dialog more than once, then why are you destroying it?
You can't use something you've destroyed; that's why you get the error...
-- Brian
15. Re: Win32Lib bug?
- Posted by Larry Miller <larrymiller at sasktel.net>
Jan 28, 2005
-
Last edited Jan 29, 2005
Regarding the reply by Brian Broker
The dialog works ok the first time used. I destroy it when the user closes it.
If the user calls for the dialog again the listview and everything else in
the dialog is recreated. And as I said, if I set setWarning(0) it works fine.
Larry
16. Re: Win32Lib bug?
- Posted by Derek Parnell <ddparnell at bigpond.com>
Jan 28, 2005
-
Last edited Jan 29, 2005
Larry Miller wrote:
>
> I am having a problem with Win32Lib v .60.6, although it might possibly be my
> code.
> In any case this is the situation:
>
> My application opens a modal dialog box with a listview control. The first
> time it opens and closes with no errors or warnings. But if the dialog is
> opened a second time I receive the following warning from Win32Lib:
> Error code 497
> getHandle: Object is destroyed
>
> The Listview requires no images and none have been added with addIcon but
> it does use the LVS_EX_CHECKBOXES extended style.
> The problem only occurs when the dialog window is destroyed, not if it is
> simply closed.
[snip]
> Is this normal behaviour for Win32Lib or am I doing something wrong?
Neither. This is a mistake (two actually) that I've made in the library.
The mistakes are that when the first ListView (or TreeView) is created, I
also create a couple of imagelists, but instead of having them owned by
the main window (which is what was intended by my code), I had them owned
by the window that owned the ListView. In your case the dialog window.
The other mistake I made was when the imagelists were destroyed, I failed to
reset the built-in imagelist ids back to zero. If I had have done that
I would have recreated them again when you recreated the dialog window.
The imagelists were being destroyed because you destroyed the dialog window
which was their parent window.
The workaround is simple. Just force the imagelists to be created such that
they are owned by the main window. Do something like this ...
constant mainwin = create(Window, "Main", 0, 0, 0, 500, 400, 0)
-- Workaround for imagelist bug --
constant dummylv = create(ListView, "", mainwin, 0, 0, 0, 0, 0)
destroy(dummylv)
In the meantime, I'll fix these mistakes I've made in the library.
--
Derek Parnell
Melbourne, Australia
