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