<button_iconcyler> why no default value setting?

[Minty23185Fresh]

Is there a particular reason the <button_iconcycler> does not have a "<defaultvalue>" parameter?

It's true the value ("value[0]") associated with default icon is the empty string (""), but when checking the getStringValue(...), comparing it against "", doesn't really give me a warm and fuzzy feeling!

[Moon Wizard]

It's because it was a template built a very long time ago for a very specific purpose. While it has been generalized a bit over time, it has only evolved by what has been needed to get the job done. ;)

JPG

[Minty23185Fresh]

Okay, thank you.

@Community Wiki moderators: If I were to "re-generalize" the <button_iconcycler> control yet again, without breaking current functionality, would the reworked control be worthy of consideration for publishing on the Community Wiki? Publishing it in the forums dooms the work to temporal obscurity.

[Moon Wizard]

I like that, "temporal obscurity". ;)

If you have a new script for a template that doesn't break anything but adds functionality, I'm not sure that the wiki would be the best place to publish, unless your plan is to provide it as an instructive example. Posting on the forums invites dialog to refine the code and provide for people to use in ongoing projects, which seems better.

One of the challenges with defining constructs without a clear example/need is that you end up designing in a vacuum. You spend time on things that will never be used, and are at risk of creating a design that does not meet your long term needs. While normally this isn't an issue, you just change it when you need to; but it becomes an issue when dealing with backward compatibility and a modding community.

If you did build a replacement template with a clear need it is solving, I would be willing to review the code for inclusion as a replacement for the existing template with your permission. However, I never promise to leave things untouched when I include them. I typically rewrite to fit in with the existing implementations when I feel it is needed. Just ask any of the developers I work with closely. :)

Cheers,
JPG

[Minty23185Fresh]

Moon Wizard, again thanks.

I wanted to ask that question, but didn't quite know how.

Okay then. This might be well worth my time. I will put something together, thoroughly test it and publish here, for your perusal.

[LordEntrails]

As for the Wiki aspect, if their is a current page that the information that <button_cycler> doesn't have a default value should be included on, let me know and we can update that page. If you were thinking something else (as your discussion with Moon indicates), let me know what you guys come up with and how/where it would make sense to include in the wiki.

[Moon Wizard]

Also, one thing I thought of that you should consider is that the default value for any string field or string database value is the empty string. So, if you are thinking about implementing a default value, consider that.

Also, try and use the default tag like it is used by numbercontrol, so there is consistency.

Cheers,
JPG

[Minty23185Fresh]

...the default value for any string field or string database value is the empty string...
Okay. Got it.

So, if you are thinking about implementing a default value, consider that.
No that's not where I was going. (See below.)

... use the default tag like it is used by numbercontrol...
Okay. Got it.

For these example parameters:
defaulticon: IconA
icons: IconB, IconC , IconD
values: two, three, four

The problem is..
As one cycles through the icons with the mouse, click, click, click...
IconA, IconB, IconC, IconD
The results of getStringValue( ) are:
"","two","three","four"

If programmatically, you want to see if the user stopped at IconA, it would be nice to have the value of say "one" returned instead of "".

"" is just... well too blank!

[Minty23185Fresh]

... if their is a current page that the information that <button_iconcycler> doesn't have a default value...
There is currently no Wiki page for this esoteric little control. At least not one that I could easily find. It is simply a little undocumented template. Many templates like this are based on other controls which are documented, so addition documentation is not needed. This guy is a little different than most. Maybe its sister control, stringcycler or textcycler (can't remember the name) has documentation.

But if I do a proper job on this Moon Wizard might bring it in to the ruleset anyway, so this discussion might be moot.

I guess the pressure is on.

[Moon Wizard]

There are no documented templates that I am aware of. Only basic controls are documented in the FG API reference. These are the building blocks that all windows and templates are built from.

Regards,
JPG

[Minty23185Fresh]

@Moon Wizard: What is your opinion of making the default parameters optional?

Right now if the <defaulticon> and <defaulttooltip> (or <defaulttooltipres>) are not present, then the lua script throws errors.
But if I handled those issues....

(preliminary thinking is) In onInit() if the default parameters aren't in the XML set a flag. Then whenever the modular scoped variable cycleindex cycles to zero, bump it to one based on the no defaults flag==true.

The index would run from 1 to #icons, instead of 0 to #icons, which is fine.
All defined icons would have string values associated with the icons and numeric indexes.
The database I/O and data would be fine. The field and its value (""), for <defaulticon> is not written to the DB. If the field is missing in db.xml, then during DB read the missing data defaults to <defaulticon> for that data item (value="", cyclerindex=0).
Nothing in existence in any ruleset would have to change since (I assume) all current controls using <button_iconcycler> have <defaulticon>defined.
Going forward it would be okay not to use <defaulticon> and <defaulttooltip> (or <defaulttooltipres>)


[EDIT] Oops. It doesn't throw errors. The control appears to not initialize or be invisible. But that's not true, it's there just doesn't have an icon, so it looks invisible.

[LordEntrails]

There is currently no Wiki page for this esoteric little control. At least not one that I could easily find. It is simply a little undocumented template. Many templates like this are based on other controls which are documented, so addition documentation is not needed. This guy is a little different than most. Maybe its sister control, stringcycler or textcycler (can't remember the name) has documentation.

But if I do a proper job on this Moon Wizard might bring it in to the ruleset anyway, so this discussion might be moot.

I guess the pressure is on.
Just let me know if you end up wanting to document it.

[Minty23185Fresh]

@Moon Wizard: What is your opinion of making the default parameters optional?

This methodology looks great. It provided the functionality I desire. Works with old db.xml. Works with templates/controls that do have <defaulticon> defined. Yada, yada, yada.

One small function, and about six other code changes (e.g. XXX = 0; becomes XXX = myNewFunction(); )

I'll publish here for your perusal (and consumption, if desired), after a bit more testing.

[Minty23185Fresh]

@Moon Wizard: As promised here is the code that I suggested earlier in this thread.

Recap: I complained that the control (template) does not have a "defaultvalue" parameter setting, that corresponds with the defaulticon and defaulttooltip parameters. The control falls back on a "defaultvalue" of "". Which I believe is a shortcoming. The developer should be able to set that value to something more meaningful to the control's context. An example: in the CoreRPG ruleset the button_iconrecycler template is employed by the button_effect_apply template. In that template there is a <defaulticon> of "button_toggle_all", with the <defaulttooltipres> of "effect_tooltip_applyall". The way the template is currently defined, the corresponding <value> for this icon is "". I believe the developer should be able to set the default <value> to a value they wish, for example, "all" in this context. (The other <values> employed in the control are "action", "roll" and "single".) Currently the developer defines n+1 icons (the <icons> + a <defaulticon>), n+1 tooltips (the <tooltips> + a <defaulttooltip>), but only n values (there is no <defaultvalue> parameter).

Remedy: I suggested that the control be modified to include a <defaultvalue> parameter. After looking at the lua code I decided to go a different route. Instead I suggest the <defaulticon> and consequently the <defaulttooltip> (or <defaulttooltipres>) be optional <parameters>. Right now they're mandatory and if the developer does not define them, when the form containing the icon cycler control comes up the control appears to be invisible (because there is no icon defined for that initial state). By allowing the "default" parameters to be optional, the developer can use a set of <icons>, a set of <values> and a set of <tooltips> that correspond one-to-one with what's presented on screen and in code.

Attached is the lua code (as text file ICC_button_iconcycler.txt) that I am submitting for replacement of the existing CoreRPG ruleset code. I have also attached the ruleset lua (as a text file) for convenience. If one diff's the two files, one sees that the new code employs one new function (bottom of the file) and 7 changes (typically setting the cycleindex equal to the value returned by the new function). The new function returns 1 if there is no <defaulticon> defined or 0 if there is. these two values correspond to the indexes into the icons[ ], values[ ], and tooltips[ ] tables. Without a <defaulticon> there is no [0]-th element in each of the tables.

Should this modification not adopted into the ruleset there is a tiny extension attached that defines and employs the modified .lua file. I release all copyright of the code to whomever may wish to employ it. The extension provides proof of concept using the CoreRPG Combat Tracker Faction iconcycler. As is, when dropped into a project the behavior of the Faction control in the Combat Tracker behaves exactly as if the extension were not being used. One can go in and uncomment the second <includefile> recitation in the extension.xml file and then the Faction control will cycle through "foe", "neutral" and "friend" because <defaulticon> is not used in the faction template in ICC_template_common.xml.

Thanks in advance for your consideration.

[Bidmaron]

Thanks, minty. Sounds like with a little testing this is backward compatible and forward excellent

[Minty23185Fresh]

Thanks, minty. Sounds like with a little testing this is backward compatible and forward excellent

Thanks Bidmaron.

It's already pretty well tested. The new lua file is in the latest version of the Field Filters for All Libraries extension. A full week of heavy use during FFAL revisioning should have captured any non-esoteric flaws.

[Moon Wizard]

Here's an alternate version that does what you were looking for, but addresses a couple minor items raised by the changes you wanted.

Also, the faction cycler deliberately has an empty option, so four states is correct for that control. I'm assuming that you used it as an easy example.

I'll plan to include this version in CoreRPG next release, unless you find an issue with it.

Regards,
JPG

[Minty23185Fresh]

Here's an alternate version that does what you were looking for, but addresses a couple minor items raised by the changes you wanted.

Also, the faction cycler deliberately has an empty option, so four states is correct for that control. I'm assuming that you used it as an easy example.

I'll plan to include this version in CoreRPG next release, unless you find an issue with it.

Regards,
JPG

(1) alternative.... we're essentially doing the same thing, slightly different means. Your way is a little more efficient. One test in onInit() instead of retesting over and over.. I like it. Thanks.

(2) four states.. Yes I understand that. It was just, as you say, an easy test. No big lengthy setup. Bang open the CT and there it is.

(3) issues.... Looks great to me. Works just as I desired. Thank you very much. And I am pleased that you consider my work worth including in the ruleset.

(4) four... (MW: replies: "Four... wait.... what four? there isn't a fourth point in my reply" :) )
I apologize for neglecting to ask/include this in my code/questions. It slipped my mind until I was diff'ing your code against mine.
In your new code, the setIndex() ~line 165 and setStringValue() ~line 194, functions... In both of them the nCycleIndex is not set to a new value on "if srcnode" evaluating true. My question is: shouldn't it be set to a value consistent with the function's argument regardless of the presence of srcnode? I.e. setting nCycleIndex should be outside the if statement (and consequently so should be the declaration of nMatch)?

(5) .... which leads me to a fifth point... The concept of a <source> with type "number" seems wrong (to me) in this context. The whole concept behind this control is to cycle icons and use names to index the icons. To use numbers seems archaic and not worth consideration. But that's my two cents. Is it possible some quick copy/paste programming brought this numeric index support over from another control as an artifact? I searched the Core, 3.5E and 5E rulesets to find an instance of using numeric indexes in an iconcycler and didn't see one. Though I could have missed it.

W.R.T. points 4 and 5. Maybe I don't understand what's going on with those two functions. Maybe they're double duty, and I have failed to grasp it. In which case nevermind. :O

[Moon Wizard]

4. When the template is linked to a database node, then whenever the srcnode is changed, the update function is called which synchs the internal variables to match the node's value. If we also tried to set the internal variables in setIndex/setStringValue, then they would be set twice and/or potentially need flags to prevent this scenario.

5. The original iconcycler control supported both number and string data sources, so any future versions also must. There's nothing wrong with either data source type being used for an icon cycler.

Regards,
JPG

[Minty23185Fresh]

4. When the template is linked to a database node, then whenever the srcnode is changed, the update function is called which synchs the internal variables to match the node's value. If we also tried to set the internal variables in setIndex/setStringValue, then they would be set twice and/or potentially need flags to prevent this scenario.


Moon Wizard, sorry to belabor this point. I suspect I didn't express myself well enough.

My concern is that if the nBaseIndex == 1 (no default icon) and for some reason the argument comes in equal to zero, the srcnode value will set to an invalid (in this particular instance) value of "".

I think if the argument, srcval, is pretested against nBaseIndex, the rest of the routine falls into line, almost without modification:



function setIndex(srcval)
if type(srcval) ~= "number" then
return;
end

if srcval < nBaseIndex then srcval = nBaseIndex; end;

if srcnode then
........


I'll agree, in advance that in this scenario, srcval should not come in == 0, but lot's of times things shouldn't happen and then do.
(I tend to be a bit of a defensive coder.)

Thanks for your patience.

[Minty23185Fresh]

@Moon Wizard:

I just noticed this... Seems a bit redundant, yes?


function setStringValue(srcval)
if type(srcval) ~= "string" then
return;
end

if srcnode then
if srcnodetype == "number" then
if srcnode then
local nMatch = nBaseIndex;
for k, v in pairs(values) do
if v == srcval then
nMatch = k;
end
end
srcnode.setValue(nMatch);
end
else
if srcnode then
srcnode.setValue(srcval);

[Moon Wizard]

The setIndex function has never enforced that the value passed is in the range specified by the number of icons on the control. Enforcing the value in this script is not necessary, and technically the number database node doesn’t care. This is true whether it is set by this template code, or by another script. As long as the code displays the default icon when that happens, it’s working as expected.

JPG