How to get Window(0) not to be the HTMLViewer

I have been baffled by not being able to get my StartUp window, which calls the Htmlviewer under certain circumstances, to be window(0). The circumstance is this is the first use and the user needs to know how to setup things, because we generally don’t read the help manual. The problem is the HTMLViewer becomes window(0) of course, and in this case I need it to be Window(1). I added to StartUp.Open self.show to no avail.
I had also traced the code just short of finding the solution to why it showed up as Window(0).
The solution or cause is the HTMLViewer runs DocumentComplete after all of the StartUp code is done.
I thought if I traced the HTMLViewer through Open that I would be good, but it runs after.
Why?
Is there anyway I can get it to finish?
Is there any I can do a workaround?

You know that the window indexes are the order front to back, right? If you want the HTMLViewer to be behind another window you need to show the top most window last.

Yes. I understand the indexes. I’m trying to do this call of htmlviewer from the StartUp window. I don’t have to. It’s just easier (until now).
But I don’t understand why the documentcomplete has to run after the Calling window finishes

Open your startup window.
On that, have a timer set to fire once
Have the timer open the HTMLViewer

Because DocumentComplete is asynchronous. It fires when the page in the HTMLViewer finishes loading.

Let’s say you did this

HTMLWindow.Show // which shows the content
Window1.Show

What you’re effectively getting is:

HTMLWindow.Show
HTMLViewer.Load(whatever your url is)
// HTMLViewer1 Requests the page async
Window1.Show
// HTMLViewer receives the page
HTMLViewer1.DocumentComplete

No

I don’t understand how anything in coding is asynchronous.
On the other hand, I fail at inductive logic, so it’s no surprise I don’t understand.

The reason is that the request for the page is sent off by the operating system on a background thread which runs on a different cpu core than your app. When it gets a response, whenever that happens, we forward that event to your app.

I suggest that you take the time to figure this out though. More and more of modern OSs are asynchronous and you’re going to run into this somewhere.

All computers and their operating systems can do this, have been able to certainly since before I started writing software in 1965. Go learn about interrupts in computers.

I moved the call for the help file to a different location and that part works. Now

Aah. Background threads. That makes sense,
I am lousy at understanding object oriented messaging. Is there any part of XOJO that will work with those instances. I am basically aware of the Worker concept and many other concepts, but I don’t have a use for them. What can I do to work with these modern features?

Thanks for interrupts. I’d forgotten about those. Never had a chance to really learn them.

Interrupts are like events but at a much lower level, and allow the sequential flow of code to be interfered with. Any interrupt either causes all the running task’s context to be saved or causes a switch to another set of registers so the running task’s registers are not lost.

The interrupt handler for the clock may just alter a counter, but if that counter eaches some value, then the entire context of the running task will be saved probably on the stack for that task, and another task’s saved context switched into the register set so the previously dormant task can resume execution.

If you have an app which is user-facing, you don’t want it to become unresponsive to the user just because the user just clicked the button in your app asking for π to one million places. So you do that calculation in a thread so the user can continue the chess game they are playing against your app. There, a real practical application for threads! :smile:

Well, think about this… if you are making desktop apps in Xojo, you’re already working asynchronously if you have code in any button.Action events. The program presents some information to the user and sometime in the future the user may (or may not) press that button and execute that code. It’s up to the user and not your program as to when that code runs.

1 Like

I always work asynchronously. Thank you

Forum for Xojo Programming Language and IDE. Copyright © 2021 Xojo, Inc.