Web app works with 2013r2, crashes with 2013r3

Targets Web
1

I have a web project developed with 2013r2 that crashes if I run it with 2013r3. The crash occurs when the main window should show up, after the user have passed the login page.

The (long) error message starts with:

Could not execute returned javascript: ‘undefined’ is not an object (evaluating ‘Xojo.controls[‘Mff8cGiw’].object’)
Source: document.title = “Main”;

document.getElementById(‘Mff8cGiw’).style.overflow = ‘auto’;
Xojo.controls[‘Mff8cGiw’].object().style.top = ‘67px’;
Xojo.controls[‘Mff8cGiw’].refresh();
Xojo.controls[‘Mff8cGiw’].setVisible(true);
Xojo.controls[‘Mff8cGiw’].refresh();
document.getElementById(‘Mff8cGiw’).style.overflow = ‘auto’;

document.getElementById(‘TQdjXsGb’).style.overflow = ‘auto’;
Xojo.controls[‘TQdjXsGb’].setVisible(false);
Xojo.controls[‘TQdjXsGb’].refresh();
document.getElementById(‘TQdjXsGb’).style.overflow = ‘auto’;

document.getElementById(‘SJlr79Jr’).style.overflow = ‘auto’;
…
…

and ends with:

…
…
Xojo.refreshControl(‘CnpPM2Xo’);

Xojo.refreshControl(‘IsIfUrUI’);

Xojo.refreshControl(‘Re9szSsX’);

Xojo.refreshControl(‘HvZZD73o’);
document.cookie = ‘UserName=xeris;’;
Xojo.controls[‘FTAxdvhp’].setValue("");

It’s a fairly complicated project, I need to go on with its development, so I’ll stick with 2013r2 for now.

After some non-obvious debugging attempts, I finally discovered that control Mff8cGiw mentioned in the first line of the error message is a container control.

I stepped through the debugging session both in 2012r2 and 2013r3. I get with both to the last statement before the page should be shown. One more step with r2 and the page shows up. One more step with r3 and the black error dialog appears.

Are there known issues with 2012r3 on this regard?

Thanks

Franco

2

You’re doing something to a control before it’s in the browser. So… are you doing anything in Open events of pages, controls, containers? If so, what? Moving that stuff to Shown will usually resolve the issue. The problem is that you may not want it done every time the page, control, container is shown. In Studio Stable Web Essentials Free, I have a solution for that: the PrepareToShow event. It only fires the first time an object is shown and is the perfect place to do those things you’d naturally want to place in Open.

Get it here.

If it’s not the Open event of some page, control, container, etc., it might be a WebSDK control that’s not playing right. Are you using any of those?

3

Thanks Brad

Will go through the tons of controls I have on that page (there’s a toolbar, and a container control associated with each toolbar item) to check their open events.

Since all is working in r2, has something changed in the management of the Open event?

No fancy controls other than standard Xojo controls, and subclasses.

4

There has been a lot of ongoing work to fix these kinds of problems, issues with event order (especially with containers), etc. I’ve seen a lot of code that “works” by working around old problems, and then breaks when the issues are addressed in the framework. At this point, eliminate code in Open events first and then go from there.

5

Going through all controls right now, thanks for the suggestion! Will let you know…

6

Definitely the problem is related with code in the Open event of pages and controls. A quick and dirty attempt at moving that code away made the error disappear, with the minor side effect of breaking the app functionality… :-/

Will better plan the move and do it again. Will look at your classes too, thanks for sharing them. But what is the open event for, then?

Then the question is: should I consider unsafe to run the web app compiled with 2013r2?

7

There are some things you can safely do in the Open event, but I don’t think they’re listed anywhere. With either the free or paid Web Essentials, if you make your WebPage subclasses subclasses of WEWebPage (and containers, dialogs, controls, etc.), you’ll have a PrepareToShow event which is a great place to put the stuff you had in Open. It will only run once per instance. See the link above.

Every release of Xojo is gonna have some framework bugs. It sounds like your code didn’t expose those issues in r2. I think the best course of action is to fix things so they work with r3, and hopefully work more as intended, and just keep moving forward.

8

So, after throwing away the changes made yesterday in a hurry, I started again the removal of code from the Open events. Using the “Shown” event is out of question, as it is called too many times during the app execution.

I decided to begin with the Open event of the troubled window. Moving the code out of the Open event, and placing it into a new “Init” method, called just before the call to the Show method

pageMain.Init pageMain.Show

solved the issue. The app is now working fine with 2013r3, like it was with 2013r2.

So no need to rearrange the code in the Open event of controls and containers of the window, at least in my case. Who knows if r4 will force other changes, but for now I can go on developing the app using the latest Xojo

Thanks again, Brad!

9

BTW, did you know that you can edit the title of the conversation afterwards, too? Because it could use some correction :slight_smile:

10

I finally found how to do that… :wink: