while not ivelin.knows():
ivelin.listen(nathan.tells_secret()) # important lessons
ivelin.digest_information(duration=1.0) # side effect: may change outcome of 'knows()'
I’d love to see how the two classes look like.
It will be very educational.
I crashed rhino only three times last night. I managed to make both key event to work as well as the timer, but not able to stop the timer using the key.
Btw, the exanple above is triggered twice, upon keyDown and keyUp. How can I do it once?
Global variable is actually not that smart here. It is much better to encapsulate in a class, pretty much like the event handler class, and stick it in the sticky dictionary. Most important lesson here is that you were creating a new Timer each time you called your Main.
But it prints only once, right? the self.sel_down is the variable holding the state. I mentioned in an earlier reply that you have to keep track of key state yourself, this is it. Assume that on first running of the script nothing is pressed. Then for each key each event toggles state.
It isn’t necessary, you can do two classes. I was just lazy and wanted primarily to show that you shouldn’t create a new Timer every time (pun intended).
I did want to clean out the icky use of exec. Don’t do that ever - unless you’re writing a parser and want to run live code changes… But still, don’t do that ever.
it prints twice if you press slowly. Can I manipulate the “hold” time somehow?
I have to admit, I didn’t know I can store class instance in the sticky
But also my implementation allows me to use the same helper function for any key event. Or any event for that matter by simply changing the string in exec(). I’m a script kiddie, copy/paste working code is essential. Even if it is done by me . When I create code about something today, and I have to do the same code in half a year from now. It will most certainly be different. Maybe that’s normal but I prefer to copy existing code and adjust to the desired functionality.
Why, what is the issue with it? I like live code. I actually think if Rhino was made to allow subprocesses of the python engine to run without locking Rhino. It all would run much faster and more reliably.
I guess that is the key repeat. Not sure how to work around that.
For event handlers I look in our dev samples repository:
If you make a mistake there will be a crash instead of the script just failing to start.
No idea about that. I don’t know how the internals work for IronPython, but doing so with CPython requires great care with the GIL, and access to data in the document (from my Blender coding experience).