ScriptInitData working differently now, or has a bug?!

Help & Support
1

Hello! o)

I have some scripts and users reporting errors when scripts initialize with the recent versions. I guess something changed (unintentionally?!) after the "convenience" functionality was introduced for handling script config items.

I debugged what happens and the problem seems to be at assigning a fresh Vector to the scriptInitData.config collection. The assignment fails for some reason, I think I can show with this demo code:

function OnInit(data){
	var scriptInitData = scriptInitData || data;
	var myConfigVector = DOpus.Create.Vector();
	data.config["myConfigVector"] = myConfigVector;
	DOpus.Output("myConfigVector.count                          = " + myConfigVector.count + "        "             + " //   expected - count == 0"); 
	DOpus.Output("scriptInitData.config['myConfigVector'].count = " + scriptInitData.config["myConfigVector"].count + " // unexpected - count == undefined"); 
	// ..
}

Output:

MyScript.js:  myConfigVector.count                          = 0         //   expected - count == 0
MyScript.js:  scriptInitData.config['myConfigVector'].count = undefined // unexpected - count == undefined

When I start DO I have 4-5 scripts now, which fail to initialize. They all fail at the same line (basically):

image
image686×128 2.67 KB

And we also have these users reporting the same issue:

Thank you for any ideas on this! o)

ps: Lot's of new threads these days it seems, don't rush anything. o)

2

I have no idea whether this qualifies as a bug, but it seems to be a problem only if, later in the same OnInit() function, you try to access the value assigned to ScriptInitData.config. Considering config_desc and config_groups have existed since at least Opus 12 (and I think this area has improved in recent releases), I don't see any other reason to access it.

But if you still really need to do that, add this line before setting values on config in your example above:

data.config = DOpus.Create().Map(); // or OrderedMap()

3

Same bug for me...

4

Is that a script pre v12.0?

5

Should be fixed in the next beta, yell out if you still see any weirdness.

6

Fantastico! o)

If this works, this avoids the need to screw around in older scripts which are still in the wild. Not that the fix / workaround is complex, but keeping the compatibility is surely the higher, more elegant solution.

Thank you and have a nice weekend (everyone else too!).. o)

7

I verified the fix in v13.18.3 beta, no more init errors, wonderful! Thx! o)

1 Like