Re: [pygame] USEREVENT

[Jan Ekholm <chakie@infa.abo.fi>]

On Mon, 2 Jul 2001, Pete Shinners wrote:

[USERVENT question schnipped]

>ok, the Event types are the only thing you can post on the stack.
>they are actually python extension types, not classes that can
>be derived from. still, they are plenty flexible to give you what
>you want.

Yes, I understand them now. I should learn to use the interpreter more to
test out things, but I'm too stuck with the C++/Java mentality that
everything has to be compiled first. I did some tests, but got a few weird
problems, that I can probably attribute to running PyGame 0.9?


>as for the dict/keyword-args initialization. in previous pygame 
>releases, you could only create a new Event by passing a dictionary
>containing all the properties and values for the event.
>
>>>> props = {'source': self, 'time': time.get_ticks()}
>>>> event = event.Event(USEREVENT, props)
>
>now the dictionary method is a lot more flexible, but for most of
>the time, a couple string property names are all you need. with the
>new keyword arguments you can shorten this process to
>
>>>> event = event.Event(USEREVENT, source=self, time=time.get_ticks())

These latter method did not work, but I assume it's new in 1.X (I still
run 0.9). Tried to upgrade to 1.1, but the dependencies are far too new
for my system (Mandrake 7.1/7.2). Building from source did not work, as
the old version of Python I had was installed in /usr/local and not
/usr/lib. Tried upgrading Python to 2.1, but I managed to fubar
everything, so now I'm stuck without Python too. Deadbeef.

As soon as pygame materializes in Debian testing I'll nuke this and go for
Debian.

[good example schnipped] 


>just small sampling there, just remember that you really can pass
>any type of python object into the event queue, and also remember
>that using 'event id types' is not really the best way to handle
>things in python. it is easy to add your own "secondary" type id
>if you want to, but first i'd sit and think about how i could solve
>the problem without them, then decide which method would work better.

Thanks for the example code, Pete, and the overall help. 

Our framework is however quite C++:ish, so id:s seem to be the best way to
do things. It's not the real Python way, but I'm not yet a real Python
programmer either, so it will suffice. We'll have plenty of time to rip up
the code as soon as we get a 1.0 of the game out. Looking forward to that
day... :-)

-----------------------------------------------------------------------------
      Real children don't go hoppity-skip unless they are on drugs.
           -- Susan Sto Helit, in Hogfather (Terry Pratchett)

____________________________________
pygame mailing list
pygame-users@seul.org
http://pygame.seul.org