onReplicantAdded OR-container failing

Environment: TS 7.3.2 on Linux

Scenario:

I have a DCT that contains an replicant OR conainer that looks essentially like this:

<container name="slide" location="slide" min="0" max="unbounded" default="0" combination="or">
  <label>Slide</label>
  <container name="image" location="image">
    <label>Image</label>
    ...
  </container>
  <container name="audio" location="audio">
    <label>Audio</label>
    ...
  </container>
  ...
</container>

I create a DCR from it, and in [semi-]collapsed mode I see N "Slide" container label-headings.

I decided, I'd like to augment those labels so that they include the type of slide inside, so I created the following code:

function init() {
  if (IWDCRInfo.getDCRName() != "") {
      resetSlideLabels();
  }
  IWEventRegistry.addItemHandler("/root/slide", "onReplicantAdded", resetLabel);
}

function resetSlideLabels() {
  var children  = IWDatacapture.getItem("/root/slide").getChildren();
  for (var i in children) {
    resetLabel(children[i]);
  }
}

function resetLabel(item) {
console.log("reset label on "+item.getName());
  var kids = item.getChildren();
  console.log(" -> "+item.getLabel()+" : "+kids[0].getLabel());  item.setLabel(item.getLabel()+" : "+kids[0].getLabel());
  console.log("done");  return true;
}

So - I bring up an existing DCR with 5 slides in it - the code works just great, and I can see in the console log:

resetLabel on /root/slide[1]
-> Slide : Image
done
...
resetLabel on /root/slide[5]
-> Slide : Audio
done

Great!

Problem

Now I go to add a new slide in 3rd position, the replicant never gets added and I see the following in the console log:

resetLabel on /root/slide[3]
-> Slide : Image
TypeError: titleElement is nulltitleElement.innerHTML = HTMLEscape(item.label);
[dc_actions.js (line 106)]

I was obviously able to derefernce both the item and the child-item to get their respective labels in order to display the second debugging line (-> Slide : Image) so it has to be failing on the item.setLabel() line, a line that worked just fine 5 times in a row on pre-existing elements.

I'm a bit stymied by this: It's a post-process event handler, I appear to have access to both the parent and child IWItems and their respective labels, but it dies when I try to actually modify the label on the newly created [child] instance. It's not like I can put conditionals around anything in my code to test for null-ness and such, because it would all pass through and still fail where it is now.

Any ideas?

Find more posts tagged with

Comments

Rick Poulin

The onReplicantAdded is asynchronous and actually triggers before the replicant instance is fully built, so I've seen some very weird things happen because of that. I'd say delay your execution with a setTimeout() and see if that fixes it.

Adam Stoller

Hmm - I cannot seem to get setTimeout to work - either I'm doing something wrong, or it isn't delaying like it's supposed to in Firefox (32.0.3) or IE-11

/* Time delay required for asynchronous behavior of onReplicantAdded */
function resetLabelWait(item) {
console.log("Waiting... " + Date());/*#=#*/
setTimeout(resetLabel(item), 4000);
console.log("Done waiting " + Date());/*#=#*/
    return true;
}

/* aesthetic function to modify the labels for "Slide" to include the slide type */
function resetLabel(item) {
console.log("resetLabel on "+item.getName()+" "+Date());/*#=#*/
    var kids = item.getChildren();
console.log("-> "+item.getLabel()+" => "+ kids[0].getLabel());/*#=#*/    item.setLabel(item.getLabel() + " : " + kids[0].getLabel());
console.log("done?");/*#=#*/
    return true;
}

The console log shows:

Waiting... Mon Oct 06 2014 07:58:44 GMT-0700 (Pacific Standard Time)
resetLabel on /root/slide[8] Mon Oct 06 2014 07:58:44 GMT-0700 (Pacific Standard Time)
-> Slide => Image
TypeError: titleElement is null
	titleElement.innerHTML = HTMLEscape(item.label);
        dc_action.js (line 106)

Notice the timestamps - if I read the documentation on SetTimeout correctly, the second timestamp should be 4-seconds later than the first, but they appear to be exactly the same.

Am I overlooking some simple syntactic error on my part that is preventing the delay for happening?

Rick Poulin

ghoti wrote:
Am I overlooking some simple syntactic error on my part that is preventing the delay for happening?

Yup.. you're passing the result of your function to setTimeout right now.. you want this:

setTimeout("resetLabel(item)", 4000);

..except now 'item' probably won't resolve in the global context, so you might have to pass the path instead:

setTimeout("resetLabel('"+item.getPath()+"')", 4000);

Adam Stoller

rpoulin wrote:
ghoti wrote:
Am I overlooking some simple syntactic error on my part that is preventing the delay for happening?
Yup.. you're passing the result of your function to setTimeout right now.. you want this:
setTimeout("resetLabel(item)", 4000);
..except now 'item' probably won't resolve in the global context, so you might have to pass the path instead:
setTimeout("resetLabel('"+item.getPath()+"')", 4000);

Actually, I think just 'item' outside of quotes should do ... trying now ...

function resetLabelWait(item) {
  setTimeout("resetLabel('"+item+"')", 2000);
  return true;
}

Hmm that didn't work.

I ended up having to modify both the resetLabelWait and resetLabel functions as follows:

function resetLabelWait(item) {
  setTimeout("resetLabel('"+item.getName()+"')", 2000);
  return true;
}

function resetLabel(item) {
  if ((typeof item) === "string") {
    item = IWDatacapture.getItem(item);
  }
  //...existing code...
}

Also, I now realize that my complaint about setTimeout not working based on the timestamps of the two console log messages was completely false - setTimeout is asynchronous queuing, so the the fact that the two messages had the exact same time stamp was perfectly correct, if I could have seen the timestamp on the error message - that probably would have been 2-4 seconds later.

Anyway - the above seems to work - and although I grant @rpoulin a significant portion of the credit, I'll mark this post as the solution since it has the actually working code in it (you lost points for getting the method name wrong ;-))

Rick Poulin

ghoti wrote:
(you lost points for getting the method name wrong ;-))

Haha fair enough. I did think it wasn't quite right but I was too lazy to look it up Smiley Tongue