Parameters of scripted component (mcu)
I added a parameter of type "string" to a scripted component like it is described at https://simulide.com/p/scripted/#the-script-language
The parameter shows up in the property dialog of the component but any value entered is forgotten once the dialog is closed. Where is that parameter saved? Is this related to the setter and getter function which must be implemented?
Are there other types than integer, double, string? E.g. a selection menu with a predefined list of values?
Where is that parameter saved? Is this related to the setter and getter function which must be implemented?
The parameter is saved in the script, and it's related to the setter and getter.
The script can use a variable to store the value and set it in the setter.
The property dialog will get the value from the getter.
So to "remember" the value save the value in the setter and return it in the getter.
Are there other types than integer, double, string? E.g. a selection menu with a predefined list of values?
By now these are the types supported: int, uint, double, bool, string.
Lists are not supported yet, but it is planned.
Quote from arcachofo on January 9, 2024, 7:33 amWhere is that parameter saved? Is this related to the setter and getter function which must be implemented?
The parameter is saved in the script, and it's related to the setter and getter.
The script can use a variable to store the value and set it in the setter.
The property dialog will get the value from the getter.So to "remember" the value save the value in the setter and return it in the getter.
I though so, but for some reason it's not working. Here is what I did so far:
<mcu name="Programable Sequencer" core="scripted" script="ProgSequencer.as" prog="8096" progword="1">
<propertygroup name="IR">
<property name="protocol" type="string" />
<property name="model" type="string" />
</propertygroup>
<ioport name="PORTI" pins="D0,D1,D2,D3" />
<ioport name="PORTO" pins="Out" />
</mcu>string protocol;
string model;
void setProtocol( string val ) {
print ("Call setProtocol()");
protocol = val;
}
string getProtocol() {
print ("Call getProtocol()");
return protocol;
}
void setModel( string val ) {
print ("Call setModel()");
model = val;
}
string getModel() {
print ("Call getModel()");
return model;
}The properties dialog for the component contains the two properties
When I enter something in the protocol field and than click on the model field, the value in the protocol field disappears and neither of the setters or getters is called.
Are there other types than integer, double, string? E.g. a selection menu with a predefined list of values?
By now these are the types supported: int, uint, double, bool, string.
Lists are not supported yet, but it is planned.
Fair enough for now. I suppose a string will remain a string anyway, even if it is chosen from a list of values. Hence, the script won't change, just the xml file and the gui.
Property name ad getter/setter must be exactly the same:
name="protocol" -> getprotocol()
name="Protocol" -> getProtocol()
I suppose a string will remain a string anyway, even if it is chosen from a list of values. Hence, the script won't change, just the xml file and the gui.
Yes, lists are always strings.
So when it is implemented getters and setters will be: string getProp() and void SetProp( string )
The only thing that you will have to change is property type from "string" to "enum".
Additionally you will have to implement an extra function to populate the values in the list that will return an array of strings:
When the property widget is created it will call the script asking for the list of strings in the dropdown list.
Thanks. Changing names made it work.
On page https://simulide.com/p/scripted/#the-script-language a property named prop1 and a setter setProp1() is defined. That made me though, the property name is capitized for the setter and getter functions.
On page https://simulide.com/p/scripted/#the-script-language a property named
prop1and a settersetProp1()is defined. That made me though, the property name is capitized for the setter and getter functions.
Sorry, that's an error, I will fix it.
Quote from arcachofo on January 9, 2024, 9:07 amI suppose a string will remain a string anyway, even if it is chosen from a list of values. Hence, the script won't change, just the xml file and the gui.
Yes, lists are always strings.
Wouldn't it better to have lists of any type? Just like arrays can be of any type? That's way more flexible and doesn't require to convert a string into int or double.
Additionally you will have to implement an extra function to populate the values in the list that will return an array of strings:
When the property widget is created it will call the script asking for the list of strings in the dropdown list.
That's even better than specifying the list of values in the xml file.
Wouldn't it better to have lists of any type? Just like arrays can be of any type? That's way more flexible and doesn't require to convert a string into int or double.
I mean the list of options in a property, like the list of colors for LEDs, or wave types in WaveGen, etc.
Those are always strings, so the property needs a list of strings to populate the dropdown menu.
And the property will use those strings for getter and setter.
The only option would be to use the index of the element in the list (an integer), but if you add elements to the list later or reorder it, then it could break the functionality.
Quote from arcachofo on January 9, 2024, 10:01 amWouldn't it better to have lists of any type? Just like arrays can be of any type? That's way more flexible and doesn't require to convert a string into int or double.
I mean the list of options in a property, like the list of colors for LEDs, or wave types in WaveGen, etc.
Those are always strings, so the property needs a list of strings to populate the dropdown menu.
Those are strings, but what if a list of addresses in ram/rom or the number of bits (8, 16, 32) or even different voltage levels shall be selected?
And the property will use those strings for getter and setter.
The only option would be to use the index of the element in the list (an integer), but if you add elements to the list later or reorder it, then it could break the functionality.
The implies to separate the value from the display value, just like options in html.