1. RE: Win32lib cascading windows
OK, I have been able to put together a program which is little more than
a series of windows that call each other. The opening window has a
button. Push that button and it opens a window which prompts for a
name. Click the OK button there and it opens a window which would show
scores, except I've stripped all the displays to minimize the code.
Click OK on that window and it should return control to the original
main window since I'm not opening any further windows. That is when I
wind up in this weird, locked-up state. Thanks for helping me to look
at this. No doubt I've done something stupid, but I've seen many times
how having another set of eyes look at it can spot the thing I'm
missing.
J. Kenneth Riviere
--------------------------------
include file.e
include misc.e
include Win32Lib.ew
without warning
sequence userName
constant
scoreWin = create(
Window,"Standings",0,Default,Default,350,320,0 ),
scoreOKButton = create( DefPushButton, "OK", scoreWin, 160, 250, 60,
32, 0 )
procedure closeScoreWin()
integer result
result = message_box( "Ready to close scoreWin",
"finishScoreWin!", 0 )
end procedure
onClose[ scoreWin ] = routine_id("closeScoreWin")
procedure onClick_ScoreOKButton()
closeWindow(scoreWin)
end procedure
onClick[ scoreOKButton ] = routine_id( "onClick_ScoreOKButton" )
procedure scorePaint( integer x1, integer y1, integer x2, integer y2 )
sequence printSol, sortSols
integer madeTop10
madeTop10 = 1
if madeTop10 = 0 then
setPosition( scoreWin, 50, 210 )
wPuts( scoreWin, printSol )
end if
end procedure
onPaint[scoreWin] = routine_id( "scorePaint" )
procedure writeSol()
openWindow( scoreWin, Modal )
end procedure
constant
PromptWin = create( Window,"Enter your
name",0,Default,Default,260,120,0),
NameLbl = create( LText, "Please enter your name",
PromptWin, 10, 10, 120, 30, 0 ),
NameFld = create( EditText, "", PromptWin, 10, 45, 120, 20, 0 ),
OKButton = create( DefPushButton, "OK", PromptWin, 180, 40, 30, 30,
0 )
procedure finishGameWon()
atom result
result = message_box( "Ready to close PromptWin",
"finishGameWon!", 0 )
writeSol()
--nextPuzzle()
end procedure
procedure displayUserName( integer x1, integer y1, integer x2, integer
y2 )
sequence tmpName
tmpName = "JoKeR"
setText(NameFld, tmpName)
end procedure
procedure onClick_OKButton()
userName = getText( NameFld )
closeWindow(PromptWin)
end procedure
onClick[ OKButton ] = routine_id("onClick_OKButton")
onPaint[ PromptWin ] = routine_id("displayUserName")
onClose[ PromptWin ] = routine_id("finishGameWon")
constant ButtonWindow =
create( Window, "Button Example", 0, Default, Default, 100, 100, 0 )
-- create a control in the window
constant OkButton =
create( PushButton, "&Button", ButtonWindow, 10, 10, 80, 40, 0 )
-- add a tooltip to the button
setHint( OkButton, "This button invokes name prompting." )
procedure doPrompt()
openWindow(PromptWin, Modal)
end procedure
onClick[ OkButton ] = routine_id("doPrompt")
-- hand control over to Windows
WinMain( ButtonWindow, Normal )
> demonstration program that exhibits the effect?
>
> For windows that are not the main one, the closeWindow() is little more
> than
> a glorified hideWindow().
>
> ------
> Derek Parnell
> Melbourne, Australia
> "To finish a job quickly, go slower."
>
>
>
2. RE: Win32lib cascading windows
Hi Kenneth,
you found a bug with using Modal windows. I'll track it down later but for
now you can do this instead.
Use the openDialog( win) function instead of openWindow(win, Modal) and
remove onClose[] trapping, instead just call the close routine directly.
eg...
WAS
procedure onCloseMyWin()
. . .
end procedure
onClose[mymin] = routine_id("onCloseMyWin")
. . .
openWindow(mywin, Modal)
SHOULD BE
procedure onCloseMyWin()
. . .
end procedure
. . .
openDialog(mywin)
onCloseMyWin()
The main difference between openDialog() and openWindow(...,Modal) is that
the next line after the openDialog() is not executed until the window is
closed, whereas with openWindow() the next line is executed immediately
after the window is opened.
Here is your sample program with these amendments...
-------------------
include file.e
include misc.e
include Win32Lib.ew
without warning
sequence userName
constant
scoreWin = create(Window,"Standings",0,Default,Default,350,320,0 ),
scoreOKButton = create( DefPushButton, "OK", scoreWin, 160, 250, 60,
32, 0 )
procedure closeScoreWin()
integer result
result = message_box( "Ready to close scoreWin",
"finishScoreWin!", 0 )
end procedure
--onClose[ scoreWin ] = routine_id("closeScoreWin")
procedure onClick_ScoreOKButton()
closeWindow(scoreWin)
end procedure
onClick[ scoreOKButton ] = routine_id( "onClick_ScoreOKButton" )
procedure scorePaint( integer x1, integer y1, integer x2, integer y2 )
sequence printSol, sortSols
integer madeTop10
madeTop10 = 1
if madeTop10 = 0 then
setPosition( scoreWin, 50, 210 )
wPuts( scoreWin, printSol )
end if
end procedure
onPaint[scoreWin] = routine_id( "scorePaint" )
procedure writeSol()
-- openWindow( scoreWin, Modal )
openDialog(scoreWin)
closeScoreWin()
end procedure
constant
PromptWin = create( Window,"Enter your
name",0,Default,Default,260,120,0),
NameLbl = create( LText, "Please enter your name",
PromptWin, 10, 10, 120, 30, 0 ),
NameFld = create( EditText, "", PromptWin, 10, 45, 120, 20, 0 ),
OKButton = create( DefPushButton, "OK", PromptWin, 180, 40, 30, 30,
0 )
procedure finishGameWon()
atom result
result = message_box( "Ready to close PromptWin",
"finishGameWon!", 0 )
writeSol()
--nextPuzzle()
end procedure
procedure displayUserName( integer x1, integer y1, integer x2, integer
y2 )
sequence tmpName
tmpName = "JoKeR"
setText(NameFld, tmpName)
end procedure
procedure onClick_OKButton()
userName = getText( NameFld )
closeWindow(PromptWin)
end procedure
onClick[ OKButton ] = routine_id("onClick_OKButton")
onPaint[ PromptWin ] = routine_id("displayUserName")
--onClose[ PromptWin ] = routine_id("finishGameWon")
constant ButtonWindow =
create( Window, "Button Example", 0, Default, Default, 100, 100, 0 )
-- create a control in the window
constant OkButton =
create( PushButton, "&Button", ButtonWindow, 10, 10, 80, 40, 0 )
-- add a tooltip to the button
setHint( OkButton, "This button invokes name prompting." )
procedure doPrompt()
-- openWindow(PromptWin, Modal)
openDialog(PromptWin)
finishGameWon()
end procedure
onClick[ OkButton ] = routine_id("doPrompt")
-- hand control over to Windows
WinMain( ButtonWindow, Normal )
-------------------
-----------
cheers,
Derek Parnell
Senior Design Engineer
Global Technology Australasia Ltd
dparnell at glotec.com.au
---------------------
3. RE: Win32lib cascading windows
Derek Parnell wrote:
> Hi Kenneth,
> you found a bug with using Modal windows. I'll track it down later
Thanks for your speedy response. I read your reply at work but didn't
print it out. When I got home I tried simply changing to Normal opens
instead of Modal and I no longer locked up (though that did lead to some
odd behavior, more on that in a bit).
I'll try changing to to openDialog now that I've got the message in
front of me again. The Win32lib really has been helpful in learning to
do some gui Windows code. Most of my experience has been in batch or
terminal programming so this event driven code is something new for me.
Having this type of utility has been very helpful. (I need to spend
some of my monthly money (which I've been forgetting to do) so that you
and David get something for your efforts.)
I noticed when I upgraded from .50i (or whatever I was running) to 55.1
that a lot of new includes were called for (from the names I'm assuming
it has to do with TK graphics). Has Robert said anything about
conditional inclusion so that metavariables of some kind could be used
to keep portions of code which an application doesn't need out at load
time? This could help to reduce the size of programs if whole sections
of code (such as the Tk routines) are not being used.
As for the somewhat odd behavior of using Normal windows: one thing was
simply application specific. Since I opened the windows as Normal my
primary window could still become activated and my code didn't allow for
checking that no movement was allowed after the completion of the
puzzle. I'd trusted the Modal mode to protect it and I'm hoping to use
the openDialog to the same effect.
However, I've also noticed that when I hit Enter at the PromptWindow so
that it responds as if I'd clicked on OK, the scoreWindow flashes past
as though the Enter keystroke was processed for both windows. I tried
this multiple times to make sure I hadn't accidentally hit Enter twice.
I think it had done this before with the Modal windows but I hadn't paid
as much attention then because I was immediately thrown into the locked
state that prompted my initial question. I've just tried it with the
openDialog feature and the double processing of Enter ocurrs with it as
well. (It does restore Modal operation, but now I have all three
windows on screen at once, but that is a trival matter.) Should I be
trying to test for keystrokes being entered when I enter a routine which
is invoked by a button before opening the next window to assure that the
keystroke doesn't get picked up by the next window or is this some other
problem? This is not a show stopper like the locked state was, but it
doesn't seem quite right.
Again, thanks for your help. Good luck to you.
-J. Kenneth Riviere
4. RE: Win32lib cascading windows
Hi Kenneth,
> Thanks for your speedy response.
No worries.
> I read your reply at work but didn't
> print it out. When I got home I tried simply changing to
> Normal opens
> instead of Modal and I no longer locked up (though that did
> lead to some
> odd behavior, more on that in a bit).
Yes, I can believe that.
> I'll try changing to to openDialog now that I've got the message in
> front of me again. The Win32lib really has been helpful in
> learning to
> do some gui Windows code. Most of my experience has been in batch or
> terminal programming so this event driven code is something
> new for me.
Once the paradigm is grasped, it makes the divide&conquer style of coding a
lot easier.
> I noticed when I upgraded from .50i (or whatever I was
> running) to 55.1
> that a lot of new includes were called for (from the names
> I'm assuming
> it has to do with TK graphics). Has Robert said anything about
> conditional inclusion so that metavariables of some kind
> could be used
> to keep portions of code which an application doesn't need
> out at load
> time? This could help to reduce the size of programs if
> whole sections
> of code (such as the Tk routines) are not being used.
I think that Robert can't see any need for this in Euphoria. His workaround,
I believe, is 'If you don't want specific include files to be included, use
your text editor and remove them.' A sad state of affairs in my opinion. It
could be that it is just hard for him to adapt the interpreter to do this,
but I don't know for sure. Try asking Robert directly at
rds at RapidEuphoria.com
On the other hand, I'm juggling the internal layout of win32lib.ew so that a
"light" version can be created without any embedded controls. Theoretically,
you should then be able to add the includes for the controls you want to
use.
> As for the somewhat odd behavior of using Normal windows:
> one thing was
> simply application specific. Since I opened the windows as Normal my
> primary window could still become activated and my code
> didn't allow for
> checking that no movement was allowed after the completion of the
> puzzle. I'd trusted the Modal mode to protect it and I'm
> hoping to use
> the openDialog to the same effect.
Yes it does. Internally it is the same as opening a modal window, but it
starts up a new instance of the Windows message loop that only gets messages
from the Dialog window and its controls.
> However, I've also noticed that when I hit Enter at the
> PromptWindow so
> that it responds as if I'd clicked on OK, the scoreWindow
> flashes past
> as though the Enter keystroke was processed for both windows.
> I tried
> this multiple times to make sure I hadn't accidentally hit
> Enter twice.
> I think it had done this before with the Modal windows but I
> hadn't paid
> as much attention then because I was immediately thrown into
> the locked
> state that prompted my initial question. I've just tried it with the
> openDialog feature and the double processing of Enter ocurrs
> with it as
> well. (It does restore Modal operation, but now I have all three
> windows on screen at once, but that is a trival matter.) Should I be
> trying to test for keystrokes being entered when I enter a
> routine which
> is invoked by a button before opening the next window to
> assure that the
> keystroke doesn't get picked up by the next window or is this
> some other
> problem? This is not a show stopper like the locked state
> was, but it
> doesn't seem quite right.
Looks like another bug. I can replicate the effect on my machine too but I
don't have an answer yet. Either the RETURN key is not being removed from
the message queue or another one is being put in the queue or more probably,
I'm just not handling the key properly.
-----------
cheers,
Derek Parnell
Senior Design Engineer
Global Technology Australasia Ltd
dparnell at glotec.com.au
---------------------
