sequential vs events driven

[Steve A.]

sequential vs events driven

Hey guys,
To all you language developers out there:

In the construction of Bxbasic, since Bxbasic has been up to this point
a Console mode, sequentially driven compiler/interpreter, I've never
had to be bothered about event handling.
i.e.: mouse roll-over, on-click, on-button, etc.

From those of you who are familiar with GUI and event driven models,
I'd like to know just how you are dealing with coding event handlers.

Related to Bxbasic, up to now, I've never done any GUI, event driven coding.
At this moment, I'm working on some GUI stuff, so that I can incorporate
some "Windows" specific GUI to Bxbasic.

One of the things I've uncovered and am toying with, is the notion that
I may not need two distinct compilers/interpreters to handle Console
mode -vs- GUI mode operation.

What I mean by that is, by using a single scripting engine that is
capable of handling both Console mode and GUI mode scripts, I may be
able to construct a single compiler/interpreter. As opposed to a distinct
Console mode engine and a seperate GUI mode engine.

That is, instead of requireing the user to select whether they want to
build a Console mode or GUI mode application, they simply make that
distinction by opening a GUI window or not, within the script.
Assuming that a standard console is the default method.

Or..., conversely,
if GUI is the default method, by not making a window visible at the start,
either a console can be opened or a GUI window can be made visible.

I have already constructed a test platform, whereby a console app can open
a GUI window. And, I know that a GUI window has the ability to open a
Console Mode window, (stdin/stdout and all).
And, I can open both, simultaniously, sending stdout to the console and
displaying text and graphics to the GUI window.

The issue I have to resolve is Windows events.

Programming in C/C++, generally WinProc() handles the events aspect.
Programming a Console mode engine is pretty straight forward, you simply
read-in what the next command is and execute it.

Example: from Bxbasic: function parser():

void parser()
{
    switch(token)
    {   case 1:                      /* LET */
            parse_let();
            break;
        case 2:                      /* CLEAR */
            clr_vars();
            break;
        case 3:                      /* LOCATE */
            locate();
            break;
        case 4:                      /* PRINT */
            parse_print();
            break;
        case 5:                      /* GOTO */
            go_to();
            break;
        case 6:                      /* BEEP */
            beep();
            break;
        case 7:                      /* CLS */
            cls();
            break;
<snip>


The question becomes; in a GUI mode engine, how do you test for events
and handle event messages ?

Those of you who are constructing GUI engines, are you dealing with
and handling events ?
Or, are you programming GUI in a sequential manner ?

Your input is greatly appreciated.
Steve

<cc: other forums as well>

[JRS]

Steve,

The trend I have noticed is to use multi-platform GUI toolkit. (Gtk, Qt, wxWidgets, ...) You're kind of stuck with the winAPI (message loops, SDKs, ...) on Windows.

I'm using GTK with ScriptBasic and it works great for the applications I write.

John

[jcfuller]

I'm using wxWidgets on both Linux & Windows with Bcx,Ubx,Mbc but it is a c++ library.
With wxWidgets you get native look on windows.

James

[JRS]

I believe MDI is MS Windows answer to a multiple window / single process applications. This is why I'm going the multi-threaded route so each window can operate independently.

[JRS]

No John...
This is not about MDI ,i know what you mean.
I mean open few windows as separate window or as child .

How would you manage the Windows message pump from multiple windows in a single threaded process? After using Linux as my full time desktop environment for the last few months, I keep saying to myself, was I that lazy and set in my ways that I would accept grief and frustration as a normal aspect of my day?

[JRS]

I have in plan use pointer for message loop.

Maybe one of the Windows gurus out there can shed some light on how to deal with multiple windows in a single process and not use a MDI container.

Good luck, I'm also interested in the feedback you get on this topic.

[Steve A.]

Thanks John...
I looking for Steve respond ,maby he have something concrete on his mind.

I don't have the answer for this Aurel.
I'm trying to avoid using (for the moment) GTK, wxWidgets, etc.
I want to learn how it all works using GDI, OpenGL, etc.

I guess what I want to do is create a "message pump" and intercept any app related messages and process them.
The problem I have is that I don't quite know where to begin..., what API functions I need to implement.

[JRS]

I don't have the answer for this Aurel.
I'm trying to avoid using (for the moment) GTK, wxWidgets, etc.

To quote a Godaddy site pitch, "You could be up and running tonight!"

Why don't you give GTK-Server a try. It comes with a Windows generic DLL and installing Gtk runtime under Windows takes less than a minute. Gtk-Server is more than just a Gtk GUI solution. I have scripted complex Linux interfaces with it and added threading to to mix. Until you know where your going, join the GTK-Server fan club and I'll even share my scripts with you.  

[Steve A.]

Here is code in C++ maby you get some point :
 ...[snip]

In EBasic i can crete one sub which contain adress of window procedure
and inside this sub is intercepted all window messages.

Hey Aurel,
I thoroughly understand the code snippet you provided for WinMain and WinProc.
What I don't understand is how I turn those into User Definable Commands.
Actually, it has more to do with WinProc. WinMain is not that hard to figure out.
I will explain what I mean by that, with an example, in my next post.

[Steve A.]

Okay, below is C code for a sample WinProc() callback function.
This is a normal looking WinProc(), which you might expect to see in any normal Windows GUI application.

Code: [Select]

LRESULT CALLBACK WndProc(HWND hwnd, UINT uMsg, WPARAM wParam, LPARAM lParam)
{
    PAINTSTRUCT ps;
    RECT        rect;
    HDC         hdc;

    switch(uMsg)
    {
        case WM_CREATE:
            hdc = GetDC(hwnd);
            break;

        case WM_PAINT:
            {
                BeginPaint(hwnd, &ps);

                GetClientRect(hwnd, &rect);
                DrawText(hdc, "Demo program using a private DC.", -1, &rect, DT_SINGLELINE | DT_CENTER | DT_VCENTER);
                DrawLine(hwnd);
                MakeNewFont(hwnd);
                DrawBox(hwnd);

                DrawRect(hwnd);
                DrawRndRect(hwnd);
                EndPaint(hwnd, &ps);
            }
            break;

        case WM_LBUTTONDOWN:    // left clicking on the client area of the window (white part)
            break;

        case WM_RBUTTONDOWN:    // right clicking on the client area of the window (white part)
            break;

        case WM_CHAR:   // character key
            break;

        case WM_MOVE:   // moving the window
            break;

        case WM_SIZE:
            break;

        case WM_DESTROY:
            PostQuitMessage(0);
            break;

        default:
            return DefWindowProc(hwnd, uMsg, wParam, lParam);
    }
    return 0;
}
/* ------ end WndProc ------ */

The problem, as I see it, is that a scripting engine/interpreter is not a normal Windows GUI application.
Or, perhaps it is and I'm just missing something.

If you look at the code snippet for the command parser, from my original post, shown here:

Code: [Select]

void parser()
{
    switch(token)
    {   case 1:                      /* LET */
            parse_let();
            break;
        case 2:                      /* CLEAR */
            clr_vars();
            break;
        case 3:                      /* LOCATE */
            locate();
            break;
        case 4:                      /* PRINT */
            parse_print();
            break;
        case 5:                      /* GOTO */
            go_to();
            break;
        case 6:                      /* BEEP */
            beep();
            break;
        case 7:                      /* CLS */
            cls();
            break;
<snip>
you can see that each Bxbasic command is listed sequentially in a switch/case loop.

What I have not figured out is:
1) how to combine the message loop with the command parser loop,
2) assuming I create Bxbasic commands to:
    a) create and open a GUI window,
    b) draw graphics in the client area and
    c) output text to the client area,

how does the user intercept the messages shown in the WinProc example ?
Not only that, but, how does the user define what messages to intercept ?

[JRS]

Steve,

Is your plans to remain a Windows only interpreter? It's a bit crowded in that space, don't you think? Even with ScriptBasic being an embeddable Basic, I have had very little interest from Windows users. If BXBasic is just a personal challenge and meant to be a tutorial on writing an interpreter, no need to read any further and may the force be with you.

I'm trying to find a niche by extending SB with dynamic scripting of 3rd party libraries and system APIs. The multi-threaded effort is just a personal challenge trying to find the limits of SB.

John

[Steve A.]

Hey Aurel,
Thanks for your help.
I appreciate your assistance and detailed explaining.
I may figure this out yet.

[Steve A.]

Hey John,

Is your plans to remain a Windows only interpreter?

No, that's not really it.
Before I commit to using a tool kit, I'd prefer to know how it works, at the lowest levels.
Sure, I could simply Plug'N Play a tool kit, but, that wouldn't tell me anything about how it works.
If a bug were to exist in either my code or in the 'tool kit', I'd prefer to know from an internal perspective how things work.

It's a bit crowded in that space, don't you think?

Oh, I'm sure.
New avenues are opening almost daily.

If BXBasic is just a personal challenge and meant to be a tutorial on writing an interpreter, ...

Well, I would like to write Volume-II.
In it I would like to take on the current topic of discussion.

[Steve A.]

Here you can see screenshot of testing how i open multiple windows.
http://aurelbasicsoft.ucoz.com/AOnepreview.png

Hmmm..., simple, interesting.

[JRS]

Aurel,

Nice job! Do you have all 6 windows sending messages to the IDE message processing loop?

Side Note:

I'm surprised you stayed on with E-Basic with the company being sold over and over.  What motivation keeps you from looking at other options? I understand that E-Basic is a community supported Basic compiler. Wouldn't it make more sense to take on the role of a project manager and support E-Basic as a language rather than creating an interpreter for beginners with it? I see E-Basic following the same road the RapidQ ended on. Does the new owner of the IWBasic version plan on future releases? My guess is Paul will come up with a new compiler that will encompass everything he has done in the past. Basic has found it's niche as a hobbyist language, creating custom applications for small businesses and a teaching aid for leaning how to program.

John

P.S.

E-Basic running under Wine with both a Mac and XP theme.