adonthell-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Adonthell-devel] Event system continued


From: ksterker
Subject: [Adonthell-devel] Event system continued
Date: Mon, 19 Apr 2004 10:17:14 +0200

Hi!

First of all some questions regarding map events:

Do we still have a grid? Or should map events be tied to a certain map object 
or area? Or should I leave map events for now, until we actually have a map 
again? ;-)

Now on to some good news:
I have completed and debugged the rest of the event stuff (haven't checked for 
memleaks, though). I'll give some details below, but I'll also add a chapter to 
the engine documentation.

The bad news are: I can't commit stuff at present as I still have net access at 
the office only. (And since the iBook has neither floppy nor CD-R drives, 
there's no easy way to get the code on my PC there) Sorry!


One thing I had to change in the underlying code was the Python instance 
passing. The present implementation did not support inheritance, which caused 
problems. When I pass a time_event, cast to event, SWIG would not know that it 
is a time_event, and prevent casting the event back to time_event.

So I changed things to add the get_type_name () directly to each class, thus 
recognizing a time_event, even when cast to event. The line in pass_instance is 
now arg->get_type_name () instead of get_type_name<A>(). That also has the 
advantage that the compiler complains if you try passing objects to python that 
don't provide a get_type_name method. With the old code, it would compile fine, 
but crash at runtime.


Other than that, the new event system has the following features:

* you can change the connected callback (or it's arguments) from within the 
current callback. That means we can keep the callbacks small and limited to a 
single task. If something else needs be performed, we can switch to a different 
callback.

* as all events that use callbacks from the same Python class share actually 
the same instance of that class, it should be possible for them to 
'communicate' via member variables. (That occured to me just now, so I haven't 
tested yet how well that will work). The problem with that is that the state of 
such variables won't survive a reload.

* destroying the event from within it's callback is also safely possible. The 
event managers take care of deletion after the callback returns.


One thing I wanted to look into is the following:
the steps to create an event on python side are:

# -- create the event
evt = event.time_event ("10m")
# -- aquire a pointer to a listener for that event
lst = event.factory.add (evt)
# -- register callback
lst.connect_callback ("file", "class", "method", (arg1, arg2, ...))

The problem is the second call. The event will be copied into the listener, and 
the listener will free it at the end of its lifetime. However, since the event 
is created on python side, it has it's thisown set to 1, which means that 
python will also delete it. Crash! For now, one has to manually set evt.thisown 
to 0, but a nicer solution would be to have that done automatically. This can 
probably done with a SWIG typemap, or the %feature(shadow) thing.

I will have a closer look at this. But I think we should generally take care of 
similar situations, to avoid errors because both C and Python think they are 
responsible of freeing objects. That caused a lot of trouble while coding v0.3 
python scripts, so we should do better in v0.4.

Okay, so much for now!

Cheers,

Kai

P.S: I'll look for a way to commit stuff, but it might take a while. I hope you 
have patience ...






reply via email to

[Prev in Thread] Current Thread [Next in Thread]