App OK with 2012r21, not 2013r33

I just discovered that an app that has been fine for most of the year now says that IE 7.0 or higher is required when launched with IE 11. I figured I would compile the app with the latest version of Xojo and all would be fine. Not. Same source that works fine with RB generates an error message with Xojo. I have not found any documentation that even hints at how to make any sense out of the error message that is returned. Any help would be greatly appreciated. Seaching for “WLocPv83”, the undefined javascript control, in my code returns nothing.

[quote]Could not execute returned javascript: Xojo.controls.WLocPv83 is undefined
Source: document.getElementById(‘AYhk1iPa’).style.userSelect = ‘none’;document.getElementById(‘AYhk1iPa’).style.webkitUserSelect = ‘none’;document.getElementById(‘AYhk1iPa’).style.MozUserSelect = ‘none’;

var tableElt = document.getElementById(‘FM5h8INW_headers’);
var columnElts = tableElt.getElementsByTagName(‘td’);
for (var i = 0; i < columnElts.length; i++) {
columnElts[i].columnIndex = i;
columnElts[i].onclick = eval(function(e) { Xojo.triggerServerEvent(‘WLocPv83’, ‘headingClicked’, [‘FM5h8INW’,]); e.preventDefault(); });

var elt = document.getElementById(‘FM5h8INW_headers’);
var height = elt.offsetHeight;
Xojo.triggerServerEvent(‘WLocPv83’, ‘headingHeight’, [‘FM5h8INW’, height]);

There were perhaps hundreds of lines more, all ending in .refresh(); where the dashed line is. So many I could not start the conversation because it was too long.

well, your problem is right here:

for (var i = 0; i < columnElts.length; i++) { columnElts[i].columnIndex = i; columnElts[i].onclick = eval(function(e) { Xojo.triggerServerEvent('WLocPv83', 'headingClicked' ['FM5h8INW',]); e.preventDefault(); }); }

Contact the developer that made the WebCustomControl which has the headingClicked event and tell them there’s a problem with their control. If it turns out to be a framework bug, the developer should file a bug report.

This looks like Studio Stable Web Essentials. Dean, make sure you are using the latest and make sure that you are not doing any UI manipulation in your WebPage’s Open or controls’ Open events. Move those things to the respective PrepareToShow events.

Greg, the problem here ended up being an invisible control . Dean can elaborate, but I think I’ve run up against this before. IIRC, invisible controls don’t get created client side until they are made visible. Is that what happened Dean?

Revising and extending my remarks… Dean sent me his project. It runs as expected with 2013r2. It gets JavaScript errors as a result of code called downstream of a Shown event. Dean is using one WebPage and several containers that he makes visible/invisible as needed in an effort to page them in and out. I’m not a big fan of how he does it. However, something seems to have changed after 2013r2 that has made some controls not available in the client when the server is handling another control’s Shown() event. It would take me a day to pick this project apart piece by piece to actually isolate some problem in a way it could be fixed. Don’t have it :-).

Greg, I am at a loss for something constructive to recommend here. The two recommendations I gave were: (1) redesign this to just use multiple WebPages until Dean is more comfortable with doing a container-paging design that doesn’t run into this issue, (2) revert to 2013r2 until whatever new behavior that’s going on in the open/show plumbing is “fixed” or changes in a some favorable way. Ideas?

P.S. I’ve also got Feedback #31003 dumped back in my lap from a mutual customer, which seems to me like a similar issue about containers, open, shown, and visible introduced some time after 2013r2. Borderline frustrated here…

P.P.S. This issue snuck in with 2013r3.2. I’d guess it is related to <>. Things go bad on a “refresh” of a control that is not instantiated on the client side yet. What do I win?

Thanks for your help Brad. Like you, I don’t have the time to get to the bottom of this. My project was a pro-bono one that ended up taking a lot more time that I originally intended. One of those things where each new feature suggests another one. Moving from its original 2012r2.1 to the latest Xojo was prompted not by new features or bugs, but because apps made with 2012r2.1 don’t work with Internet Explorer 11. Neither do apps made with 2013r2 so it looks like IE 11 is not an option until a fix is found.