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

Multiple simulataneous forms in a sinlge application

P: n/a
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==]
Nov 29 '05 #1
Share this Question
Share on Google+
20 Replies


P: n/a
Are you referring to modeless dialogs?

--
Regards,
Nish [VC++ MVP]
"Peter Oliphant" <po*******@RoundTripInc.com> wrote in message
news:eA**************@TK2MSFTNGP10.phx.gbl...
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==]

Nov 29 '05 #2

P: n/a
> Are you referring to modeless dialogs?

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==]

"Nishant Sivakumar" <ni**@nospam.asianetindia.com> wrote in message
news:%2****************@TK2MSFTNGP15.phx.gbl...
Are you referring to modeless dialogs?

--
Regards,
Nish [VC++ MVP]
"Peter Oliphant" <po*******@RoundTripInc.com> wrote in message
news:eA**************@TK2MSFTNGP10.phx.gbl...
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==]


Nov 29 '05 #3

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

[==P==]

"Peter Oliphant" <po*******@RoundTripInc.com> wrote in message
news:OY*************@TK2MSFTNGP12.phx.gbl...
Are you referring to modeless dialogs?


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==]

"Nishant Sivakumar" <ni**@nospam.asianetindia.com> wrote in message
news:%2****************@TK2MSFTNGP15.phx.gbl...
Are you referring to modeless dialogs?

--
Regards,
Nish [VC++ MVP]
"Peter Oliphant" <po*******@RoundTripInc.com> wrote in message
news:eA**************@TK2MSFTNGP10.phx.gbl...
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==]



Nov 29 '05 #4

P: n/a
I've got an article on creating modeless dialogs here :

http://www.voidnish.com/articles/Sho...ettingmodeless

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]
"Peter Oliphant" <po*******@RoundTripInc.com> wrote in message
news:OY*************@TK2MSFTNGP12.phx.gbl...
Are you referring to modeless dialogs?


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==]

"Nishant Sivakumar" <ni**@nospam.asianetindia.com> wrote in message
news:%2****************@TK2MSFTNGP15.phx.gbl...
Are you referring to modeless dialogs?

--
Regards,
Nish [VC++ MVP]
"Peter Oliphant" <po*******@RoundTripInc.com> wrote in message
news:eA**************@TK2MSFTNGP10.phx.gbl...
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==]



Nov 29 '05 #5

P: n/a
>> BTW, I don't know why I keep spelling 'single' as 'sinlge'... : )

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]
"Peter Oliphant" <po*******@RoundTripInc.com> wrote in message
news:%2****************@tk2msftngp13.phx.gbl...
BTW, I don't know why I keep spelling 'single' as 'sinlge'... : )

[==P==]

"Peter Oliphant" <po*******@RoundTripInc.com> wrote in message
news:OY*************@TK2MSFTNGP12.phx.gbl...
Are you referring to modeless dialogs?


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==]

"Nishant Sivakumar" <ni**@nospam.asianetindia.com> wrote in message
news:%2****************@TK2MSFTNGP15.phx.gbl...
Are you referring to modeless dialogs?

--
Regards,
Nish [VC++ MVP]
"Peter Oliphant" <po*******@RoundTripInc.com> wrote in message
news:eA**************@TK2MSFTNGP10.phx.gbl...
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==]



Nov 29 '05 #6

P: n/a
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==]

"Nishant Sivakumar" <ni**@nospam.asianetindia.com> wrote in message
news:Or**************@TK2MSFTNGP11.phx.gbl...
I've got an article on creating modeless dialogs here :

http://www.voidnish.com/articles/Sho...ettingmodeless

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]
"Peter Oliphant" <po*******@RoundTripInc.com> wrote in message
news:OY*************@TK2MSFTNGP12.phx.gbl...
Are you referring to modeless dialogs?


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==]

"Nishant Sivakumar" <ni**@nospam.asianetindia.com> wrote in message
news:%2****************@TK2MSFTNGP15.phx.gbl...
Are you referring to modeless dialogs?

--
Regards,
Nish [VC++ MVP]
"Peter Oliphant" <po*******@RoundTripInc.com> wrote in message
news:eA**************@TK2MSFTNGP10.phx.gbl...
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==]



Nov 29 '05 #7

P: n/a
"Peter Oliphant" <po*******@RoundTripInc.com> wrote in message
news:eA**************@TK2MSFTNGP10.phx.gbl...
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...


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
Nov 30 '05 #8

P: n/a
what's the problem here?
what about

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

????
"Peter Oliphant" <po*******@RoundTripInc.com> wrote in message
news:eA**************@TK2MSFTNGP10.phx.gbl...
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==]

Nov 30 '05 #9

P: n/a
Hello Peter
Thanks for the info! Question: I'm programming using VS C++.NET 2005
Express in /clr:pure. Does evoking CModeless violate /clr:pure?
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]
"Peter Oliphant" <po*******@RoundTripInc.com> wrote in message
news:%2***************@TK2MSFTNGP12.phx.gbl... 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==]

"Nishant Sivakumar" <ni**@nospam.asianetindia.com> wrote in message
news:Or**************@TK2MSFTNGP11.phx.gbl...
I've got an article on creating modeless dialogs here :

http://www.voidnish.com/articles/Sho...ettingmodeless

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]
"Peter Oliphant" <po*******@RoundTripInc.com> wrote in message
news:OY*************@TK2MSFTNGP12.phx.gbl...
Are you referring to modeless dialogs?

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==]

"Nishant Sivakumar" <ni**@nospam.asianetindia.com> wrote in message
news:%2****************@TK2MSFTNGP15.phx.gbl...
Are you referring to modeless dialogs?

--
Regards,
Nish [VC++ MVP]
"Peter Oliphant" <po*******@RoundTripInc.com> wrote in message
news:eA**************@TK2MSFTNGP10.phx.gbl...
> 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==]
>
>



Nov 30 '05 #10

P: n/a
> For one thing, the expression edition does not have MFC - so you cannot
use
:-(

expression -> express

Damned typo!

--
Regards,
Nish [VC++ MVP]
"Nishant Sivakumar" <ni**@nospam.asianetindia.com> wrote in message
news:%2****************@TK2MSFTNGP12.phx.gbl... Hello Peter
Thanks for the info! Question: I'm programming using VS C++.NET 2005
Express in /clr:pure. Does evoking CModeless violate /clr:pure?


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]
"Peter Oliphant" <po*******@RoundTripInc.com> wrote in message
news:%2***************@TK2MSFTNGP12.phx.gbl...
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==]

"Nishant Sivakumar" <ni**@nospam.asianetindia.com> wrote in message
news:Or**************@TK2MSFTNGP11.phx.gbl...
I've got an article on creating modeless dialogs here :

http://www.voidnish.com/articles/Sho...ettingmodeless

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]
"Peter Oliphant" <po*******@RoundTripInc.com> wrote in message
news:OY*************@TK2MSFTNGP12.phx.gbl...
> Are you referring to modeless dialogs?

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==]

"Nishant Sivakumar" <ni**@nospam.asianetindia.com> wrote in message
news:%2****************@TK2MSFTNGP15.phx.gbl...
> Are you referring to modeless dialogs?
>
> --
> Regards,
> Nish [VC++ MVP]
>
>
> "Peter Oliphant" <po*******@RoundTripInc.com> wrote in message
> news:eA**************@TK2MSFTNGP10.phx.gbl...
>> 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==]
>>
>>
>
>



Nov 30 '05 #11

P: n/a
> Form f = new Form();
f.Show();
The problem was I didn't know about the Show( ) method, which is why I
asked.... hehe

Thanks Nish, Carl, and Lloyd! : )

[==P==]

"Lloyd Dupont" <net.galador@ld> wrote in message
news:%2***************@TK2MSFTNGP15.phx.gbl... what's the problem here?
what about

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

????
"Peter Oliphant" <po*******@RoundTripInc.com> wrote in message
news:eA**************@TK2MSFTNGP10.phx.gbl...
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==]


Nov 30 '05 #12

P: n/a
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==]
"Peter Oliphant" <po*******@RoundTripInc.com> wrote in message
news:uH**************@TK2MSFTNGP09.phx.gbl...
Form f = new Form();
f.Show();


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

Thanks Nish, Carl, and Lloyd! : )

[==P==]

"Lloyd Dupont" <net.galador@ld> wrote in message
news:%2***************@TK2MSFTNGP15.phx.gbl...
what's the problem here?
what about

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

????
"Peter Oliphant" <po*******@RoundTripInc.com> wrote in message
news:eA**************@TK2MSFTNGP10.phx.gbl...
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==]



Nov 30 '05 #13

P: n/a
Peter Oliphant wrote:
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.


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.

Tom
Nov 30 '05 #14

P: n/a
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==]

"Tamas Demjen" <td*****@yahoo.com> wrote in message
news:Oi**************@TK2MSFTNGP11.phx.gbl...
Peter Oliphant wrote:
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.


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.

Tom

Nov 30 '05 #15

P: n/a
Peter Oliphant wrote:
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?


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.

Tom
Nov 30 '05 #16

P: n/a
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.
"Peter Oliphant" <po*******@RoundTripInc.com> wrote in message
news:Om**************@TK2MSFTNGP14.phx.gbl...
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==]

"Tamas Demjen" <td*****@yahoo.com> wrote in message
news:Oi**************@TK2MSFTNGP11.phx.gbl...
Peter Oliphant wrote:
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.


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.

Tom


Dec 1 '05 #17

P: n/a
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==]

"Lloyd Dupont" <net.galador@ld> wrote in message
news:%2***************@TK2MSFTNGP10.phx.gbl...
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.
"Peter Oliphant" <po*******@RoundTripInc.com> wrote in message
news:Om**************@TK2MSFTNGP14.phx.gbl...
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==]

"Tamas Demjen" <td*****@yahoo.com> wrote in message
news:Oi**************@TK2MSFTNGP11.phx.gbl...
Peter Oliphant wrote:
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.

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.

Tom



Dec 1 '05 #18

P: n/a
> 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).
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?


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==]

"Lloyd Dupont" <net.galador@ld> wrote in message
news:%2***************@TK2MSFTNGP10.phx.gbl...
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.
"Peter Oliphant" <po*******@RoundTripInc.com> wrote in message
news:Om**************@TK2MSFTNGP14.phx.gbl...
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==]

"Tamas Demjen" <td*****@yahoo.com> wrote in message
news:Oi**************@TK2MSFTNGP11.phx.gbl...
Peter Oliphant wrote:
> 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.

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.

Tom



Dec 2 '05 #19

P: n/a
> Haha... here is the root of your problem.
You don't (know how to) use the documentation!
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...
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?


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/lib...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/de...pplication.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==]
"Lloyd Dupont" <net.galador@ld> wrote in message
news:uT****************@TK2MSFTNGP14.phx.gbl...
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).

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?


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==]

"Lloyd Dupont" <net.galador@ld> wrote in message
news:%2***************@TK2MSFTNGP10.phx.gbl...
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.
"Peter Oliphant" <po*******@RoundTripInc.com> wrote in message
news:Om**************@TK2MSFTNGP14.phx.gbl...
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==]

"Tamas Demjen" <td*****@yahoo.com> wrote in message
news:Oi**************@TK2MSFTNGP11.phx.gbl...
> Peter Oliphant wrote:
>> 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.
>
> 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.
>
> Tom



Dec 2 '05 #20

P: n/a
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...
Dec 2 '05 #21

This discussion thread is closed

Replies have been disabled for this discussion.