addFields(aa as Object) as Boolean
Adds the field(s) and corresponding field value(s) defined as key-value pair(s) in the associative array aa to the subject node. The types of the added fields are determined by the values which correspond to the allowable types for an
Translation: if you feed addFields() an AA with field names and values for them, it will create fields with those names, guess the types by the values and set them to those values.
What happens if those fields already exist, one wonders? One imagines it could either
(a) work as setValues() for these (seems desirable) or
(b) throws an error.
Let’s see:
BrightScript Debugger> o = createObject("roSgNode", "Label")
BrightScript Debugger> ? o.addFields({id: "movingLabel", width: 280, height: 60, text: "All The Best Videos!", horizAlign: "center", vertAlign: "center"})
true
Oh cool, so it returned True, everything went allright. Did it do (a), let’s check (some properties omitted for brevity):
BrightScript Debugger> ? o
Turns out neither! RSG took (c) “the Road Not Taken”, duplicated the fields and to add offense to injury, lied that everything is “halal” when it fact the node is in some kind of “haram” jumbled-up state!
BrightScript Debugger> o = createObject("roSgNode", "Label")
BrightScript Debugger> ? o.addFields({id: "movingLabel", width: 280, height: 60, text: "All The Best Videos!", horizAlign: "center", vertAlign: "center"})
true
…
I believe that the RSG manipulations such as addFields only get processed when the render thread is running. So you might not get synchronous results by executing a command in the debugger.
“RokuKC” wrote:
I believe that the RSG manipulations such as addFields only get processed when the render thread is running. So you might not get synchronous results by executing a command in the debugger.
Yes - i noticed and got used to that. But the render thread was running in above - plus result is the same whether i do it in main console, render console or main or render non-console (i.e. non-interactive run).
Yes - i noticed and got used to that. But the render thread was running in above - plus result is the same whether i do it in main console, render console or main or render non-console (i.e. non-interactive run).
So you are doing a ‘continue’ in between the debug commands you showed, or with respect to non-interactive runs, printing out the information from the next event handler and not in a functional sequence?
“EnTerr” wrote:
Yes - i noticed and got used to that. But the render thread was running in above - plus result is the same whether i do it in main console, render console or main or render non-console (i.e. non-interactive run).
So you are doing a ‘continue’ in between the debug commands you showed, or with respect to non-interactive runs, printing out the information from the next event handler and not in a functional sequence?
No, i don’t need to do any of that actually - it’s working w/o delay in the main console (as long as render is not interrupted) - or in the render console - or if i include in main() or XML-component’s init() these lines:
o = createObject("roSgNode", "Label")
? o.addFields({id: "movingLabel", width: 280, height: 60, text: "All The Best Videos!", horizAlign: "center", vertAlign: "center"})
? o
If it was thread rendezvous timeout what you had in mind - i can intentionally induce this by STOP-ing the render thread and typing in main console, then the results are different:
BrightScript Debugger> o = createObject("roSgNode", "Label"): ? o
BRIGHTSCRIPT: ERROR: roSGNode: Failed to create roSGNode with type Label
invalid
or
BrightScript Debugger>? o.addFields({id: "movingLabel", width: 280, height: 60, text: "All The Best Videos!", horizAlign: "center", vertAlign: "center"})
false '<-- !
but this is NOT my case. No, in my first post RSG seems to be working “as intended”, except i wonder if having duplicate fields falls under “good intentions”?
PS. i suspect RoSgNode implementing ifAssociativeArray has something to do with this
…
No, in my first post RSG seems to be working “as intended”, except i wonder if having duplicate fields falls under “good intentions”?
…
Apologies, I didn’t see your original color-coded problem output carefully enough.
(I thought the problem being reported was that the fields you set didn’t show the new values afterwards, and missed that you were instead pointing out fields being shown twice with bad and good values respectively).
