Board index » delphi » Event-driven programming - experienced programmers opinion needed!!! (EFLIB)

Event-driven programming - experienced programmers opinion needed!!! (EFLIB)

Hi.

I am currently writing a replacement of Borland Turbo Vision - an entirely
new application framework. The new framework is written in 100% object
oriented Borland
Pascal. I have run into some problems when I started to implement an
event-driven GUI.

       If you are qurious ... check this out:
       http://www.ts.umu.se/~jola/EFLIB/Manual/Advanced/Analysis.html
       http://www.ts.umu.se/EFLIB/

This is what I have come up with so far:

tMessage
 procedure Reject; virtual;
 function Sender : pComponent; virtual;
 function Receiver : pComponent; virtual;
 function IsBroadcast : boolean; virtual;

tComponent
  procedure Handle (Message : pMessage);
  procedure Send (...);
  procedure Post (...);
  fManager : pManager; { field }

tManager : tComponent
  procedure Handle (Message : pMessage); override;
  procedure Kill (Component : pComponent);
  procedure Register (Component : pComponent);

tCommunicator
  procedure Post (...); override;
  fQueue : pADT; { message queue }

I think you get the picture although this is very sketchy. I have some
problems. I must decide what properties I shall put into the tComponent
class. I will give it the flag "fLocked : boolean" that is set to TRUE if
it cannot receive messages.

The Post method calls the fManagers Post method, and so on until the
manager is a communicator that put the posted message in a queue.

My tComponent class is inherited into a tView and tGroup class just like
Turbo Vision. These classes will handle the graphical interactions.

Here are the problematic issues:

(i) I don't know how to make use of a message queue -  is it really
required?
(ii) Would it be wise to enable a program to have more than one message
queue?
(iii) How are keypresses etc put into the message queue? I have designed a
class extension of tComponent ===> tDevice that will post messages. Must I
implement more methods than just Handle - ie. Execute; virtual; that is
called systematically by the manager???

Your view on this would be very helpful. Also you may know some good books
or places on Internet where one can gain further information about
event-driven programming and its basics.

I am in desperate need of advice since the product is already very
delayed..

Best Regards,
Johan Larsson
j...@ts.umu.se <=== reply here!

 

Re:Event-driven programming - experienced programmers opinion needed!!! (EFLIB)


Quote
Johan Larsson wrote:

> Hi.

> I am currently writing a replacement of Borland Turbo Vision - an
...
> Here are the problematic issues:

> (i) I don't know how to make use of a message queue -  is it really
> required?

The main purpose of a message queue is to provide for asynchronous
messages, non-blocking SendMessage / method invocation, and
serialization of message processing.  Most messages in Windows are
direct calls of the window procedure of a window, queued messages
are mostly i/o (kbd, mouse).  You should be able to achieve much
of the same by using threads, but then you'll have to implement or
find/buy a thread manager (simple co-routines should be sufficient).

Quote
> (ii) Would it be wise to enable a program to have more than one
>     message queue?

Absolutely.  If you go for message queues, use one per thread.

Quote
> (iii) How are keypresses etc put into the message queue?

That's your responsibility.  Basically, you can either hook the
keyboard interrupt (get Ralph Brown's interrupt list) or poll the
keyboard buffer.  Hooking lets you implement your own keyboard
handling, e.g. placing auto-repeat *after* buffering (if so, you
need to swallow auto-repeats generated by the keyboard).  For the
mouse, you can install a callback.  See MS Mouse Technical Manual,
I think it was called.  Anyway, this is pretty low-level stuff.

- Alf

Re:Event-driven programming - experienced programmers opinion needed!!! (EFLIB)


Re:Event-driven programming - experienced programmers opinion needed!!! (EFLIB)


Hi Alf,

Quote
> The main purpose of a message queue is to provide for asynchronous
> messages, non-blocking SendMessage / method invocation, and
> serialization of message processing.  Most messages in Windows are
> direct calls of the window procedure of a window, queued messages
> are mostly i/o (kbd, mouse).  You should be able to achieve much
> of the same by using threads, but then you'll have to implement or
> find/buy a thread manager (simple co-routines should be sufficient).

Yes, but how should one provide access to that message queue. I have just
implemented a receive (HandleMessage) method, a post and send method, and a
Idle procedure --- these methods should be provided by all components.

When should queued messages be sent to components --- must I implement
somekind of GetMessage or WaitMessage machinery (why?) --- and how do I
handle (in that case) messages dispatched from the queue to the wrong
component, like this:

 A.GetMessage (M);
 Ooop! M is for B, not for me.
 1) Give it back to the message queue? or 2) Send it directly to B???

If you would like to, I could send you my specification so far, as a RTF or
Word DOC file. Its also available in various newsgroups. The filename is
R3-Alfa-1.zip.

The Idle method is now used only for polling (see my specification). But
polling is also a dilemma --- the Idle method must be able to force
messages of the queue when it want to.

So, maybe (you tell me) I should implement these methods as well:

   GetMessage (how should it work?)
   WaitMessage (delayMS : word; M : pMessage);

Also, I have decided to create the event-mechanism in two steps: first I
define the event-machinery in a design I call Component-Manager
Architecture (just to call it something --- see the specification). Then
--- when C-M architecture is working (later, later) --- I will extend the
classes into tView or tInteractor etc. etc.

Quote
> > (ii) Would it be wise to enable a program to have more than one
> >     message queue?
> Absolutely.  If you go for message queues, use one per thread.

Yes, I will go for message queues. I have already designed a
tProcessManager (name may change) like the macintosh. This class is
responsible for the system message queue (or whatever you may want to call
it) and the Idle-processing (sending polling messages). See the
specification for details!!

But when and how should I implement more than one queue? Could you please
explain a bit further?

Quote
> > (iii) How are keypresses etc put into the message queue?
> That's your responsibility.  

I have already dealt with this in the specification. Basically, I use two
messages types: keboard and mouse types. These are low-level and high-level
messages for keyboard and mouse (key-down, mouse-down=low-level,
mouse-drag=high-level).

Thanks for your help.

Johan Larsson.

PS. You may be interested in the specification. Mail me.
       If you wonder what EFLIB is. Check out http:///www.ts.umu.se/EFLIB/
       and especially
http://www.ts.umu.se/~jola/EFLIB/Manual/Advanced/Analysis.html

Regards,
J.

Other Threads