Strange behavior

[Ken Tucker [MVP]]

Hi,

Is the statusbar showing its panels?

Statusbar1.showpanels=true

http://msdn.microsoft.com/library/d...windowsformsstatusbarclassshowpanelstopic.asp


Ken
----------------------

I'm doing a status bar for the user to wait while coding


LabelStatus.Visible = true

' Do some coding

LabelStatus.Visible = false

For some reason the statusBar visibilty is always false.

 

[romy]

I'm doing a status bar for the user to wait while coding


LabelStatus.Visible = true

' Do some coding

LabelStatus.Visible = false

For some reason the statusBar visibilty is always false.

 

[Armin Zingler]

I'm doing a status bar for the user to wait while coding


LabelStatus.Visible = true

' Do some coding

LabelStatus.Visible = false

For some reason the statusBar visibilty is always false.

How do you check whether it is visible? By code or by looking at your
screen? If by code, where do you check it?

Armin

 

[Armin Zingler]

Ofcoarse The LabelStatus become visible immedialty after the
command.

But For some Reason its visibilty is shown in the form only after
the coding in between(which takes some time)

LabelStatus.Visible = true

Do some coding (takes couple of seconds)

--- only now the statusbar is shown
LabelStatus.Visible = false

I still don't understand when exactly it is visible. What means "only
now..."? "Now" refers to the next line?
In the 1st paragraph you write it does become visible. I understood, it
doesn't. How long is it visible?

Armin

 

[romy]

Ofcoarse The LabelStatus become visible immedialty after the command.

But For some Reason its visibilty is shown in the form only after the coding
in between(which takes some time)

LabelStatus.Visible = true

Do some coding (takes couple of seconds)

--- only now the statusbar is shown
LabelStatus.Visible = false

 

[romy]

The main idea is to show the user a "Please Wait" (visible=true) statusbar
while some coding is being done, and to erase the "Please Wait" afterwards
(visible=false)

In fact , Only AFTER the coding (takes couple of seconds), The "please wait"
statusbar is shown (I noticed it after commenting LabelStatus.Visible =
false).

For some reason .visible =true/false is not shown immediatly on the form.

 

[Armin Zingler]

The main idea is to show the user a "Please Wait" (visible=true)
statusbar while some coding is being done, and to erase the "Please
Wait" afterwards (visible=false)

In fact , Only AFTER the coding (takes couple of seconds), The
"please wait" statusbar is shown (I noticed it after commenting
LabelStatus.Visible = false).

The comment in parantheses makes it clear.

For some reason .visible =true/false is not shown immediatly on the
form.

Call me.refresh after making the statusbar visible. Maybe also
labelstatus.refresh (I didn't test it). As the code is running, there is no
time to show the statusbar, and as soon as there was time, the statusbar is
invisible again.

Background information (you might already know this, of course): Windows is
message driven. Messages are sent to each window to notify the window about
a mouse button being pressed or about any other messages/events you know.
Even if your app does "nothing" it actually is running in a loop waiting for
a message to arrive and to forward it to the window concerned. The message
is put into a queue by the OS because the application might still be
processing any previous message and the OS can not wait for it to finish.
2nd: Updating the screen works by the OS requesting a window to paint
itself. That's done by sending a message to the window, too. If you make the
statusbar (in)visible, the OS sends a "paint yourself" message (WM_PAINT) to
the window. As your programm is still busy, the message will not be
processed before the job is done and it returns to the message loop where it
came from. At that point, the message will be processed, but now it's too
late because the statusbar isn't visible anymore.

You can force refreshing a control(/form) by calling it's refresh method.
This directly calls the code to paint itself. This one is called synchronous
painting in opposite to asynchronous painting described above.

Be aware of the following (IMO very very bad design) facts in WinXP (3rd
paragraph):
http://msdn.microsoft.com/library/e...ssagequeues/aboutmessagesandmessagequeues.asp

Means: If you want to update the display, not even calling Refresh works if
the OS hided your window! The designers probably thought that they can hide
a window because it doesn't accept any *input* but they totally ignored that
there is still *output*. We are forced to start a seperate thread just to
have a main thread accepting input although we do not want to accept input.
A work-around is to call the PeekMessage API function within the longer
running task.

Sorry, was much more than I intended to write...


Armin

 

[romy]

thanks for your lengthily response, armin.

The comment in parantheses makes it clear.


Call me.refresh after making the statusbar visible. Maybe also
labelstatus.refresh (I didn't test it). As the code is running, there is
no
time to show the statusbar, and as soon as there was time, the statusbar
is
invisible again.

Background information (you might already know this, of course): Windows
is
message driven. Messages are sent to each window to notify the window
about
a mouse button being pressed or about any other messages/events you know.
Even if your app does "nothing" it actually is running in a loop waiting
for
a message to arrive and to forward it to the window concerned. The message
is put into a queue by the OS because the application might still be
processing any previous message and the OS can not wait for it to finish.
2nd: Updating the screen works by the OS requesting a window to paint
itself. That's done by sending a message to the window, too. If you make
the
statusbar (in)visible, the OS sends a "paint yourself" message (WM_PAINT)
to
the window. As your programm is still busy, the message will not be
processed before the job is done and it returns to the message loop where
it
came from. At that point, the message will be processed, but now it's too
late because the statusbar isn't visible anymore.

You can force refreshing a control(/form) by calling it's refresh method.
This directly calls the code to paint itself. This one is called
synchronous
painting in opposite to asynchronous painting described above.

Be aware of the following (IMO very very bad design) facts in WinXP (3rd
paragraph):
http://msdn.microsoft.com/library/e...ssagequeues/aboutmessagesandmessagequeues.asp

Means: If you want to update the display, not even calling Refresh works
if
the OS hided your window! The designers probably thought that they can
hide
a window because it doesn't accept any *input* but they totally ignored
that there is still *output*. We are forced to start a seperate thread
just to have a main thread accepting input although we do not want to
accept input. A work-around is to call the PeekMessage API function within
the longer running task.

Sorry, was much more than I intended to write...


Armin