By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
443,417 Members | 904 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 443,417 IT Pros & Developers. It's quick & easy.

The Concept of Top Most, how useful is it really?

P: n/a
I have a scenario that is to be totally honest, doing my Gnads in. The only
control I have over window Z ordering in VB.NET is by using "TopMost=True",
or "TopMost=False". There is no "z-order" concept that I can play with
apart from this single binary choice.

Now, think about where it might be useful to have fine grained control over
Z order: I have a main form, which pops up modeless "property" windows. I
want these property windows to remain in front of the main form because
otherwise it might be easy for a user to "lose one" behind the main form. I
also run a thread that needs to pop up a modal progress bar every now and
then. I want this to be top most of course when it's running, but I don't
want it to be topmost if I need to display an error form or message of some
kind while the thread is running, I want the error form to be topmost.
When the user presses F1 for help, I obviously want the help to be topmost.
I do not want any of my windows to remain topmost when the user launches
another process.

Now this might seem like a complex scenario, but in fact I think it's
probably a fairly common one. I'm not comfortable with piddling about with
the topmost property continually to micro-manage form visibility, when I
should simply be able to give a number on a form property that gives some
kind of Z order priority to each of my forms, relative to my executable.

Any ideas on how to manage these situations? TopMost does exactly what it
says on the tin, unfortunately!


Nov 21 '05 #1
Share this Question
Share on Google+
4 Replies


P: n/a

"Robin Tucker" <un********@duetospam.com> wrote in message
news:dg*******************@news.demon.co.uk...
|I have a scenario that is to be totally honest, doing my Gnads in. The
only
| control I have over window Z ordering in VB.NET is by using
"TopMost=True",
| or "TopMost=False". There is no "z-order" concept that I can play with
| apart from this single binary choice.

| Now this might seem like a complex scenario, but in fact I think it's
| probably a fairly common one. I'm not comfortable with piddling about
with
| the topmost property continually to micro-manage form visibility, when I
| should simply be able to give a number on a form property that gives some
| kind of Z order priority to each of my forms, relative to my executable.

i understand your frustration. it can be done but i'd recommend the
following first:

you could think about making your main form an mdi form wherein the
other/child forms will be displayed and *never* go behind it. second, your
progress bar form should be set to topmost and your error handler form
should also. the error form will *always* be the most recent form displayed
and therefore the topmost visible. i don't see *any* micro-managing at all.
that type of management *would* be needed if you *did* start to set the
z-order of windows...you'd need a scheme/algorhythm to discover the
appropriate order to set for *every* window. how you open the forms too, is
very important...i.e. i'd open the error form as dialog (a.k.a.
form.showdialog() ) while the progress bar form should *only* be shown
(form.show() ).

if you don't want to go the mdi-route, you could use a combination of
topmost and/or show/showdialog with all your forms to get the results you
require.

i do agree that a bit more suffistication with window layering would be
nice, but this only comes to my mind as problematic under *far* more complex
ui contraints that the bulk of developers will never know...and, i've only
run across 2 occasions in 15 years of programming...both resolved more
easily through other means than tinkering with z-order.

hth,

me
Nov 21 '05 #2

P: n/a
Robin Tucker wrote:
the topmost property continually to micro-manage form visibility, when I
should simply be able to give a number on a form property that gives some
kind of Z order priority to each of my forms, relative to my executable.


Why don't you do exactly that!! Create an Extender Provider that will
add a ZOrder property to your forms. Then in the form's constructor,
call the SetWindowPos api to set the ZOrder. It shouldn't be too
difficult.

Nov 21 '05 #3

P: n/a
Hmmmm thanks for the tip. I think I will ;)

"Chris Dunaway" <du******@gmail.com> wrote in message
news:11**********************@z14g2000cwz.googlegr oups.com...
Robin Tucker wrote:
the topmost property continually to micro-manage form visibility, when I
should simply be able to give a number on a form property that gives some
kind of Z order priority to each of my forms, relative to my executable.


Why don't you do exactly that!! Create an Extender Provider that will
add a ZOrder property to your forms. Then in the form's constructor,
call the SetWindowPos api to set the ZOrder. It shouldn't be too
difficult.

Nov 21 '05 #4

P: n/a
If you do, you might submit it to CodeProject as an article or MSDN or
something. at least post the solution here!

Nov 21 '05 #5

This discussion thread is closed

Replies have been disabled for this discussion.