Unable to stop a window showing before ready

Targets Windows
21

I certainly do, except someone decided to move the setting to the “Advanced” tab for DesktopWindow.

3 Likes
22

I don’t. All my windows are implicit and I’ve never lost a moment’s sleep worrying about it. Oh, and they work just fine.

1 Like
23

Do you have intensive threads running?

24

There is one thread used by the window.
I don’t think it fires during open, but I will check.
(if it is the cause, that kinda defeats the point of using a thread… :> )

Edit:
I removed the code from the thread.
No change

25

Shouldn’t the constructor call Super.Constructor for the Open event to fire?
(can’t check right now)

26

It does call it.
Im wondering it I need to have the parent class duplicate the Open() event

27

This reminds me of a project I worked on, where like you said the window sat for a while in a half-drawn state. I traced it to some “intense” code in one of the individual control’s Open event. Of course, controls instantiate and fire their events before the window does–or they’re supposed to. It was benign on Mac and Linux, but behaved badly on Windows.

I took this code and moved it to a timer that fired once after the window opened. The window opened cleanly after that. Might you have something like this in the project?

28

Could be.

Of course, controls instantiate and fire their events before the window does

That seems backwards to me.
Surely
parent
child
is more logical.

29

Surely if it happened that way, you’d be guaranteeing that oddities and artefacts would occur. You want all teh controls to have finished fiddling about, then you want the window to finish and display.

1 Like
30

Surely if it happened that way, you’d be guaranteeing that oddities and artefacts would occur.

Consider a wall:

Build the wall.
Apply a coat of paint.
Hang a few pictures.
Put up a coat hook.
Hang a coat.

as opposed to

Make a coat. Oops… need a coat hook. Oops… need a wall.

certainly I dont want my window to display until it has done all the work.
And therein lies the problem.
I have to watch the builders.

31

Not disagreeing, but we live in an imperfect world. And like I said, this particular wonkiness in my experience has been Windows-specific.

32

From Quick Tip: Opening, Shown, Closing and Closed – Xojo Programming Blog

Opening in Desktop and Mobile Apps

  • First, the App Opening event will be fired first.
  • Next, the Opening event on every control of the default Window assigned to the App project. In this case, it will follow the same order in which the controls were added to the Window in the >Layout Editor. It is possible to change that order using the Order buttons in the Command Bar in the Layout Editor.
  • Last, the Opening event will be fired on the default Window containing the controls.
2 Likes
33

or not, in the case of the Open() event that predates this document…

34

As you’re running an older version it reminded my of this https://tracker.xojo.com/xojoinc/xojo/-/issues/55618 and I can’t remember when the paint recursion check was introduced.

35

Does any of your version numbers exceed 5 digits or go over 65535 or do you have an & in any app id field?

36

Edit: sorry to bother.

37

I know what the docs say.
They have nothing to say about why a Window’s Open() event does not happen: it should be impossible.

And we are probably getting waaay off topic, which usually happens.

38

Yes. Tweaked it and 2021 runs it. (No better, but it runs.)

39

Are you using App.DoEvents() anywhere?

40

Not in this window, which is the only one instantiated at the time.