spinner events


#1

So the script I’ve done is finished in its raw form, and I want to wrap it it a nice UI - because the 20+ parameters are getting out of hand, haha.

No problemo, a fast little macroscript wrapper will do the trick, and its shaping up nicely.

I got a couple of spinners. I would like to be able to distinguish between mouse-operations (ie. fiddle your value and press a button when done) and direct keyboard input - type a number, hit enter. No sweat - according to the documentation (5.1) the spinner on entered do event only fires on leaving the input field;

[b]

[/b]
[b]on <spinner> entered do <expr>
Called when the user types a number into a spinners edit field and then presses ENTER or presses TAB to move the cursor out of the field. The on <spinner> changed handler, if supplied, has already been called at this point and the spinner’s value property is up to date.

[/b]

as seen opposed to

[b]

[/b]

on <spinner> changed <arg> do <expr> Called when the user spins the spinner, or when the user enters a value in the spinner field then presses ENTER or presses TAB to move the cursor out of the field. The <arg> argument will contain the newvalue of the spinner.


But ah - Nu uh, it fires on every damn click on the spinners /cry And no, I’m not entering the field and then clicking a spinner (which while a flawed implementation would hold up against the documentation ;p) . Anyone got a workaround for it ?


#2

According to my copy of the documentation, this is not the case:

[left]on <spinner> entered do <expr>[/left]

[left]Called when the user types a number into a spinners edit field and then presses ENTER or presses TAB to move the cursor out of the field. Also called when the spinner is released. The on <spinner> changed and <spinner> buttonUp handlers, if supplied, have already been called at this point and the spinner’s value property is up to date. [/left]

This was a bug in the documentation which was fixed in 6.0 to reflect the actual behavior.
Sorry for the trouble.

Cheers,
Bobo


#3

Allright Bobo, thanks much for the pointer - also why I quoted version and direct text, otherwise it gets to be too much fluff :slight_smile:

I noticed that popping a msgbox in the on changed event would cause the on entered event to not fire - my instinct tells me its due to loss of focus - another reason could be parallelism, but I think the focus loss might just be the cause - ahh, not to mention easier to tamper with.

Hrm, Suppose I’ll have to see what I can do to emulate that behavior, without the showstopper of a messagebox - quickie little activex that does some fluffing with focus perhaps, but hmm, is possible that max completely bypasses the windows eventmodel - no clue - yet!

Time to do a full little cascade trace - I should have done that from the start out, I could kick myself for such n00bism.

By the way - Way to go on bringing Maxscript’s documentation to the state its in, good stuff :slight_smile: Soo, whats the odds on a fully hierachical navigateable object model (You know, one of them couple hundred odd hour jobs *grin) ?


#4

Who is paying the bill for the hundreds of hours? :wink:
Seriously, you are still going to love the next iteration of the MAXScript Reference.
(I think it alone is worth the upgrade price, but I am biased)


#5

This thread has been automatically closed as it remained inactive for 12 months. If you wish to continue the discussion, please create a new thread in the appropriate forum.