Well, it’s a bit more of an issue than just “Can I sleep the main thread”. I’ve got a user who wants to print some stuff. The stuff is in an HTMLViewer, and rather than relying on the TitleChanged or StatusChanged events, which either don’t work on all platforms or are subject to data length restrictions, I wrote a websocket server which is incorporated into the app, but, perforce, it’s in a thread. I use it to communicate between the Xojo side and the HTMLViewer side. Other threads can send commands into the HTMLViewer which then responds with data. Evidently such threads are suspended while waiting for data to return.
Now, can I sleep or suspend the main thread? If so I can have the File->Print menu handler send a command via the websocket server to the HTMLViewer, wait for the data to return (sleep/suspend) then save or print it.
If I can’t sleep/suspend the main thread, I could send a different command to the websocket server, to have it do the printing, which involves putting up a Print dialog box. But wouldn’t this cause a ThreadAccessingUI Exception?
Are we talking about a web or a desktop app? I’m asking because of the websocket server.
For a desktop app the html needs to be loaded into the html viewer in the main thread. I have a notification system that sends a notification when the html is loaded in DocumentComplete:
dim tempItem as FolderItem = getTempFolderitem
call HTMLViewer1.PrintToPDFFileMBS(tempItem, 50, 50, 50, 50)
NotificationManager.Post "PDFCreated", TempItem.NativePath
Then the pdf file gets page number and a header. Afterwards either the final pdf is created when the user does use the pdf format in my app or the print dialog is shown. When the user is using pdf format a notification is sent to load the next html into the html viewer.
Almost sounds like whats hes got going on is an html view in the app.
Then the app itself listens for connections back from the HTML/JS that is shown in the HTMLView. That way he can pass more data than the title change or status changed events would permit since its now a “Web app” running inside his own desktop app - the app IS the web server and the client all in one.
Yes, I’m already loading html into another HTMLViewer for printing. But in this instance the stuff to be printed is initially in another HTMLViewer (in this desktop app) and needs to be gotten hold of and merged with some other data before it can be printed. The getting hold of is what involves the websocket aspect, and , therefore, a thread. All of this work needs to be done by the Print menuitem handler, so that handler (which is on the main thread) has to send a command to the websocket thread to get it to obtain the data from the HTMLViewer, and then wait for the data to come back (how: sleep the main thread? Suspend it?)
Broadly, yes. And I use an HTMLViewer because that’s the only way I have to get HTML (that I receive from external sources) rendered.
And using Quill in an HTMLViewer is the only way I know of to allow a user to compose some rich text (with images, links) that I can then get hold of as HTML.
I wouldn’t recommend such an approach. Even if possible, pausing the main thread would mean pausing GUI updates too, which could make the GUI feel laggy. Thread has an UserInterfaceUpdate Event which you could use to trigger different app behaviour asynchronously. Or, with an older IDE, create a similar mechanism with a timer inside the thread that triggers a similar event.
Wouldn’t it be possible to send the command to the Websocket thread from the print menu item handler (and then do nothing in it anymore), and then have the UserInterfaceUpdate handler trigger the print method when the thread returned the data?