Test Release 2.7 (cont.)

[Moon Wizard]

2010-07-15 = Test Release 10

Please see the sticky thread on public testing if you want to be involved.

As always, please make a backup of your campaign before opening with a test release.

I will update this thread as I release new iterations of the test version.

Thanks,
JPG

[Moon Wizard]

[Response to kirbol from end of first test release thread]

Windowlist drop
I didn't see that behavior with the acceptdrop tag using the 4E ruleset and the NPC campaign windowlist. I get one item for each valid shortcut I drop, though I didn't test an invalid shortcut. I think you'll need to get me more information (and maybe some code) to figure out what is happening.

SetValue/onValueChanged
The change that you are recommending is actually not something that I think is a good option. In some cases, you want to be able to re-set the value of a field in an onValueChanged call. The correct behavior is to set a flag when using setValue in an onValueChanged field in order to prevent an endless loop condition, which is what you were seeing.

Cheers,
JPG

[Vudo]

moon_wizard, did you see the two errors I posted in the other 2.7 thread? They were BRP rule set related.

[kirbol]

Thanks for the quick response.

Not sure exactly how much code to drop off here, so I'll keep it short for now.

The code I was using the in the windowlist for dropping skills into the list.

<acceptdrop>

<class>refskillfull</class>
<field>name</field>
<field>attribname</field>
<field>action</field>
<field>generalskill</field>
<field>knowledge</field>
<field>strain</field>
<field>description</field>

</acceptdrop>

Honestly, I noticed this behavior after updating to 2.7, then went back and found it also in 2.6.5 (unless some lib didn't downgrade, I was suspecting it was the same).. I got the idea to change everything over to onDrop by looking at the 4E ruleset, since that's how the lists I was looking at seemed to achieve the desired results

I could not replicate this issue in the npc or item lists from the desktop, only within the lists in the character sheet when dropping off the item lists, or from the library modules I created.

setValue/onValueChanged:
The main section of code I modified was in template_linkednumber.lua, which I think is almost identical in the 4E ruleset, though this came from the Earthdawn ruleset from Joshua.

local updating = false;
function onSourceUpdate(source)

if not updating then

updating = true;
local value = calculateSources();
if value ~= getValue() then

--print("linkednumber update " .. getName());
setValue(value);

else

--print("linkednumber doesn't need update " .. getName());

end
updating = false;

end

end

((I sort of mis-spoke, this was in the linked numbers, though with the source values updating, it caused the linkednumber fields to fire their onValueChanged events))

Obviously I was trying a few things in the above, not sure that the "updating" code is even worthwhile right now, as it didn't resolve this issue. But all issues cleared up when I put in the value check. I had a lot of debug code in most of my derived fields, and I only saw this when more than one had the charsheet open.

I am in no way attempting to be argumentative, I just can't think of a time when setting a value to the same value would offer much benefit, except when updating one field grabs info from a second to complete a third, and only field one has the onValueChanged event.... but you'd always be forced to update both fields if field 2 needed a change.... (sorry just kinda thinking through this and trying/hoping to understand )

I'm still pretty new with working with rulesets, etc, only been at it for a couple months.

[Moon Wizard]

kirbol,

Thanks for the notes on the windowlist drop issue. It seems to happen in a particular situation, and hopefully I can recreate here using your info. I'll let you know if I need more.

On the value field, I see what you are saying. If setValue is called, but the value is the same, should onValueChanged be called? However, it's still a tough call, since I can see arguments on both sides. There might be rulesets depending on an onValueChanged event to fire, even if the value has not technically changed. One of things I'm trying to avoid is breaking rulesets.

Cheers,
JPG

[Moon Wizard]

Vudo,

Going to try and get my hands on the latest BRP ruleset, and see what is happening.

Thanks,
JPG

[Moon Wizard]

Vudo,

I was able to take a look at the items you mentioned.

* The script errors are caused by an issue with the ruleset. In 2.6.5, the issue does not generate errors, ironically due to a memory leak in the FG client. When I plugged the memory leak, script errors are now generated. I found a similar situation in the 4E ruleset during development.

* The scrolling in the module data actually was already happening. The difference is that 2.7 calculates the height of the text differently, thus adding some white space at the bottom allowing more scrolling. In 2.6.5, the scrolling was only about 2 lines of text, whereas in 2.7 the scrolling is about 12-15 lines of text. I'll take a look at this.

Thanks,
JPG

[Moon Wizard]

kirbol,

Do you have an onDrop handler in your code for that list control or for the list entry class or controls? It may be causing the double add.

Thanks,
JPG

[Foen]

The script errors are caused by an issue with the ruleset. In 2.6.5, the issue does not generate errors, ironically due to a memory leak in the FG client. When I plugged the memory leak, script errors are now generated. I found a similar situation in the 4E ruleset during development.

Hi JPG

I'm happy to fix the BRP ruleset, but am a bit bemused about the issue. The documentation says that windowcontrols have a destroy() method, which is being called in this code, so I'm not sure what the problem is. How did you resolve it in 4E?

Stuart

[kirbol]

At one time, I saw this on 2 different lists. one did have a seperate ondrop, since I had two classes I wanted to drop, refskillfull and reftalentfull into the skills list.

On the talent list, I only had the reftalentfull acceptdrop (virtually identical to the above) they both had the issue.

The only list that didn't have the issue was my item list, which only used onDrop.

They have all been recoded for only onDrop now, which seems to have resolved the issue.

If you'd like, I could roll back my changes and send you a copy of the ruleset (i use svn so it's fairly trivial, though I'm not sure what other bugs my creep out of the woodwork )