Hi Brian, so it looks like the slider does not automatically fire a "UI event" when it is changed which is why you're not getting the updates in your script. That's a bug that I should be able to fix up.

At the moment a quick fix is to set up a handler for onvaluechange="" on the slider which is fired when you release the mouse after adjusting the slider. You can then fire a UI event from inside there, that should then get things working like you were expecting.

The way that works is you add in an inline event handler for the slider saying:

onvaluechange="moi.ui.fireUIEvent(id);"

That means that when you do an adjustment and release the mouse, your script will get an event of that slider's id value like you were expecting to get. The whole slider with that event handler on it would look something like this:

<moi:Slider id="curve_slider" onvaluechange="moi.ui.fireUIEvent(id);" value="2.0" min="0.0" max="3.5"/>

I'll tune up the slider for the next release so that you won't need to add that onvaluechange="" part, it will automatically fire the UI event.


The other part of your script that says: dlg.event == 'nValue.' should actually fire already, (as long as you don't really have that extra . character in there at the end, that looks like a typo just in the message above?) when someone clicks on the edit field and changes it directly instead of it getting changed from the slider update.


> In your code example, is the "this" in (...id="myinput" binding ="this.value = myslider.value" />)
> a required syntax word, or just an example?

It's not required, it's optional, I just added it to try and clarify what was going on there - if it's not there it's implicit that the property on the left side of the = belongs to the element that the binding="" attribute is actually declared on.

Another optional part is that you can leave out the mid="" declaration on the slider if you want the mid to just automatically be 1/2 the way between min and max - it's only there if you want to have slightly different spread ranges for the left half and right half of the slider.

Hopefully this is all making sense? :)

- Michael

Hi Brian, also looking back in this thread you mentioned:

> Edit...Do not want to exceed the allowable modifications...(?)

Are you talking here about a forum message edit, or modifications to MoI's commands?

You can certainly modify anything that you want in MoI - that's one of the interesting things about MoI is that you can have access to all the UI that makes it up and edit it and also create new commands with your own scripts.

The only caveat is that during the beta period some parts of the UI toolkit may change and that could possibly mean that modifications that you make that depend on things that have changed may not directly work anymore...

Even just fixing bugs can change things, like in the next beta when that slider bug is fixed you'll probably want to take out that event handler for onvaluechange="" so that you won't get the UI event twice in your script.

- Michael

Many thanks Michael.
Will try out your excellent information tonight.

(Did not think I should modify MoI programs, like css ... :-)) )

Hi Brian,

> (Did not think I should modify MoI programs, like css ... :-)) )

I see - you can modify the css if you want, but it's not necessary to modify the css just to make use of existing controls in a new command - the css basically controls the visual style of the UI so it would be something you would only edit if you wanted to change how the controls looked.

You can also apply "inline css" that's attached directly to a single element - that's what those style="" declarations do. That allows you to override the default css properties for just one particular control. The main moi.css file basically sets up a lot of stuff that sets the default appearance of various controls and UI elements. This mechanism of inline styles overriding the default style sheet is what the "cascade" part of the c in "css" is about.

Some of the frequent kinds of inline css that you might use are setting an element's width, or setting it to style="display:none" so that it's hidden initially.

- Michael

Hi Michael

The Slider now works, including the edit box (without extraneous period.)!!!
All of your information was 100% correct.

The UI section got wide. I'll put back in the inline style code from twist command, to slim it back down.

Wonder if the arrow keys on the keyboard can control the slider?

Thank you again.

I should post the Euler spiral script now...

Hi Brian,

> Wonder if the arrow keys on the keyboard can control the slider?

Right now there isn't anything set up for that, but that could be a good idea for the future.

It would probably involve some tweaks in control focus handling though - currently the system is set up to make it easy for any typed characters to be handled as input into the the first numeric input field that's present in the command UI, or on to the XYZ control if there isn't any edit field in the command UI.

That's why you can do something like run the Circle command and then just type 5 and push enter without actually needing to click on the radius field first before typing - when you type 5 the focus automatically goes to that field and puts the keystroke in there.

- Michael

That reminds me that if you are for example making a 1D scale and you type something, it takes you to the scalar factor field but if you want to enter a dimension, you can't access that field from the keyboard (tab doesn't work). Is that true or I'm i missing something?

Hi ed, yup that's correct - if there is an input field for the command either typing characters directly or pushing Tab will put focus in that edit field and if you want to go to the xyz input field you have to click on it in that particular case.

I could add in some kind of modifier key that would make focus always go to the XYZ input field though. What about using Ctrl+Tab for that, does that sound like it would work?

- Michael

That sounds good, but a more common shortcut may be the inverse tab (shift+tab) that may be more easy to remember.

Hi ed,

> That sounds good, but a more common shortcut may be the
> inverse tab (shift+tab) that may be more easy to remember.

That could be possible, but the problem with that is that shift+tab can be used in other situations like if you've got focus on the 2nd field in a command that has 2 fields in it like Rectangle. In that case using shift+tab moves focus to the previous field, and it's probably not good to remove that behavior so that would mean that there wouldn't be a single key combo that would always put focus into the XYZ edit field if shift+tab was used for that only in the case of nothing having focus yet.

If ctrl+tab is used, that can work universally I think.

- Michael

yeah been moi wide it will be a frequent shortcut and you'll have to remember it!