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/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/d...irectplay.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==]
Lloyd Dupont said:
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 said:
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.
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==]
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
ure. Does evoking CModeless violate /clr