Does anybody know of a way to prevent the random indiscriminate internal WE java script errors from appearing. Its like rolling the dice. When this occurs which is often I just hit the refresh button and it goes away. These errors are not in my code but are random java script errors generated by the framework. like “setting the cursor”. I am trying to get my company to go with XOJO but these errors make WE apps seem like a non viable solution.
It’s kind of hard to even begin to diagnose why you’re getting these errors based on what you’ve said.
The best way to get this looked into / at is to file a bug report with the error & a sample project.
First question is how you’re deploying, CGI or stand-alone?
Second, assuming your programming isn’t causing it, these things typically happen when the client gets commands out of order from the server. For example, a new page or container is created, but the client receives a command to do something with it before it receives the command to create it. Posting the JavaScript messages you’re getting would help confirm that. Sometimes, you can solve this by creating something, then waiting for a client side timer before acting. CGI pushing large data seems a little more susceptible to that issue than stand-alone. Large data (e.g. pictures) can be problematic in any case. Better to serve them with Apache if you can. If we ever got WebSockets back, this kind of serialization problem would go away. Insert disclaimer about downside of WebSockets here.
I have a couple of rather large web edition projects that are in development right now. Javascript errors can be hard to track down but they’ve (so far) always been because I’m trying to do something to objects that haven’t been created yet. So be careful on relying upon the order of events for things to occur.
In our case we had to add some delay for dynamic web containers to be shown before trying to start manipulating them. It slows things down but, so far, the apps have been rock solid since the change.
Here is a sample of my code. The error occurs when running from the IDE on the mac and more frequent when deploying as a standalone
Could not execute returned javascript: ‘undefined’ is not an object
Source: Xojo.controls[‘SkdpBNqa’].setCursor(‘pointer’);
Xojo.controls[‘SkdpBNqa’].refresh();
Where are you calling “SetCursor” in your code? Any chance you’re doing it an Open event?
The vast majority of these types of errors come from making changes to controls that aren’t yet fully rendered in the browser. Bob and Brad are likely on the right track. Check for control related changes/methods in Open events that might need to be moved to Shown events- and most likely you’ll start to address your issues…
I am not using SetCursor but rather me.Cursor=. I have since deleted all Cursor manipulation to see if it makes a difference.
Thanks
Are you using dynamically added WebContainers? I’ve had instances where I’ve had to delay populating the contents of a dynamically added container by 100 ms or so to give it a chance to create everything.
I never, ever, use app.doevents. Usually I use a timer with 100 ms delay. Seems to be long enough to let Xojo do whatever it needs doing.
No, I’m delaying loading data into the controls in the Container. The controls aren’t ready yet and that’s why you get the occasional Javascript error. It doesn’t happen to me on every container but some really busy ones just seem to need that slight delay. So in the shown event I start a 100ms timer and load the data into the controls when it fires.
Another approach is throw a one-shot WebTimer (yes client side) on the container/page. When you get its Action event, controls at that level have been created. Make all those controls invisible. Set them up and make them visible in the Action event.
Ok thank you Bob, a Feedback was created? It would be better if it improved in the Framework. This may be a problem specific to containers there.