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!