1. Win32lib dialogs within proc's
I'm wondering if anyone has an elegant solution to this. I'm writing a
windows program (actually porting a DOS program) using win32lib, and come to
a section in a routine where I need to get some input from the user by
opening up another dialog. An example would be:
file = getOpenFileName(Main, "", {"All Files", "*.*"} )
But I'd like to get some information from one of _my_ dialogs. I figure
that I could use a "callback" id, along with flags to let me know how far
into the original routine I got, and just have the window call the callback
when it's done, and add a bunch of 'if..then' statements looking at the
various flags I've set.
I don't want to do this yet, since I have about 60 or so routines, most of
which would need this type of overhaul. Also, my future plands include
porting the routines into a script that would allow me more flexibility etc,
so I'll have to include into the scripting language any scheme that I come
up with.
Here's the basic format of what I have now:
procedure foo( atom a, atom b, )
atom target
while 1 do
target = choose_target( a, "foo" )
if target then
....do stuff...
else
....do other stuff...
end if
end while
end procedure
There may be other 'choose_target' (or equivalent) calls in the ....do
stuff...., which is why I think I'd need flags or something.
So, if anyone has any ideas, I'd _really_ love to hear them.
Thanks,
Matthew W Lewis
2. Re: Win32lib dialogs within proc's
OK, I think I gave a bad example. Basically, I was using the
getOpenFileName dialog as an easy way to get some input from the user in a
generic sense. I guess what I'd like to do is be able to create my own
dialogs that could be used in a similar manner. I think this works because
you hand over control to windows using the common dialog, which does it's
thing and then gives control back to Eu.
Basically, I'd like to be able to 'emulate' that ability. I haven't been
able to think of any nice solutions to this. I guess what I'd need is
another event loop, like by nesting a call to WinMain within a call to
WinMain. I guess that would require some sort of 'namespace' architecture
on the part of win32lib, to keep controls of the various event loops
separate.
Hmmm. This would help me with something else that's been bothering me with
windows programming. I've found that I have to make a lot of vars global
(at least local, and not private to a routine), and use procedures
everywhere to manipulate vars rather than cleaner functions and less global
vars--since we don't know when the user will trigger any given event (eg,
Button_onClick) and send us back to the main flow of our program.
Matthew W Lewis
> -----Original Message-----
> From: Grape_ Vine_ [mailto:g__vine at hotmail.com]
>
> I am working on a project that sounds like it is close to
> what you are
> doing, Can you give me a clearer idea as to what it is you are doing?
> You used
>
> file = getOpenFileName(Main, "", {"All Files", "*.*"} )
>
> as a example, IF you wanted to use a certian file name from
> another part of
> your program that would be easy, you change the code to
>
> object file_name
> tons of code
> file = getOpenFileName(Main, "file_name", {"File
> description", "file_name"})
>
> Since i dont know just what your needs are my example is most
> likely not
> what you need
>
3. Re: Win32lib dialogs within proc's
Matthew Lewis wrote:
> But I'd like to get some information from
> one of _my_ dialogs.
Just create a window that looks like a dialog, and open it with:
openWindow( <window>, Modal )
When a window other than a non-primary window is closed, Win32Lib simply
hides it, so you can still query the controls in that window. Just set a
flag on the dialog's 'Ok' button onClick behavior, so you can tell how the
dialog was exited.
-- David Cuny
4. Re: Win32lib dialogs within proc's
----- Original Message -----
From: Matthew Lewis <MatthewL at KAPCOUSA.COM>
To: <EUPHORIA at LISTSERV.MUOHIO.EDU>
Sent: Friday, March 10, 2000 10:59 AM
Subject: Re: Win32lib dialogs within proc's
> OK, I think I gave a bad example. Basically, I was using the
> getOpenFileName dialog as an easy way to get some input from the user in a
> generic sense. I guess what I'd like to do is be able to create my own
> dialogs that could be used in a similar manner. I think this works
because
> you hand over control to windows using the common dialog, which does it's
> thing and then gives control back to Eu.
Ermm. I have dozens of such "user built dialogs" in my programs.
I just build a new window, place an edit text and/or checkboxes or
radio buttons as needed, and probably an "OK" button and a "cancel"
button, which when clicked transfer the info or do the task called for,
then close the window.
> Basically, I'd like to be able to 'emulate' that ability. I haven't been
> able to think of any nice solutions to this. I guess what I'd need is
> another event loop, like by nesting a call to WinMain within a call to
> WinMain. I guess that would require some sort of 'namespace' architecture
> on the part of win32lib, to keep controls of the various event loops
> separate.
I'm trying to think of where something like this would be needed. So far,
nothing comes to mind.
> Hmmm. This would help me with something else that's been bothering me
with
> windows programming. I've found that I have to make a lot of vars global
> (at least local, and not private to a routine), and use procedures
> everywhere to manipulate vars rather than cleaner functions and less
global
> vars--since we don't know when the user will trigger any given event (eg,
> Button_onClick) and send us back to the main flow of our program.
Actually, there shouldn't be many globals required. Perhaps you need to
reconsider
how your program functions. In Windows, there's generally _not_ a main
flow -
just a state that is modified in response to events, and perhaps some
procedures that
are run on demand. (sort, print, etc)
Regards,
Irv
5. Re: Win32lib dialogs within proc's
> From: Irv Mullins
>
> Ermm. I have dozens of such "user built dialogs" in my programs.
> I just build a new window, place an edit text and/or checkboxes or
> radio buttons as needed, and probably an "OK" button and a "cancel"
> button, which when clicked transfer the info or do the task
> called for,
> then close the window.
>
> I'm trying to think of where something like this would be
> needed. So far,
> nothing comes to mind.
>
I seem to have solved my problem, but here's what I'm doing. I'm working on
writing a game that's basically like Magic the Gathering (a fantasy card
game--and actually the reason I started using Euphoria a couple of years
ago). Each card has it's own special procedures for doing whatever the
card's effects are in the game. For instance, when you cast a Lightning
Bolt, you then choose a target, and the Lightning Bolt does some damage to
whatever your target was. Well, I've got a ton of procedures that need to
do such a thing. In order to find out what the target is, I need to open up
the window, and once the window is done, go right back to the spot in the
card's event code. If I simply open the window, it comes right back to the
code, without giving the user a chance to respond.
>
> Actually, there shouldn't be many globals required. Perhaps
> you need to
> reconsider
> how your program functions. In Windows, there's generally _not_ a main
> flow -
> just a state that is modified in response to events, and perhaps some
> procedures that
> are run on demand. (sort, print, etc)
>
I've definitely considered this, but I haven't come up with any satisfactory
solutions yet. At least, not without completely rewriting the basic engine
of the game...
In any case, I hacked win32lib, and came up with something that seems to
work. I created a procedure called EventLoop, which just runs an extra
event loop on top of WinMain's (in fact, EventLoop is just WinMain
modified). When you've finished with the Loop, you just set the last value
of EventLoopExit to true, and it ends, and you continue. This should allow
multiple nested loops, using EventLoopExit as a stack of flags. A definite
caveat is that win32lib won't detect if you've closed down the main window
(to exit the program) from within the event loop.
global sequence EventLoopExit
global procedure EventLoop( integer id, integer style )
-- main routine
atom hWnd
atom msg
atom ele
-- allocate a message buffer
msg = allocate_struct(SIZEOF_MESSAGE)
EventLoopExit &= 0
ele = length(EventLoopExit)
openWindow( id, style )
-- message loop
while c_func( xGetMessage, { msg, NULL, 0, 0 } ) and not
EventLoopExit[ele] do
c_proc( xTranslateMessage, { msg } )
c_proc( xDispatchMessage, { msg } )
end while
EventLoopExit = EventLoopExit[1..ele-1]
end procedure
6. Re: Win32lib dialogs within proc's
On Fri, 10 Mar 2000, you wrote:
> > From: Irv Mullins
> >
> > Ermm. I have dozens of such "user built dialogs" in my programs.
> > I just build a new window, place an edit text and/or checkboxes or
> > radio buttons as needed, and probably an "OK" button and a "cancel"
> > button, which when clicked transfer the info or do the task
> > called for,
> > then close the window.
> >
> > I'm trying to think of where something like this would be
> > needed. So far,
> > nothing comes to mind.
> >
>
> I seem to have solved my problem, but here's what I'm doing. I'm working on
> writing a game that's basically like Magic the Gathering (a fantasy card
> game--and actually the reason I started using Euphoria a couple of years
> ago). Each card has it's own special procedures for doing whatever the
> card's effects are in the game. For instance, when you cast a Lightning
> Bolt, you then choose a target, and the Lightning Bolt does some damage to
> whatever your target was. Well, I've got a ton of procedures that need to
> do such a thing. In order to find out what the target is, I need to open up
> the window, and once the window is done, go right back to the spot in the
> card's event code. If I simply open the window, it comes right back to the
> code, without giving the user a chance to respond.
If you define your new window as modal, then it _can't_ go back until the user
responds (and a closeWindow command is issued). That could be from a click or
selection from a listbox or a button, or whatever.
Irv
7. Re: Win32lib dialogs within proc's
> From: Of Irv Mullins
> If you define your new window as modal, then it _can't_ go
> back until the user
> responds (and a closeWindow command is issued). That could be
> from a click or
> selection from a listbox or a button, or whatever.
>
> Irv
>
Unfortunately, no. Maybe a true modal window would work this way, but not
in win32lib (I believe that modal windows are emulated?). While the window
doesn't go away, the program continues immediately after the window is
created, and the user never gets to do anything. By using another event
loop, the main flow of my program is halted until the user is done with the
dialog. I suspect that Windows does something similar in the case of
getOpenFileName (namely, creating it's own event loop). Actually, the
openWindow call in EventLoop() should probably use Modal. Or maybe wrap
that into openWindow(window, Modal) calls so it would behave like you
suggest.
Unless anyone can figure out another way to do this using existing routines
in win32lib, I'd like to add this to the wishlist for David.
8. Re: Win32lib dialogs within proc's
On Fri, 10 Mar 2000, you wrote:
> > From: Of Irv Mullins
>
> > If you define your new window as modal, then it _can't_ go
> > back until the user
> > responds (and a closeWindow command is issued). That could be
> > from a click or
> > selection from a listbox or a button, or whatever.
> >
> > Irv
> >
>
> Unfortunately, no. Maybe a true modal window would work this way, but not
> in win32lib (I believe that modal windows are emulated?). While the window
> doesn't go away, the program continues immediately after the window is
> created, and the user never gets to do anything. By using another event
> loop, the main flow of my program is halted until the user is done with the
> dialog. I suspect that Windows does something similar in the case of
> getOpenFileName (namely, creating it's own event loop). Actually, the
> openWindow call in EventLoop() should probably use Modal. Or maybe wrap
> that into openWindow(window, Modal) calls so it would behave like you
> suggest.
>
> Unless anyone can figure out another way to do this using existing routines
> in win32lib, I'd like to add this to the wishlist for David.
Well, if your code sez:
openWindow(win,Modal)
puts(1,"Hello World")
....etc
then of course it will open the window, and then continue with the next line.
But that's just not good Windows event driven coding.
Actually, it's not Windows coding at all.
You can't write Windows programs like you write DOS programs. It just doesn't
work that way.
Regards,
Irv
9. Re: Win32lib dialogs within proc's
> From: Irv Mullins
>
> Well, if your code sez:
> openWindow(win,Modal)
> puts(1,"Hello World")
> ....etc
> then of course it will open the window, and then continue
> with the next line.
> But that's just not good Windows event driven coding.
> Actually, it's not Windows coding at all.
> You can't write Windows programs like you write DOS programs.
> It just doesn't work that way.
>
> Regards,
> Irv
>
I have to disagree with you here. If that were the case, then
getOpenFileName() wouldn't work the way it does. When you use this (whether
you use David's wrapper, or use the API directly) any code that comes after
the call assumes that the user has finished with the dialog. Depending on
what type of app you're writing, you might not need this kind of behavior,
but I can't see how to get around it without a huge mess of flags and extra
procedures to really complicate the flow of the program. Besides, it makes
things behave like stuff already built into windows (eg, open file dialog,
message boxes).
The more I think about it, the more I suspect that this should be a default
behavior of Modal windows. If the user isn't allowed to do anything outside
the window, why should the program? Unless you were multi-threading, which
you can't do in Euphoria.
Matt
10. Re: Win32lib dialogs within proc's
You run into the same kind of problems with GTK and other libraries - you've
got to start up your own event loop, and read from that. The problem, as was
pointed out, was that the Destroy event can get missed, and Bad Things (tm)
will happen.
I was going to put in a modified event loop a couple of weeks ago, but
eventually came to the conclusion that it was too dangerous without looking
into carefully.
-- David Cuny
11. Re: Win32lib dialogs within proc's
- Posted by Grape_ Vine_ <g__vine at HOTMAIL.COM>
Mar 10, 2000
-
Last edited Mar 11, 2000
Ah i see, There is another way, but i dont know if it will work for you.
There are other dialogs that windows has builts in, some that are not in
win32lib, I have used them before but i am not sure of there names anymore,
I got them from the windows refrence from the MS web site. I think that
windows will provide you with what you need, If i new just what data you
want from the user i could give some/full code for that piece. I too dislike
the way data is handled in windows API prigramming...I look forward to
helping you, I am in need of a change of venue....
J Reeves
Grape Vine
ICQ# 13728824
>From: Matthew Lewis <MatthewL at KAPCOUSA.COM>
>Reply-To: Euphoria Programming for MS-DOS <EUPHORIA at LISTSERV.MUOHIO.EDU>
>To: EUPHORIA at LISTSERV.MUOHIO.EDU
>Subject: Re: Win32lib dialogs within proc's
>Date: Fri, 10 Mar 2000 07:59:26 -0800
>
>OK, I think I gave a bad example. Basically, I was using the
>getOpenFileName dialog as an easy way to get some input from the user in a
>generic sense. I guess what I'd like to do is be able to create my own
>dialogs that could be used in a similar manner. I think this works because
>you hand over control to windows using the common dialog, which does it's
>thing and then gives control back to Eu.
>
>Basically, I'd like to be able to 'emulate' that ability. I haven't been
>able to think of any nice solutions to this. I guess what I'd need is
>another event loop, like by nesting a call to WinMain within a call to
>WinMain. I guess that would require some sort of 'namespace' architecture
>on the part of win32lib, to keep controls of the various event loops
>separate.
>
>Hmmm. This would help me with something else that's been bothering me with
>windows programming. I've found that I have to make a lot of vars global
>(at least local, and not private to a routine), and use procedures
>everywhere to manipulate vars rather than cleaner functions and less global
>vars--since we don't know when the user will trigger any given event (eg,
>Button_onClick) and send us back to the main flow of our program.
>
>
>Matthew W Lewis
>
>
> > -----Original Message-----
> > From: Grape_ Vine_ [mailto:g__vine at hotmail.com]
> >
> > I am working on a project that sounds like it is close to
> > what you are
> > doing, Can you give me a clearer idea as to what it is you are doing?
> > You used
> >
> > file = getOpenFileName(Main, "", {"All Files", "*.*"} )
> >
> > as a example, IF you wanted to use a certian file name from
> > another part of
> > your program that would be easy, you change the code to
> >
> > object file_name
> > tons of code
> > file = getOpenFileName(Main, "file_name", {"File
> > description", "file_name"})
> >
> > Since i dont know just what your needs are my example is most
> > likely not
> > what you need
> >
______________________________________________________
Get Your Private, Free Email at http://www.hotmail.com
