Multiple simulataneous forms in a sinlge application -- visual c

visual c : Multiple simulataneous forms in a sinlge application

Peter Oliphant
11/29/2005 11:50:58 AM

How does one launch multiple forms in an application?

Using Photoshop as an example, this application seems to be composed of many
'disjoint' forms. Yet, they all seem somewhat 'active' in contrast to one of
them always being 'modal' (e.g., if you are moving over a picture the 'Info'
form will update the (x,y) screen location in realtime even if not the
selected form. Also note that this example implies the various forms can
communicate with each other to some degree)...

I'm guessing this has something to do with threads...

Thanks in advance for responses! : )

[==P==]

Peter Oliphant
11/29/2005 12:55:24 PM

[quoted text, click to view]

Maybe. If I knew, I probably wouldn't have started this horribly
un-spell-checked topic....lol

But it sounds like I am, indeed, talking about 'modeless dialogs', if they
are like forms, but you can have more than one at once in a sinlge
application. How do I find out how to create and use them?

[==P==]

[quoted text, click to view]

Peter Oliphant
11/29/2005 1:06:46 PM

BTW, I don't know why I keep spelling 'single' as 'sinlge'... : )

[==P==]

[quoted text, click to view]

Peter Oliphant
11/29/2005 2:43:31 PM

Hi Nish,

Thanks for the info! Question: I'm programming using VS C++.NET 2005 Express
in /clr:pure. Does evoking CModeless violate /clr:pure?

[==P==]

[quoted text, click to view]

Nishant Sivakumar
11/29/2005 3:09:09 PM

Are you referring to modeless dialogs?

--
Regards,
Nish [VC++ MVP]

[quoted text, click to view]

Nishant Sivakumar
11/29/2005 4:24:41 PM

I've got an article on creating modeless dialogs here :

http://www.voidnish.com/articles/ShowArticle.aspx?code=gettingmodeless

That should get you started. But to get a Photoshop like UI, there would be
considerably more amount of work required I guess :-)

--
Regards,
Nish [VC++ MVP]

[quoted text, click to view]

Nishant Sivakumar
11/29/2005 4:25:48 PM

[quoted text, click to view]

Yeah, I know the feeling. I always mis-type "put" as "out" and it's pretty
annoying since the spell checker won't catch it!

--
Regards,
Nish [VC++ MVP]

[quoted text, click to view]

Carl Daniel [VC++ MVP]
11/29/2005 5:27:56 PM

[quoted text, click to view]

Windows Forms natively supports modeless forms. Just call the .Show()
method on a form (after instantiating it with gcnew, of course) and up it'll
come. You can have as many forms open as you need.

-cd

Lloyd Dupont
11/30/2005 12:00:00 AM

what's the problem here?
what about

Form f = new Form();
f.Show();

????

[quoted text, click to view]

Peter Oliphant
11/30/2005 7:39:06 AM

[quoted text, click to view]

The problem was I didn't know about the Show( ) method, which is why I
asked.... hehe

Thanks Nish, Carl, and Lloyd! : )

[==P==]

[quoted text, click to view]

Peter Oliphant
11/30/2005 8:29:03 AM

I've now played a bit with Show( ), and I'm able to put up more than one
form. But, if I display them all using Show( ) then my main( ) falls through
and exits. If I show the last one via ShowDialog( ) it becomes a modal form
and the other forms, while visible and active, are not accessible (i.e.,
they don't get focus when clicked on, none of the controls can be used, they
are always behind the modal form, they can't be moved or reduced or
maximized, etc.).

So, how do I get a bunch of forms up that when clicked on will gain the
focus, and still have the program 'wait synchronously' and does not drop
through the main( ) method and exit, ala the way ShowDialog( ) works (or
whatever is the right way to do this)...

[==P==]

[quoted text, click to view]

Tamas Demjen
11/30/2005 9:59:53 AM

[quoted text, click to view]

What? Do you have a console application? You have to create a WinForm
application. The main function should look like this:

int main(array<System::String ^> ^args)
{
Application::EnableVisualStyles();
Application::Run(gcnew Form1());
return 0;
}

The application exits when your main form closes. Any other form can be
closed and your application will still run. You can't prevent the fact
that if the main form closes the application closes. It's always like
that in every application in every operating system.

Nishant Sivakumar
11/30/2005 10:17:32 AM

Hello Peter

[quoted text, click to view]

For one thing, the expression edition does not have MFC - so you cannot use
MFC with that.
Second, even if you did get the full VC++ 2005 edition, MFC and ATL are not
supported in pure mode (at least as of 2005).

So, perhaps you should go for modeless forms using Windows Forms (unless you
really want to use MFC, in which case you cannot use the pure compilation
mode).

--
Regards,
Nish [VC++ MVP]

[quoted text, click to view]

Nishant Sivakumar
11/30/2005 10:19:44 AM

[quoted text, click to view]

:-(

expression -> express

Damned typo!

--
Regards,
Nish [VC++ MVP]

[quoted text, click to view]

Peter Oliphant
11/30/2005 10:29:17 AM

Yes, I'm (so far) creating the application as a console program. I do
console first for debug purposes (I have a personal Debug class that writes
debug info to the console in realtime without having to breakpoint), then
switch to non-console application. This only required changing the way
'main' was called. One way it showed the console, the other way it was not
visible (probably not even created). This was very helpful and convenient...

At least that's how I use to do it. Do I have to decide between console and
winform now from the start? I have created a customized form class which
inherits from System::Form, so I don't use a 'vanilla' Form. Hence the 'Form
design', 'Properties', and 'Toolbox' features are worthless to me, which I
believe are the main advantages to a winform application over a console
application. And I lose the console for debugging in a winform
application...

Yes, I could change my Debug class to write the debug info to an additional
modeless form (and may end up doing this), but not until I'm sure I can't
have modeless forms in a console application. Is that true?

[==P==]

[quoted text, click to view]

Tamas Demjen
11/30/2005 10:59:50 AM

[quoted text, click to view]

Either way the rule is the same. One of your forms is a dedicated main
window, and when that form closes your application exits (or the
execution passes to the next line, in case of ShowDialog). So you can
have as many modeless windows floating around as you want, but when the
main window closes, it closes everything else with it.

If you want a system where there is no visible main form, but each
window is modeless, and the application closes when the last window
closes, then I believe you still need to have a main form. Have it
positioned off-screen so it's not visible, and write your own logic that
counts the number of modal windows, and when that count reaches 0, you
programmatically close the main form. The main form must be executed via
Application::Run (typically) or ShowDialog (if you want to force the
console application design). You must have a main window that's alive
while your application is running, because that window is processing all
the messages coming from the keyboard and the mouse, and typically the
application's life span equals to the main form's life span.

Lloyd Dupont
12/1/2005 12:00:00 AM

1. you decide if it's a console application or winform application at
compilation time.
2. to show multiple form it's like that:

Form^ f1 = gcnew MySuperForm();
Form^ f2 = gcnew MySuperForm();

f1->Show();
f2->Show();

Application::Run(); // if you don't call that => no event loop and your app
stop immediately

3. now you call Application::Run() without parameter, there is no main form,
so it will run forever.
You should register event listener on your form's dispose and register your
forms when created.
And call Application::Exit() when all form have been closed.

4. apparently you are quite new to winform and have problem understanding
its concepts.
could I suggest you forget about ManagedC++ for a little while, its many
unproductivity features gets in the way of the learning process.
play with a C# winform project until you get to understand what you should
understand, then you could get back to managed C++ which works just the same
way, except it takes twice as much characters and it keeps bothering you
with headers and include order to write the same code.

[quoted text, click to view]

Peter Oliphant
12/1/2005 7:50:44 AM

It as the Application::Run( ) that I was unaware of. Now I can do what I
want, thanks! : )

Actually, I'm quite familiar with how Winform applications work, I
programmed in VB for 5 years! I'm trying to learn Managed C++, which is why
I'm asking these questions. I know what I want to do, but the doco and books
on 2005 are non-existent (understandable since its only been out for a
little over 3 weeks), so one must ask how to do things.

MSDN2 acts in many ways like a dictionary: you have to already know the
answer to know where to look. For example, tell me how I was suppose to know
that one uses Show( ) and Application::Run and Application::Exit without
knowing Show( ) exists or to look at the Application class? What should I
have given the search engine in MSDN2 in order to find out about modeless
forms (nope, 'modeless forms' doesn't work, I tried).

I WAS trying this, which AMOST, but DOESN'T, work; but seems like it should:

Form form1;
Form form2;

form1.Show() ;
form2.ShowDialog() ;

But this makes it so clicking on form1 does not give it the focus. There is
NOTHING in the description on MSDN2 of 'ShowDialog()" that warns of this
behavior, or even suggests that Application class and the Show() method
should also be looked at. And there is no sample code (gee, what a
shock...lol). In fact, here is 100% of the description it gives for
ShowDialog:

"Shows the form as a modal dialog box."

Thanks, MSDN2! While you're at it, mind pointing me to how to do a MODELESS
dialog box?

And the only 'See Also"s are Form class, Form members,
System::Windows::Forms namespace, and DialogResult. Note there is no menton
of Application class, it's Run( ) and Exit( ) methods, or the Form's
Show( ) method. And methods are grouped ALPHABETICALLY, not by function
category, so one must look through EVERYTHING to find ANYTHING. This is why
one has to ask such (seemingly simplistic) questions in this forum, cause we
need people who actually work at MS to answer them since there is no
reliable way to look up 'how-to" questions, and only people at MS know the
answer since they created the language...

Anyway, the system works, cause I now know how to do modeless forms!!! : )

[==P==]

[quoted text, click to view]

Lloyd Dupont
12/2/2005 12:00:00 AM

[quoted text, click to view]
Haha... here is the root of your problem.
You don't (know how to) use the documentation!

The SDK, & all version of VS.NET comes with a local .NET documentation.
They have an Index tab as well as a table of content (plus a search which
is more and more useless with each new version, I guess it's an old habit...
:-/).

in the index you could type a keyword / class name / method name => it will
bring youy there.
from here you could look the other section related to the topic or other
method of the object.
from the content index you could look at the various section and see how
they explain such and such and maybe gives you idea you didn't have in the
1st place.

Now, as for Application.Run();
If you knew about Aplication.Run(aForm), it's not that hard to look at the
other method of Application.
Or is it?

[quoted text, click to view]

Peter Oliphant
12/2/2005 7:01:12 AM

[quoted text, click to view]

I TRY to use it all the time! And in fact, I do get a lot of info from it.
But I do have to already know where to look to find anything. The
Application class is a perfect example. Speaking of which...

[quoted text, click to view]

Correct, once one knows about the Application class looking up other stuff
about it on MSDN2 is easier. But not necessarily trivial. For example, you
gave me an excellent answer that included this:

"And call Application::Exit() when all form have been closed."

Now look up the Run method in MSDN2's description of Application::Run. This
is ALL it says:

" Begins running a standard application message loop on the current thread.
"

Geee, no mention at all of how one needs Application::Exit( ) when exiting
if you use Application::Run( ). And it would have taken, what, 15 seconds
and 6 more words, ala, "Use Exit() when closing the application." To their
benefit, they DID list Exit( ) as a 'See Also'. But wouldn't taking the time
to write a whopping 6 extra words be a whole lot better? Even now? Or is it
too late to add to or correct the doco?

I think the problem is the MSDN2 doco is written by people who don't NEED it
to find out stuff - they ask the people around them since they work at
Microsoft! And as has always been the paradox of writing doco, the more
familiar you are with the material the less you feel you have to explain to
those less familiar than you.

The person who wrote about Application::Run doco knew it required Exit() to
end an application. It's obvious to him since he is so familiar with
Application::Run( ), so he doesn't see the need to explain further. But if
you've just discovered Application::Run( ), why do you think its so OBVIOUS
an Application::Exit( ) exists? And since stuff is arranged by ALPHABET
instead of by FUNCTION, the 'Run' line is not next to the 'Exit' line, so I
guess one must read EVERYTHING to know about ANYTHING.

Basically what happens is one uses Application::Run(), the program doesn't
exit, and one it sent scrambling back to the doco assuming they used
Application::Run( ) INCORRECTLY, oblivious to the fact that the
Application::Exit( ) method exists since it doesn't say anything about it in
the doco in the decription of Application::Run( ). Or people post here (like
me), and get answers form those who have already figured out the answer or
know it becuase they have inside sources at MS (like they work there)...

Put simply, the people who wrote the MSDN2 doco don't realize things that
are obvious to them are not obvious to anybody who is relying on the MSDN2
doco to explian it to them FOR THE FIRST TIME.

By the way, here's another interesting littel tidbit. Try looking up
Application class. If you get to the MSDN2 side, everything is good:

http://msdn2.microsoft.com/en-us/library/6y6135ed(en-us,VS.80).aspx

But, heaven forbid your search engine winds you up on the MSDN side, where
it says this about the Application class:

http://msdn.microsoft.com/archive/default.asp?url=/archive/en-us/directx9_m_dec_2004/directx/ref/ns/microsoft.directx.directplay.lobby/c/application/application.asp

" Warning: This class is deprecated. Deprecated components of Microsoft®
DirectX® 9.0 for Managed Code are considered obsolete. While these
components are still supported in this release of DirectX 9.0 for Managed
Code, they may be removed in the future. When writing new applications, you
should avoid using these deprecated components. When modifying existing
applications, you are strongly encouraged to remove any dependency on these
components."

Of course this is also in the DirectX section, but if you have been told to
look up the Applicatin class you might find this VERY MSDN page that quite
clearly tells you NOT to use the Application class. Why would you then
assume ANOTHER Appl;ication class exists in the MSDN2 section? In fact, how
do we know there isn't a third one? LOL

So you see, the doco is VERY confusing at times. As I understand it, it is
composed of 10's of thousands of pages of information. And you yourself said
this about the search engine:

"plus a search which is more and more useless with each new version"

So, let's recap. We as consumers as suppose to be able to figure out how to
use the NEW features of a language by trying to guess how MS organizes
functionality into classes and then try to guess what MS would NAME such
classes, unless we want to depend on a 'useless search' engine or read 10's
of thousands of pages from cover to cover. And when looking up things like
the 'Font' of a TreeView class you have to be clever enough to realize MS
decided to call this 'DefaultFont', since its the 'default font' for all the
TreeNodes it holds, since stuff is organized by class name, not
functionality. Stuff like that...

NOW do you understand why this forum is NECESSARY to get ANYTHING done? : )

[==P==]

[quoted text, click to view]

Lloyd Dupont
12/3/2005 12:00:00 AM

Allright, allright!

BTW, did you use the *local* documentation?
Coming with both the SDK & VS.NET!

It's much faster and one could idly peer through the table of content to get
ideas, and even tutorial on that feature or that stuff...

Got something to say? Click here to post a reply to this thread.

Don't see what you're looking for? Try a search.

View other messages about visual c

View Other Months
June 2003
July 2003
August 2003
September 2003
October 2003
November 2003
December 2003
January 2004
February 2004
March 2004
April 2004
May 2004
June 2004
July 2004
August 2004
September 2004
October 2004
November 2004
December 2004
January 2005
February 2005
March 2005
April 2005
May 2005
June 2005
July 2005
August 2005
September 2005
October 2005
November 2005
December 2005
January 2006
February 2006
March 2006
April 2006
May 2006
June 2006
July 2006
August 2006
September 2006
October 2006
November 2006
December 2006
January 2007
February 2007
March 2007
April 2007
May 2007
June 2007
July 2007
August 2007
September 2007
October 2007
November 2007

home · blog · groups

Questions? Comments? Contact the dn