<stateframe> in basicnumber derived templates

[EDIT] --> I am SO sorry, writting all this out gave my mind the ability to organize my thoughts better and after completing it, I rexamined the differences.
This issue was the darn "<readonly/> flag!

So, now I get it, I really should have thought about what the attrib "hidereadonly=" meant on <hover> --- I am sorry for wasting folks time. Leaving the rest but unless you want to know how I missed the obvious - you can stop here. RATHER, you could still answer the question I will copy from the original text, if ya know:
"One question, first: is the "copy=xxx" attribute for "prime time use" or still experimental? I'd like to be able to use it when it makes sense but have not yet considered where that might be since I read it was not yet "official" for non-SW until later."








<< BELOW WAS SOLVED... read only if bored, since no help is needed ;P >>


I have been very much enjoying reading through the updated (for me, been while) templates and documentation. I am trying, where possible, to follow new and upcoming standards.

One question, first: is the "copy=xxx" attribute for "prime time use" or still experimental? I'd like to be able to use it when it makes sense but have not yet considered where that might be since I read it was not yet "official" for non-SW until later.

The main reason I am posting this is some time ago, I did the first page of the main charactersheet and I asked where I could find out how to do the highlighting etc I see in 5E and others. I was told that it was already part of basicnumber. I was confused since I thought I was using that already but put it off since I had a lot more higher priority things.

Now that I am understanding/remembering more, I wanted to revisit this. My template for the equivalent to 5E character abilities uses:

Code:

---

        <template name="number_charabilityscore">
                <basicnumber>
                        <anchored to="abilities_title" position="insidetopleft"/>
                        <rollable />
                        <readonly />
                        <min>1</min>
                        <max>25</max>
                        <default>9</default>
                        <frame name="fielddark" />
                        <script file="campaign/scripts/number_abilityscore.lua" />
                </basicnumber>
        </template>

---

Here is one such use of the above:

Code:

---

                        <number_charabilityscore name="strength" source="abilities.strength.score">
                                <anchored offset="-10,38" height="36" width="35" />
                                <tooltip textres="char_strength_tooltip"></tooltip>
                                <target>strength</target>
                        </number_charabilityscore>

---

(I have to revisit anchoring for much of this since I started it using RSW.)

Now, in my case, hovering the cursor over any of the attribs does nothing but display the tooltip. I removed the frame definition (since I had made my own with that name) and it made the boxes different shapped but still no highlighting as I expect is defined in:

Code:

---

--> CoreRPG snippet:

        <template name="basicnumber">
                <simplenumber>
                        <frame mergerule="replace" name="fielddark" offset="7,5,7,5" />
                        <stateframe>
                                <keyedit name="fieldfocus" offset="7,5,7,5" />
                                <hover name="fieldfocus" offset="7,5,7,5" hidereadonly="true" />
                                <drophilight name="fieldfocus" offset="7,5,7,5" hidereadonly="true" />
                        </stateframe>
                </simplenumber>
        </template>

---

Any idea what I might have done to "turn that off" or didn't do to "initialize" that sort of default behavior?


Thanks!

Unfortunately, I cannot resolve it as I'd wish.

In CoreRPG I saw this:

Code:

---

        <template name="basicnumber">
                <simplenumber>
                        <frame mergerule="replace" name="fielddark" offset="7,5,7,5" />
                        <stateframe>
                                <keyedit name="fieldfocus" offset="7,5,7,5" />
                                <hover name="fieldfocus" offset="7,5,7,5" hidereadonly="true" />
                                <drophilight name="fieldfocus" offset="7,5,7,5" hidereadonly="true" />
                        </stateframe>
                </simplenumber>
        </template>

---

So, I thought, simply changing:
<hover name="fieldfocus" offset="7,5,7,5" hidereadonly="true" />

to
<hover name="fieldfocus" offset="7,5,7,5" hidereadonly="false" />

would work.

Then I read the wiki:
<hidereadonly /> If present, the frame will not be drawn regardless of state when the control is set to read only.

So it isn't truly a "boolean" field.
And since the original tags do not have: mergerule="replace" in place, I cannot make the <hidereadonly /> go away. I tested adding that mergerule to the <stateframe> tag in CoreRPG and it "worked" - but that isn't a true solution. I can make my own "basicnumber" for this control, but I'd rather use the existing one to catch any future changes if I could.

Any tips? I suspect others may know how to address this likely common scenario where the base template tag doesn't have a mergerule.
I have an idea with onInit(), but it's likely a longshot. Plus hoping for easier solutions even if it works.

OK... my work here is done for tonight at least.

The workaround was not as ugly as I expected.
I added to my lua "<script file=..." an onInit() which resets the default value(s) (I am so glad you guys expose programatic ways and not just XML!)

The setFrame below's last parameter is "hidereadonly", setting it to false fixes the issue. I'll try it in a second, but I suspect I can leave off the last two args and it behaves properly. But given that I am trying to replace something specifcally, it is probably better coding practice to be explicit in that.

Code:

---

function onInit()
        if super and super.onInit then
                super.onInit();
        end
   
    setStateFrame("hover", "fieldfocus", 7, 5, 7, 5, false, false)
end

---

EDIT: Verified, leaving out the last 2 args defaults them to false both which is what I want.

I wonder if the original in CoreRPG had been:

Code:

---

        <template name="basicnumber">
                <simplenumber>
                        <frame name="fielddark" offset="7,5,7,5" />
                        <stateframe>
                                <keyedit name="fieldfocus" offset="7,5,7,5" />
                                <hover>
                                    <name>fieldfocus</name>
                                    <offset>7,5,7,5</offset>
                                    <hidereadonly>true</hidereadonly>
                                </hover>
                                <drophilight name="fieldfocus" offset="7,5,7,5" hidereadonly="true" />
                        </stateframe>
                </simplenumber>
        </template>

---

If I could have written:

Code:

---

function onInit()
        if super and super.onInit then
                super.onInit();
        end

    -- Done to override basicnumber's setting where hover is not triggered for readonly controls.
    setStateFrame("hover", stateframe[1].hover[1].name[1], 7, 5, 7, 5, false, false)  --> Probably completely wrong, cos I use trial and error first time I try something and can't try this atm
end

---

Of course, simply adding a mergerule to CoreRPG tag is simpler if we were making a CoreRPG change to begin with - was just a mental exercise.
... OK, before hitting POST, I tested it lol, I changed CoreRPG to use nodes vs attribs. I then referenced Hover's frame and offsets (that needed parsing since I the following wasn't the shortcut I hoped for: Debug.console(stateframe[1].hover[1].offset[1][n]) where n=1-4

Night all!

You can use merge="replace" in your stateframe definition to override the base version completely. (It's the reverse of mergerule.)

Regards,
JPG

Omg!
I just thought they renamed merge to mergerule, awesome thanks! It makes sense for it to have both angles. Great. Will update it later. But, kinda glad I ran into it cos it made me experiment with alternate ways.

Rubber duck debugging - Wikipedia
:)

Quote:

---

Originally Posted by LordEntrails

Rubber duck debugging - Wikipedia
:)

---

You ain’t wrong…