I am running into an odd problem with Web 2.0. I have a fairly complex page that involves a WebListBox. The app runs fine in the debugger, but when I deploy the app to a Linux server, sometimes the complex page does not render properly: the listbox does not appear at all and certain other controls don’t render or are incompletely rendered, as if there was some kind of javascript error in the client that halted the construction of the page at some point. However, the problem is only intermittent (about 20% of the loads), so it is very hard to determine its source. I am running Xojo 2022R1.1 on a Mac but deploying to a Linux server (sorry don’t know Linux version at this moment).
Hector, that’s a good idea. According to the documentation of the event, a javascript error is supposed to create an error log file by default, but I don’t see any error file. Do I have to actually implement the event for this to happen? Is there another way to make the error visible?
Indeed the documentation states that an error log should be created if possible, to be honest I haven’t read that until you pointed it out. Since it seems this is not happening I would catch the error in the javascriptError event and check if an error is being raised.
OK, I am not seeing any evidence that the JavaScriptError event is firing. I set it up first to post a MessageBox, but did not see anything when the error occurred. Then I tried creating and writing to a text file, but no text file was created when the error occurred. Might anything else cause the problem I am seeing?
Jean-Yves, the data comes from a SQLite database, but I write to the database using a Xojo app and read from it using a Xojo app, so I think that it all should be UTF-8, right? Also, how could this cause a failure sometimes and not other times? The data read into the listbox is the same every time.
OK, more information. The problem with the ListBox not showing is actually a problem with the WebPage.Shown event not firing. This does seem to have something to do with at least one of the date pickers on the page: when this error happens, one of the two date pickers is always blank and neither operates. I took Jean-Yves’ suggestion (thank you!) and saw this in the error console:
I’ll work on a sample project. I can’t reproduce the error on Chrome, so it may be a Safari problem. I am using Safari 14.1.2 on MacOS 10.14.6. The server is running Rocky Linux 8.
It looks like the date picker is having trouble parsing the initial values. IIRC, they need to either be in SQLDate format YYYY-MM-DD or in whatever format is native to the region the user is in.
Wouldn’t creating a DateTime object and assigning it to the date picker be a more generic way of handling this since it wouldn’t matter the region the user is in?
Thanks, Greg, for the suggestion. But the problem is that when this fails, the WebPage.Shown event doesn’t even fire, which is where I initialize the DatePickers. (In the Shown event, I do what Hector suggests, by creating DateTime objects and assigning them to the DatePickers.)
So whatever is going wrong is going wrong as the page is being set up by Xojo. What makes it even more complicated is that most of the time it works and only about 20% of the time it doesn’t. If I move away from the page and then return, it works 100% of the time. Also I noticed that when I displayed the Javascript console to expose the errors, the page would update correctly behind the console. It is something having to do with the very first time the page is displayed. Some kind of timing issue perhaps?
You said above that the shown event isn’t firing at all. If that’s the case, the problem is not in the shown event.
I would start by going to the IDE and confirming that the default value for the date pickers is blank or have sql dates in them and then recheck to make sure that their value is not being set anywhere else. Intermittent problems like this can often be caused by event order bugs that are inherent in web apps because of transmission latency.
I tried what you suggested. The error occurs whether the initial date is blank or whether I set it to a particular SQLDate. I have two date-time pickers, and when the error occurs, the first one in tab index order remains set to the initial date supplied in the inspector. The second one is always set to the present day, no matter what the initial date was. Neither are operable: if you click on them, nothing happens.
However, things are more complicated than I thought. I believe that the Shown event actually is firing on the server, but the user interface on the client is frozen after the error occurs, so the label text that I had set up to indicate that the event was firing never got updated, making it appear that the event didn’t fire. I moved the tab order of the date pickers after the listbox, and now the listbox always gets updated with data that only the Shown event can create. This also explains why displaying the Javascript Console fixed things: it unfroze the client so that the results of the Shown event could be displayed. (How it is that some parts of the user interface get updated and others don’t is still a mystery, though.)
Since the Shown event is firing, my code might in principle have been at fault. However, I have excised the code in the Shown event that updates the date pickers and the error still occurs. Moreover, when the error occurs, both date pickers are inoperable, even after the interface is updated. So the problem appears to be intrinsic to the WebDatePicker class.
The next step, I guess, is to write my own date picker.
Check for ExecuteJavascript calls. If you have an error in some JS that you’re sending and it gets included in the same packet as Framework setup JS, it can cause these issues.
If you really want a more featureful DatePicker(or ListBox, or just about anything else), I have GraffitiDateTimePicker.
A very plausible idea, Anthony. So I killed all ExecuteJavascript calls. Error still occurs.
Thanks also for your suggestion of the GraffitiDateTimePicker. I’ll have a look. But after all this, I had decided that a standard date-time picker was not necessarily the best way to do what I wanted anyway.
