Debugging a pain

Is it just me or is debugging a webcustomcontrol a general pain? When debugging, Javascript errors only get raised when being done with debugging, not when the particular error actually was caused. This makes it pretty hard to figure out which line now causes error.

Yes, it’s a pain. I added a debugmessage event to my control to send messages to debug.

Could you please elaborate a little more?

You can define an event in your own control and in javascript call it, so on the Web App you can show the messages in a listbox.

The issue is that all of the commands that you send within a single request are clustered together and sent back to the browser in a group, the same way the rest of the web framework does it. If we didn’t do it this way the framework would be unbelievably slow.

What do you mean by “a single request”? I call ExecuteJavascriptFunction a couple of times, however they seem to be bundled together too!?

Right. If in a single method you did this:

ExecuteJavascript("var el = document.getElementById('hello');") ExecuteJavascript("alert(el.value);")

These two commands get queued into an array of strings and sent at the same time.

What you might want to try is interspersing some Console.Log calls (in JavaScript) to be sent to the browsers console window. It may help you figure out where the errors are. Another thing to try would be the developer tools that are available with most browsers today. For instance, safari has a rather substantial debugger which may tell you exactly where your error lies.

With Chrome development tools (or webkit), it is convenient to study the javascript code as a whole, and set breakpoints on some lines. But with Xojo, it’s difficult, the code (webControlWrapper…) is only visible in the tree, and not in the “source code”, so we can not set breakpoints easily.

Is there a solution to update the source code page so that it takes into account the code sent by Xojo?

The browser debuggers don’t show javascript code that is in memory, and that’s what you currently get in the WebSDK. The only other way I’ve been able to do this (for development) is to create a global WebFile instance in and then add it to the header in Session.PrepareSession. That will get the actual code onto the page, but you’ve got to make sure your code can handle the fact that the library may not be there immediately.