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
|
Not Categorized, Please Help
|
|
