OpenEuphoria

Re: I need help with a text edit window

• Posted by Matthew Lewis <MatthewL at KAPCOUSA.COM> Oct 06, 2000
• 581 views

Derek Parnell wrote:

>  I'm not exactly sure by what you mean by "the program
> continues to run",
> but
> I assume you mean that the user is free to TAB or click into
> other fields.

Here's the generic situation:

Some event occurs, and suddenly your program needs some additional
information to continue processing.  In a console app, you might use
prompt_string/prompt_number to get some info from the user.  How would you
do this in win32lib?  You might create a separate window for this input, and
within your code:

--console
procedure someEvent()
--...do some stuff

--need something from the user to procede
x = prompt_string()

--...do more stuff
end procedure
-- end console

--windows
procedure someEvent()
--...do some stuff

--need something from the user to procede
openWindow(MyDialogWin, Modal)

--...do more stuff
end procedure
--end windows

In the console instance, your procedure doesn't continue until
prompt_string() returns a value.  In the windows instance, your code
continues immediately after the window is opened, without waiting for any
user input.  I had this argument with Irv, back when I originally came up
with implementing another event loop.

Here's a question :).  Do you use message boxes?  Same thing.

<snip>

>  This might sound "out-of-turn" so tell me if I should be quiet.
>
>  Environments that are event-driven, such as Windows
> programming,

<snip>

>  In short, dialog boxes are *not* in the pure philosophy on
> event-driven
>  programming. Instead, they are a way to make programmer's
> work easier, at
>  the cost of restricting users. Microsoft programs are great
> source of how
>  not to write programs. I recommend that you don't use Matt's
> work-around
>  (sorry Matt, nothing personal) but instead, make your code
> bend to the way
>  the user might want to work with the form. This is what
> *user-friendly* is
>  all about.

No offense taken.  This model of event driven programming is probably
sufficient for a database type application.  But suppose you're writing
something like a game.  You really need the functionality of a dialog box.
The way I'd implemented them, I call a function that 'wraps' the dialog.

Here's an example from my majuk project (a game based on Magic the
Gathering).  This is an excerpt of the code used to select a target.

-- begin code

-- target.ew
-- Matt Lewis
-- Choose Target Dialog
sequence target, TargetCards
atom TargetID
TargetID = 0
target = {}

--  Window TargetWindow
global constant TargetWindow = create( Window, "Choose Target", Main,
Default, Default, 352, 336+ 44, 0 )
constant TargetList = create( List, "List of targets here", TargetWindow, 8,
56, 328, 224, 0 )
constant TargetSelectButton = create( PushButton, "Select", TargetWindow,
36, 292, 90, 30, 0 )
constant TargetCancelButton = create( PushButton, "Cancel", TargetWindow,
204, 292, 90, 30, 0 )
constant TargetActionLabel = create( LText, "Targeting action description
here", TargetWindow, 8, 4, 332, 48, 0 )

procedure SetTarget()
-- fills controls with the data
end procedure --SetTarget

procedure TargetWindow_onOpen ()
    SetTarget()
end procedure
onOpen[TargetWindow] = routine_id("TargetWindow_onOpen")

procedure TargetSelectButton_onClick ()
    atom card
    card =  getIndex( HandList )
    if card then
        TargetID = card
        ExitEventLoop()
        closeWindow( TargetWindow )
    end if
end procedure
onClick[TargetSelectButton] = routine_id("TargetSelectButton_onClick")

procedure TargetCancelButton_onClick ()
    -- Cancel targeting...
    TargetID = 0
    closeWindow( TargetWindow )
end procedure
onClick[TargetCancelButton] = routine_id("TargetCancelButton_onClick")

global function choose_target(atom card, atom player,atom targets,
        sequence what)
    TargetID = 0
    target = { card, player, targets, what }
    EventLoop( TargetWindow, Modal )
    return TargetID
end function
-- end code

Basically, I can call this from any point to get a target.  It's like a
custom getSaveFileDialog.

>  In the situation you cited, which is not too uncommon, you can do few
> things
>  (if you must) to force the user to do things your way and not theirs.

<snipped a) & b)>

a) and b ) sound much too painful.

>  c) Create and open a new modal window that only has the one
> edit field on
>  it. The simplest from a programmer's point of view, but
> might not be very
>  user-friendly.

This is exactly the point, except that if you need the input from within a
routine, simply creating a modal window won't work.  You have to add that
pesky event loop.

Matt Lewis