For those of us with little css experience:
css stands for Cascading Style Sheets.
http://www.w3.org/Style/CSS/Overview.en.html has a huge amount of information, including a
link to http://www.w3.org/MarkUp/Guide/Style Dave Raggett, 8th April 2002 ...short guide to styling your Web pages... with
basic named colors explanation.

Finally found moi.css under c:\Program files (x86)\moi 3.0 betaOct-25-2011 \ui. (Clicked on column header "Type"),
with file name "moi" and file type "css" .

For a slider on a new MoI script, do not believe it is necessary to mess with css at all.
May add a line or two to the EnglishStrings.txt such as " Euler spiral curvature slider label=Curvature ." (I think)

I finally got the "Curvature" slider to display correctly, but there is no binding of changing values.

Still need to BIND the Slider Curvature value "nValue" to "value", (like Twist Slider "easein" to "value"), without using a factory input,
(like "moi.ui.bindUIToInput( 'easein', 'value', factory.getInput(5) );").

Based upon May 2010 post with Dave Morril and Trim, Michael said:
"Also I (Michael) should mention that there are a few of varieties of binders, there is one that goes on HTML elements in the UI, which are set up with a bindingx="" attribute."

My question is: How to bind a slider value name (like Twist "easein") to its changing slider 'value'?


Edit found : bindUIToInput string uIElementId,
string uIElementProperty,
GeometryFactoryInput input

also found: bindPropertyChangeFunc object object,
string propName,
object func

and bind object pdispTarget,
string targetProperty,
object pdispSource,
string sourceProperty,
boolean twoWay

Hi Brian, sorry I think I misunderstood what you were asking about previously.

I had thought when you asked about sliders being used elsewhere, you were asking about using them totally outside of MoI like on a regular web page on your own web server, but it looks like you are asking about using them in a new plug-in command.


> For a slider on a new MoI script, do not believe it is necessary to
> mess with css at all.

That's correct - if you're using them in a plug-in command you don't need to mess around with the css at all, you would only change the css if you wanted to change how the sliders actually looked within MoI.


> May add a line or two to the EnglishStrings.txt such as " Euler spiral
> curvature slider label=Curvature ." (I think)

You can do that, but once again I may have mislead you a bit - for all of MoI's built in commands the text comes from those string tables.

But when you're doing a plug-in command it's kind of hard for the plug-in to put its text in those string tables because it would mean modifying a bunch of files instead of only placing in new files in the \commands sub-folder.

So when you're doing a plug-in command that you want to be able to send to other people, for that case it is probably better to just put in your hard coded text directly into the HTML instead of using the string table mechanism.

In the future I want to make it possible for a plug-in to have a kind of mini string table that can come along with it so that it would be easier to have translated text for a plug-in but for right now there is no mechanism like that.

- Michael

Hi Brian, re: binders - there are some commands that set up a binding between a slider and a text input field, like Twist.htm or Blend.htm so you could look in those files for a current working example.

But basically you first need to give each control an id="" attribute - that will then give it a name that can be referred to in script.

Then if you want to tie those 2 controls together so when one is changed the other will be updated, you can use a binder to do that. There are a few different ways to set up binders, but in a case like this is it easiest to use a binding map attribute - in v3 that's a binding="" attribute that you can declare on a control. There are also a couple of different forms of binding maps, the most simple which can be used in this case is a direct assignment 2-way binder, which is just 2 properties that have an = between them. With that kind of binding map, MoI will monitor each property and when it is changed reflect that value onto the other one. So with 2 controls that will have the effect of keeping the controls synchronized to one another.

Here's an example:

    <moi:Slider id="myslider" value="1.0" min="1.0" max="10.0" />
    <moi:NumericInput id="myinput" binding="this.value = myslider.value" />

That will create 2 controls, a slider and then a numeric input field. The numeric input field has a binder="" declared on it which will cause the values of the 2 controls to be synchronized - that binding map means that any changes on the property on one side of the = will then cause the value on the other side of the equal to be updated - in this case it will cause the slider and the input field to be synchronized to have the same value.

Then since they will have the same value, in your command script you can retrieve the value from either one of them, it doesn't really matter which one you get it from.

There are other kinds of binders as well, like setting up a binding between a UI control's value and a geometry factory's input slot so that any time the UI control's value changes it will then apply the new property to the geometry factory and call .update() on it - when you set one of those up then you don't have to do any manual event handling of that control after that.


Hope this helps!

- Michael

Thank you very much Michael.

The display of the slider seems fine. The value changes in the little box. CSS is not modified.




But moving the slider has no update effect. I think that an UPDATE in .js for the slider, nValue, or curve_slider.value is needed, but have not been able to
puzzle it out. Twist uses the factory "input slot", so it doesn't help.

Question: What is the proper "update" script in .js?

The standard if ... dlg.event == 'nValue.' || dlg.event == 'curve_slider'... update... does not seem to help at all.
(If the slider is changed, done pushed, an the script restarted, the slider value does change.)




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

Thank You

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!