log in | register | forums
Show:
Go:
Forums
Username:

Password:

User accounts
Register new account
Forgot password
Forum stats
List of members
Search the forums

Advanced search
Recent discussions
- WROCC Newsletter Volume 41:11 reviewed (News:)
- WROCC March 2024 meeting o... Hughes and Peter Richmond (News:1)
- Rougol March 2024 meeting on monday with Bernard Boase (News:)
- Drag'n'Drop 13i2 edition reviewed (News:)
- South-West Show 2024 talks (News:4)
- February 2024 News Summary (News:1)
- Next developer fireside chat (News:)
- DDE31d released (News:)
- South-West Show 2024 Report (News:)
- South-West Show 2024 in pictures (News:)
Latest postings RSS Feeds
RSS 2.0 | 1.0 | 0.9
Atom 0.3
Misc RDF | CDF
 
View on Mastodon
@www.iconbar.com@rss-parrot.net
Site Search
 
Article archives
The Icon Bar: Programming: Event based programming outside the WIMP
 
  Event based programming outside the WIMP
  (12:26 14/1/2001)
  johnstlr (09:43 15/1/2001)
    Gulli (13:58 15/6/2002)
      johnstlr (18:39 25/1/2001)
  GavinW (09:57 16/2/2001)
    johnstlr (13:18 16/2/2001)
      Gulli (13:58 15/6/2002)
 
Gulli Message #4712, posted at 12:26, 14/1/2001
Unregistered user I'm on the brink of writing a program that will run outside the WIMP but I want to make it event driven. I'll be writing it in C++.
What I wish to do is to write a class that checks for all input from keyboard and mouse (clicking, dragging, double-clicking etc) and then sends out an event to objects that have been created using various classes. Classes would include windows (the "windows" would at first really be full screens but would evolve), buttons, labels text fields etc. It's sort of what's done in Windows (and with the Toolbox modules I think).

What I really need to know is what is the best way of doing this, how do I create the event and send it to the correct object?
Do I make the event class keep track of all objects that are running and figure out what object is supposed to get the event or do I make the event class only know which window is in front and has focus and send it to that window to figure out who's to get the event?

How would I construct the event part of the basic classes (window, button etc).
One way I've thought of is to make all the classes accept all events, creating an event class all classes would inherit, and simply return them all unless the corresponding function was overridden or is there some easy way to let the class accept only the events it wants? I guess that would require the object to register itself with the parent object or the event generator and request the events it wants but I think that would require me to create an event mask in every object that is generated so it's a little less appealing but should be easy to implement.
Speed is not of much issue at this point but is always worth considering. What I might want to do is to create a sort of multi-tasking environment inside the program so that null events might be used for some small calculations etc. That probably requires the event mask.

Does anyone know of any good website or a good book that explains clearly how to write an event generating engine and class like I'm trying to explain?

Gulli

PS. If I'm not explaining this clearly enough please just ask.

  ^[ Log in to reply ]
 
johnstlr Message #4713, posted at 09:43, 15/1/2001, in reply to message #4712
Unregistered user Blimey, there are lots of ways to achieve this in C++.

A great book on OO programming is

Design Patterns: Elements of Reusable Object-Oriented Software

Erich Gamma, Richard Helm et al
ISBN0-201-63361-2

My copy was about £30 but it's probably cheaper on Amazon. For those who don't know design pattern describe common programming constructs in OO programming - this book is basically a wealth of experience on how to solve particular problems in OO design. However, having said that it doesn't have a general eventing mechanism - partially because it has several different ideas. Further ideas on patterns can be found from

http://hillside.net/patterns/patterns.html

Anyway back to your question. Whatever you decide to do you only want to send events to the objects that actually want them. This means that objects should register themselves with some event manager.

How objects receive events is up to you. One way is to group common events (window opened, window closed etc) and then define abstract classes which much be implemented by objects which want to receive those interfaces. Java works like this. Anyway your objects register themselves as wanting to receive a specific block of events and the event manager merely calls the appropriate method on the objects interface. The nice thing about this is that it's neat, it's easy to see how events should be handled (fill in the virtual functions) but it's also difficult to add new events.

A better approach might be to design a generic event interface, something like

class CEvent {
public:
CEvent(int t) { type = t; }
int eventType() { return type; }

const int EVENTTYPE1 = 1; // Bits
const int EVENTTYPE2 = 2;
const int EVENTTYPE2 = 4;
...
private:
int type;
};

class CEventHandler {
public:
virtual boolean eventHandler(CEvent &event) = 0;
};

All classes are derived from CEventHandler and implement the eventHandler method. All this method looks like is a switch statement decoding the event and taking the appropriate action.

Then you can have an event manager with an interface like

class CEventManager {
public:
boolean register(CEventHandler &object int eventMask);
boolean unregister(CEventHandler &object int eventMask);
};

The event manager contains a list for each possible event. The register method places the object on the list for each event in the event mask. The unregister method removes the object from the event lists specified in event mask. As events occur you traverse the appropriate list creating events and calling the object handlers.

The only flaw with what I've said is that the CEvent class assumes that all events have the same form (ie you don't pass event specific data to the object). What may be better is to make CEvent an abstract class and derive specific event classes from it. The evenHandler method can then cast the CEvent object to the object appropriate to the event.

Hope that's some help. I have a generic event mechanism in C which was written for a game engine. Let me know if you want me to mail it to you. It's not as powerful as what I suggest above but it may give you some ideas. Failing that it's part of the OS/G distribution at

http://www.comp.lancs.ac.uk/computing/users/johnstlr/riscos/threed.html

although this is a 300k download. The source files are Event.c and EventH.h

[Edited by johnstlr at 09:44, 15/1/2001]

  ^[ Log in to reply ]
 
johnstlr Message #4715, posted at 18:39, 25/1/2001, in reply to message #4714
Unregistered user No probs. As for the patterns what I tend to do is dip into them when I have a problem I want to solve and see if someone has solved it already. I did try reading about them but it can be too much information to take in.
  ^[ Log in to reply ]
 
GavinW Message #4716, posted at 09:57, 16/2/2001, in reply to message #4712
Unregistered user Dear Gunnlaugur
Maybe I have misunderstood what you want, but why not set up each object as a wimp task, and
use the Wimp_SendMessage SWI for communication
between them? All your event machinery is already
built in to RISC OS.
-- Gavin Wraith
  ^[ Log in to reply ]
 
johnstlr Message #4717, posted at 13:18, 16/2/2001, in reply to message #4716
Unregistered user I would guess that this isn't practical for two reasons

1) He states that his program runs outside of the WIMP. It's not a Wimp task so the facilities built into RISC OS aren't applicable.

2) It seems that the requirement is for event passing in a "single address space". Structuring the program as a series of co-operating Wimp tasks is a) complex and b) more heavy-weight.

Finally he might be doing it to learn about eventing mechanisms rather than just using one.

  ^[ Log in to reply ]
 
Gulli Message #4714, posted at 13:58, 15/6/2002, in reply to message #4713
Unregistered user Thanks Lee, this all sounds like exactly what I was looking for. Haven't had a chance to look at your code yet but the patterns site is quite interesting, a lot more info than I'll have time to grasp in the near future smile
  ^[ Log in to reply ]
 
Gulli Message #4718, posted at 13:58, 15/6/2002, in reply to message #4717
Unregistered user
I would guess that this isn't practical for two reasons

1) He states that his program runs outside of the WIMP. It's not a Wimp task so the facilities built into RISC OS aren't applicable.

2) It seems that the requirement is for event passing in a "single address space". Structuring the program as a series of co-operating Wimp tasks is a) complex and b) more heavy-weight.

Finally he might be doing it to learn about eventing mechanisms rather than just using one.

Correct on all three accounts smile
Mostly I'm doing this to learn the eventing mechanisms, writing the program itself is merely a way of learning how but it might become useful on its own.

Gulli

[Edited by Gulli at 14:32, 16/2/2001]

  ^[ Log in to reply ]
 

The Icon Bar: Programming: Event based programming outside the WIMP