1. Win32lib cascading windows
Seeing David's post about porting Sokoban revived my interest in putting
the finishing touches on my own Sokoban program, JokoSoko. It has undo,
saves scores which can be replayed, records move macros, and other
features which I like. However, I thought it would be good to make sure
it works with the latest Win32lib release since I haven't kept up to
date with that for 6 months or more.
After downloading the new version and updating the files in my include
directory to incorporate all of the new includes required by the latest
version I found that it seems to work fine with one exception.
When saving scores I wanted a name to associate with the player who
solved the puzzle. But I got tired of asking for the name so I added a
confirmation box which would allow me to simply confirm that I was the
same player that had won the previous game. Thus, when a puzzle is
solved a new window pops up with a message requesting confirmation of
the name. If that confirmation is affirmed then it goes on to show the
current list of best scores in another window (with the confirmation
window closing, of course). When the player has had a chance to review
the scores and closes that window then the main window is updated with
the next game and play resumes. All of this works fine.
The problem arrises when the confirmation is denied. Thus, from the
main window I open the confimation window and the player presses the
"No" button which then leads to a new prompt window for the player's
name. When that prompt window is closed then the score window is
displayed as before followed by the return to the main window. However,
after this sequence (the only difference being the additional prompt
window in the sequence of windows) my main window is in some kind of
wierd locked state. Using Windows controls (I'm running 95) I can cause
the game window to be minimized and restored so it is not completely
fried. However, when I try to do anything in the window by clicking on
it it becomes not the active window. When I minimize and restore it the
bar at the top of the window indicates that it is active but it doesn't
respond to my keystrokes. The only thing I've been able to do is to use
the TaskManager to kill it.
My code for the prompt window is as follows:
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()
writeSol() -- invokes the routine to display scores
end procedure
procedure onClick_OKButton()
userName = getText( NameFld )
configSeq = kvset(configSeq,"userName",userName)
closeWindow(PromptWin)
end procedure
onClick[ OKButton ] = routine_id("onClick_OKButton")
onClose[ PromptWin ] = routine_id("finishGameWon")
-------------------------------
Whether they press ok to accept a newly entered name or use the close
button on the window it proceeds to the score window OK. However, once
the score window is closed my game locks up. The score window code is
more complex since it involves formatting and arranging multiple scores
in two sorted lists (first by least moves, then by least pushes).
However, if someone thinks that would be helpful I'll be glad to post
it.
This had been working fine with .50 (I think that is what I was using)
but now it is not.
My own thinking is that it involves opening these other windows while I
still have a window open (since I open the new window from within the
onClose clause for the current window). What I'd prefer is an
afterClose capability, but I haven't noticed that in Win32lib. Did I
just miss it? This would allow me to avoid opening a new window until
after the other window was closed rather than during the process of
closing the first one. onClose is a useful and appropriate routine, but
I wonder if in some cases such as this an afterClose routine might be
more appropriate.
Any insight anyone can give would be greatly appreciated.
-J. Kenneth Riviere
2. Re: Win32lib cascading windows
Hi Kenneth,
I can't see much wrong with your approach. Can you knock up a small
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."
3. Re: Win32lib cascading windows
Kenneth Riviere wrote:
> 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.)
Credit to those who deserve it: I haven't been actively involved in Win32Lib
for some months now. The current version is very much the work of Derek,
Matt Lewis, and other contributors. Truth be told, I can no longer find my
way around parts of the library - there's been some serious reorganization
going on!
Thanks again, Derek, Matt, Judith and everyone else!
-- David Cuny
