Event driven programs in a multithreaded/multitasking environment tend to end in a deadlock somewhere :)

Something similar can happen with Poser and Python. Poser starts your scripts (better: asks Python to execute your script). Under normal circumstances Poser holds anything until your script ends. But if your script starts Tkinter, you give control back to Poser. If something is changed, Poser may report this to your script (Callback Events). If you like to live with risk, you may call "ProcessSomeEvents()", handing control back to Poser. Poser may generate the same event another time, before the first call became a chance to end.

Another nice way is this: To make a dialog stay on top, some people are using a timer interrupt to get control back. If only the screen is updated, anything may work fine. If callbacks are used there is a great chance to end in a crash (sooner or later).

Uncountable similar scenarios are possible and I would be able to declare most of them - but not in english, sorry :)
Errors caused through wrong event driven programming concepts are often hard to find. Because such an error may not occure if your testmachine runs faster (because you have more RAM, no other apps running at the same time, you BS does mutitasking smoother, or while it is cloudy weather).

I think you are right with:
I was kind of wondering if a disagreement between tk.mainloop() and the callback loop might be what crashes P7

And I think the problem is not the tk.mainloop/callback, but the wrong handling of this :)

Ok, a framework for Poser Python scripts is a bit longer on my To-Do list now. Some sort of infrastructure any script may use. With this it would be possible to run several different scripts at the same time. And writing scripts for Poser would be a lot easier.

---