I''m used to VB and now that i''m going over to c++, i''ve several questions: In VB, you ca use RaiseEvent myEvent(...) to raise a custom event from your object/class. What''s the equivalent in c++? and how do you catch it? thanks.

I''m not very used with c++ but try,catch,throw is used to throw exeption when calling a function, isn''t it?

I would like to send an event so that a method in the object''s owner is executed.

I don''t know exactly what you want, but I''ll give it a try.

You could use a method like, say event() in your class. If you make all your events objects that are instances of a certain class that provides for identification of the event type, you just make your event() method look up the event type and act accordingly.

If you just want to be able to say something like raiseEvent(someEventImadeUp) from anywhere, you''d have to do some more complex stuff like create a central list that contains pointers to all objects able to act on signal.

I need some sugar, thinking is difficult at the moment. So if the above makes absolutely no sense, please forgive me.

hmm...
it seems that events don't really exist in c++ !?
i've also searched on the web but didn't find precise stuff about it.

then, if there is no way to simply manage events (like in VB), another way must be found.
Is this the right way to do it (rigoursly):

let's call the classes A and B, where A is owning instance(s) of B. So if B send a so called event, it must arrive to A.
So, the way i thought to do it is:
- Creating a 'MyClassEventReceiver' class wich contains method which can be called to raise the event.
- a Struct or Class 'MyObjectEvent1' which contain the event's informations.
So every A class owning B must extend 'MyClassEventReceiver'. And the B class must contain a pointer to a 'MyClassEventReceiver' type object. And then call methods in 'MyClassEventReceiver' to send the corresponding event.

Is it the right way to do it?

[edited by - misterX on June 27, 2002 10:50:32 AM]

Events and event sinks are a part of the COM framework, and are made fairly transparent behind VB. There is no directly equivalent concept in Standard C++. The question that has to be asked is what problem are you trying to solve that you think requires an eventing mechanism?

Well...
in fact, it's not a problem.
I've some experience in game programming, small projects and OOP. And i'm now going on to some little bigger projects. But most of all, i want to construct them well!
And events are an important part of it.

for example, imagine the following object structure:
>Scheduler
--->IO
------>IOinput
------>...
--->MenuScreen
------>MenuInputInterpretor
------>...
--->GameScreen
------>GameInputInterpretor
------>...
--->other "screens"...


And now, we want to make the game... Let's say we project to implement IO and its components using DirectX. But in order to save time and to see results of the program as it is yet, we'll implement it with a simple visual window.


The MenuInputInterpretor and GameInputInterpretor are used to interpret what they receive from the input source (IOinput), that means (for example) it recieves mouseClic on (321,456) and give out 'Button32pressed' (or nothing).
Let's look at the way all that happens:
The myWindowClass handles the notification MyWindowClass::OnLButtonDown(UINT nFlags, CPoint point)
-> call myIOinput::mouseDown(button,x,y)
-> myIOinput calls myAttachedInputInterpretor::mouseDown(button,x,y) (this is the same as previously but would be different if using DX)
-> XXXInputInterpretor calls myParentClass::weaponSelected(...) (for example)

Well, it looks maybe a little complicated at first sight!
It's mainly because i want you to show the long flow events can generate.

And now, the way to implement all this. 3 possibilities i see for the moment:
1) You SUPPOSE all owner classes have the needed methods to call
2) Each parent object implement a specific Interface
3) Each parent object inherits these methods from an 'EventReceiver' class.


These 3 solutions have the same big problem:
the event methods can't be private! But they should be forbidden to call them externaly!
The myMenuScreen should not be able to call the method MenuInputInterpretor::mouseDown(button,x,y) !!!


Of course, this will not break down anything. It's more a question of rigour.

So, what's the solution ?


To simplify all this:
a class A and a class B. myA is owning myB. How can myB "activate" a reaction in A without making this function public ?


(and it's so simple in VB !!!)

[edited by - misterX on June 27, 2002 1:32:14 PM]

thanks