I have an old application which used HTML Viewer for webpages. It also communicated back (webpage interaction) to XoJo parent using the bowser status and the StatusChange event.
Of course altering the browser status is no longer available via JavaScript. I do notice that JavaScript alert() creates a message box outside the HTMLViewer object. Is it possible to subclass the MsgBox control to have HTMLViewer pass me messages from webpage JavaScript.
The application already uses a subclassed HTMLViewer exposing the events to my new class, so I was hoping if I subclassed MsgBox within that same class; maybe the JavaScript alert(); function (called within the HTMLViewer object) would use my modified MsgBox, preventing the box; but pulling the message content.
Traditionally the way to do this was to change the window’s title or status in JavaScript and then use the TitleChanged or StatusChanged event to get the data.
Thanks Greg, I have investigated that option; but I’d have to parse the message to avoid the title character limit. The alert box does seem to show all the content I was trying to process.
There’s no way to intercept the alert(); method being executed in the HTMLViewer from within your Xojo code. You can either update the project to a more modern version of Xojo that supports JavaScript communication or write JavaScript to do packet updates via the Title/Status.
I used this method for years. You write a JavaScript function that takes a string input, breaks it up in to smaller chunks (I don’t recall the limits for length of title or status now). Send a Title/Status update that says “I’m about to send data”, then iterate over your data chunks, and finally send a “I’m done sending data” update. On the Xojo side, have a buffer array. Clear the array when you receive the starting packet, add anything else that comes in that isn’t your ending packet to the buffer, then execute when you receive the ending packet.
Personally, I would investigate updating the version of Xojo used to at least one that supports the JavaScript communication.
Note that this may fail on macOS or Linux depending upon the version of the libraries used on the OS for the HTMLViewer.
Thanks Anthony,
I don’t think they are ready for a full project migration, but the ‘chunk’ idea is exactly what I proposed. I did some testing with [>BEG<] c, c, c, c, c, c, c [>END<] just as you explained well. (BTW, it appears title is 260 bytes/char max; I will limit to 240 chunk + beg/end tag - b/c documentation for Chromium says 250 max). This is part of a much larger, windows only platform, project. (I suspect it hasn’t worked for a while or they just moved it to a newer PC.) The Web document.status seems like that was neutered quite a while ago. (You also may be correct that the status had character limits too, we just never hit them before. It was a long time ago; now that they want it working again they want to capture some 3K-5K in some fields.)