Unable to stop a window showing before ready

Targets Windows
41

Can you say more about the class hierarchy? I believe in Xojo you can have a Window subclass, which could be itself subclassed, but you can’t subclass a Window itself (since a Window functions more like a Module in terms of scope).

If you have 2 levels of subclassing going on, you would need to make sure that each one is calling Super.Constructor()

42

Can you say more about the class hierarchy?

I created a class called MyWindow, derived from window
The constructor calls super.constructor, then sets any label on the window to have text of a color.

Thats basically it.
Changing the super of the problem window back to ‘Window’ made no difference.
I’m currently commenting out code blocks from all the controls in turn to see if I can find a problem control.

43

Other ideas:

  • You say no DoEvents(), but are you using threaded code? Perhaps this code is yielding at a bad time, so that when you do this:
    dim x as new MyWindow
    x.show
    the controls are not actually set up properly when you show the window.

You could try this instead:

dim x as new MyWindow
// do not call x.show here

Iinstead, put a Timer on MyWindow set to mode=Single with a short (250msec) period and show the window then:

MyWindow.Timer1.Action:
    self.show  // in a control, self means "my Window" not "me"

Also, in the past there was a difference between:

  Window.Show 
vs
  Window.visible = true

although I think that was mainly on macOS where it mattered…

1 Like
44

What I’d like to see is a preference that allows users to control the value of that property when they get enough experience to warrant it. The problem with outright turning it off is that it’s really bad for demos and learning, but once a developer gets to a certain point, they tend to learn why Implicit instances are such a bad thing and then have to remember to turn it off for every window they create. As a veteran developer, I’d have that default to an OFF position, but I wouldn’t want to impose that on every other user.

2 Likes
45

And then what the observer sees is just what you are complaining about: the construction process.

46

All I want is ‘show me the finished screen’
Oh well.

47

Do window.visible = False immediately after window.show.

Then drag a timer onto the window. Make it single, period 100-200.

In the Action event of the timer, put:

self.visible = True
1 Like
48

I should mention, it’s already ‘visible = false’ in the IDE.
I only make it visible after all the setup actions are done, but maybe even that is too soon.
Experiments continue.

49

When you do show, it sets visible to true.

50

Unfortunately, the Windows UI framework has never worked properly since the transition to Direct2D (for whatever reason that was). I get the impression that Xojo does some funky stuff to draw the UI which isn’t very optimised and doesn’t work as soon as you have more than a very basic interface.

Some ideas:

  1. Try switching off the transparent flag on all controls including any container controls and their children.

  2. If the window or controls intercept Windows WndProc messages try disabling that code.

  3. Temporarily remove any Windows API declares that disable / prevent redrawing.

  4. Try removing specific types of controls or make them invisible in the IDE to see if you can pinpoint what is causing the slowdown.

If these don’t help then your next step might be to contact Xojo.

51

When you do show, it sets visible to true.

WHHHAAAAATTT???
That helps explain some things.

your next step might be to contact Xojo.

This stuff is hardly new to Xojo. We’re 8 years on from Direct2D.

52

How about you do a PagePanel solution where the panel you show during opening is blank or shows “Loading” and then you switch to the panel with the controls? Or use a canvas over the controls.

53

Well, the utterly only thing that ‘works’ was:

Add a timer (Thanks Michel)
Have the timer set the window size, and place it at -9000 left
Make the window visible (off screen)
Do all the setting up.
Move the window onscreen, using SetBounds so that all 4 properties are set in one call.

Despite all that, the whole dialog flashes briefly when it becomes visible in the main screen, which is infuriating.
But this seems to be the best I’m going to get.

54

Hey now, it was my suggestion to do the timer first :sunglasses:

Also, you say this:

Earlier you said this was a “Document window” - is it actually some sort of Dialog window (modal or otherwise?)

55

Fair enough. Thanks Mike.

Earlier you said this was a “Document window”

Crikey.
Well, you saw straight through the fragile tissue of lies I have used as an alibi. :slight_smile:

It is a document window.
They are all dialogs to me .
Like all vacuums are Hoovers, and all sticky plasters are Elastoplast.

1 Like
56

Can you make your project available to Xojo so that they can try to fix it in a future release?

57

The reason I asked about Dialogs is that the event loop is weird when using Dialog window styles and/or ShowModal. But if it’s a normal Document window, that shouldn’t be relevant.

58

I do it like this, this works for my fine:

WindowX.Show
#if TagretWindows then
WindowX.Refresh
DoEvents
#endif

60

how do I close a window that is open like above?

61

A few ways:

  1. keep track of the window as a global property, perhaps of the App class, e.g.
Public App.MyWindowX as MyWindow
[...] 
App.MyWindowX = new MyWindow
[...] 
App.MyWindowX.Close
  1. Iterate over the Windows
For i As Integer = App.WindowCount - 1 DownTo 0
  Var w As Window = App.Window(i)
  If w isa MyWindow then
   w.Close()
  End If
Next

Windows are weird in Xojo, in that they don’t follow the general rule that “An object will be deconstructed when no more references point to it.” You can have a Window where your code doesn’t have any references to the instance, yet it stays alive nonetheless.

1 Like