|
yes, it will run as soon as Form1 gets closed; however the other Forms (also) being modeless, the main code will run to completion immediately after creating those Forms, so you probably will never actually see them. Try adding a MessageBox.Show inside the Form2 constructor!
|
|
|
|
|
Nice, +5 
"Don't confuse experts with facts" - Eric_V
|
|
|
|
|
Good point, Luc: perhaps I should have said: "after the termination of the Application.Run(SomeForm) process, while, technically, the code that follows will be kind-of executed, the programmer who believes this is useful, in some practical way, needs medication for stress immediately." ?
As long as we're cataloging horrors: this will actually work:
Application.Run(new Form1());
Form1 f3 = new Form1();
f3.Text = "BAD PROGRAMMING STYLE INCARNATE";
Application.Run(f3);
Yup, when Form1 is closed, a new Windows Message Pump is instantiated, and Form 'f3 has its day in the sun.
Again, a pointless exercise: after all: all 'state' created in the first Form's life-cycle is gone when it is closed.
best, Bill
"In the River of Delights, Panic has not failed me." Jorge Luis Borges
modified on Tuesday, August 23, 2011 2:36 AM
|
|
|
|
|
I'm afraid I can't agree once more.
public static void Main() {
Application.Run(new Form1());
Application.Run(new Form2());
}
makes perfect sense to me, it will show and run Form2 once you're done with Form1; there may be no need to share state between those Forms, or there may be some mechanism that shares that state, maybe additional data structures in the class that holds such Main() method, maybe in some other global or singleton class, maybe in a database, you name it.
A simple example could be: Form2 is the actual application, Form1 is a complex license dialog which connects to a license server, interacts with the user, asks for a new license key, etc. When the license fails, it calls Application.Exit(), preventing Form2 to even get constructed, hence being safer than a dialog shown by Form2's constructor or Load event.
|
|
|
|
|
Correct, my +5 . I failed to realise that, thanks for pointing out. But again even if you show the other forms before calling Application.Run() with the main form, the application ends as soon as the main form closes. And if you show all forms using its Show method and call Application.Run() without arguments, the app keeps running in the background even if all the forms are closed (unless, of course, you call Application.Exit())
"Don't confuse experts with facts" - Eric_V
|
|
|
|
|
Shameel wrote: And if you show all forms using its Show method and call Application.Run() without arguments, the app keeps running in the background even if all the forms are closed (unless, of course, you call Application.Exit())
Hi Shameel,
Right you are, and in my bottom-most top-level response to this thread, I indicated a simple strategy to handle that potential case of the "formless application." Let me run it by you again:
1. for each Form you launch, insert an EventHandler for the Form.Closing event.
2. in that handler check if the Application.OpenForms.Count == 1: if so, call Application.Exit.
It's a strategy I have used many times; I think of it as a variant of the so-called SDI pattern multiple-form WinForm architecture as described by Chris Sells, and others.
best, Bill
"In the River of Delights, Panic has not failed me." Jorge Luis Borges
|
|
|
|
|
Thank you both guys, but there is a problem with this solution.
Since Application.Run() operates with the same thread, it is not able to discriminate which is the form that is being used by user (buttons, data, client_id...)
But I think that must be re-coded by me...
Regards,
D.
|
|
|
|
|
You can certainly keep track of what Form is Active:
For example:
1. Create a static public class in which you have a variable of type Form named TheActiveForm
2. Write event handlers for the Activated and Deactivate Events of all your Forms and have them update the static variable 'TheActiveForm.'
If you wish you can turn that static class into a complete event-handler that accepts and forwards messages from Form to Form, etc.
Please note that my saying you 'can' do this doesn't mean 'doing this' is right for your particular solution.
best, Bill
"In the River of Delights, Panic has not failed me." Jorge Luis Borges
|
|
|
|
|
I mean, Application.Run() has 3 overloads, one of them is Application.Run(Form mainForm).
I want to call it simultaneously as many forms as I´ve opened before, but the problem is that Application.Run cannot be multiple-called.
I hope it´s clear enough what I need and someone can help me.
Ty,
D.
|
|
|
|
|
An application can have only one main UI thread at a time, your main form. To open other forms you need to use Show or ShowDialog if they are modal. You can do this in the load event of the main form.
I know the language. I've read a book. - _Madmatt
"The OP herself was not sure about her question"
"The OP is from India and I know what she meant." - Shameel
|
|
|
|
|
Thanks Mark 
|
|
|
|
|
Your scenario I find a little ambiguous: you write, on the one hand, about connection threads on the same WinForm, but, then you write of having multiple Forms: can you clarify that a bit ?
In any case you don't want to be calling Application.Run more than once.
If you are describing a scenario in which there isn't the typical pattern of a single new instance of some Form passed as the argument to Application.Run(new MainForm), and you 'Show a bunch of forms before calling Application.Run():
If that is your goal, there's nothing wrong with that: but you then need to consider the implications of that strategy:
1. there's no single Form which, when closed, will close all the other open Forms and exit the Application: you could possibly, by closing all open Forms, leave the Application running without you having any way to access it, or terminate it.
An easy work-around for the problem of closing the Application in this scenario is to write a handler for each Form's 'Closing' event, check and see if the collection of open forms in Application.OpenForms.Count == 1, and if that's the case, do an Application.Exit().
A question: what reason do you have for not creating other forms inside a MainForm launched in the usual way ?
best, Bill
"In the River of Delights, Panic has not failed me." Jorge Luis Borges
modified on Tuesday, August 23, 2011 2:38 AM
|
|
|
|
|
Thanks Bill,
Looks very useful the feature about checking the number of openforms for exiting the app.
According to your question, I must develop this application to be able to open up to 8 different forms, because that´s the maximum number of simultaneous connections that the external server can handle from a client (just changing the client_id number).
So, by now, I just have to open these 8 forms when launching the application and see how to handle them like they were independent one from the others.
After this, I´ll do the upper layer for managing how many forms can be launched and all the control stuff.
Thanks again for your time,
Regards,
D.
|
|
|
|
|
Hi, one idea that may be useful if you are required to instantiate all eight forms when the Application starts, rather than creating them on-the-fly in response to events or input: which means you must call 'Show for each Form in your Program.cs static Main method:
You may need to implement control over whether or not one, or more, of your eight forms can be closed, or not: since, if closed, they will have to be re-instantiated by using 'Show again: here's an example of one possible way to handle that case:
private void Form1_FormClosing(object sender, FormClosingEventArgs e)
{
(sender as Form).Hide();
e.Cancel = true;
}
However, in my opinion, if you really don't want the user to close a Form, then best to create the Form without a ControlBox ... but that leaves you with the issue of how, if you allow it, the user can hide forms.
The issue of how to best manage a WinForms application with multiple independent Forms is a very interesting one, and I hope to publish a CP article in the next month on that issue.
One strategy to consider is to have a static class that functions as a Form manager, to which Form events are routed, and in which messages between Forms are dispatched.
best, Bill
"In the River of Delights, Panic has not failed me." Jorge Luis Borges
|
|
|
|
|
Thanks Bill, that will be useful when handling the quantity of forms that must be launched or when they must be closed, but now I´m in a lower layer so I don´t care about it until I can handle the eight forms independently.
Regards,
D.
|
|
|
|
|
I´ve seen this post update now, thanks bill.
I have done this:
public static List<frmPpal> FormsList { get; private set; }
static void Main()
{
FormsList = new List<frmPpal>();
for (int i = 0; i < 8; i++)
{
frmPpal form = new frmPpal(new DayTradeFacade());
FormsList.Add(form);
form.Show();
}
Application.Run();
So now, I can access to the FormList from the other classes of the Project.
But how can I know which one is active? I mean, from which one has the user called.
ActiveForm doesnt seem to work properly because frmPpal is not a default Form.
Any suggestions?
Thank you for your time and help,
Regards,
D.
|
|
|
|
|
1. a function that returns any type of object can be called without using the result:
private string whale(string theSpeciesOfWhale)
{
return theSpeciesOfWhale + " is a whale";
}
private void someMethod()
{
whale("Baleen");
}2. You can add a new Class to a Project, remove the NameSpace declaration added by VS, and in it define classes, dynamic, or static: you can then access these classes from anywhere else in your Project directly:
using System;
public class anyClass
{
public int someInt;
}At first, I thought perhaps there was an 'implicit default' NameSpace based on the Assembly name, but trying to access a class defined in a no-NameSpace form by using the Assembly name + dot + class name: does not work.
Both of these use-cases were just 'stumbled upon' by accident, and somehow they seem, to me, to be not 'congruent' with the strongly typed nature of C#.
In the case of allowing a function to be called, and not handling its return value, I can kind of see the rationale for that: in one instance you might call said function just for a side-effect, and in another instance you might want to do something based on the value it returned. I would not want to write code that allows even a slight ambiguity of interpreted use, so, in that case, I would write two functions.
The second case just seems like a 'puzzle:' when 'anyClass is defined above, does it exist in a NameSpace ... or not ?
Well, what say you: is this another instance of my inability to perceive the glorious meta-structure of .NET and C# in Visual Studio ?
best, Bill
"In the River of Delights, Panic has not failed me." Jorge Luis Borges
|
|
|
|
|
The first one is quite convenient in the case where a 'function' actually has side effects and you may not care about the return value. It stops you having to write
sink = Whale("baleen");
... and then probably getting a warning that 'sink is assigned but the value is never used' for your trouble. It's also inherited behaviour from C.
The second one is not in a namespace. The default namespace is just a VS thing, namespaces on classes are simply defined within the source file, and if you don't specify one, your code is not in a namespace.
|
|
|
|
|
I would expect neither of those cases to throw an error.
In the first one, you're just ignoring (dropping) the return value without using it. Lots of languages allow this behavior.
In the second, your code is still in a namespace. Open the Project Properties and you'll find "Default Namespace" specified.
|
|
|
|
|
Thanks, Dave,
My observation that using the return value of a function is not required in C# was, perhaps, surprising to me since I associate such lexical 'slack' as being found in more weakly typed languages (LISP, PostScript in my experience).
Personally I would like the C# compiler to flag cases where I ignore the return type of a function.
The C# compiler will certainly not let you get away with this:
private void someFunc(string someValue)
{
}
private string someFunc(string someValue)
{
}
best, Bill
"In the River of Delights, Panic has not failed me." Jorge Luis Borges
|
|
|
|
|
Correct. You can't vary an overload just by the return type.
But, in this example, the compiler will throw if you specify a return type, but don't return anything.
|
|
|
|
|
Dave Kreskowiak wrote: In the second, your code is still in a namespace. Open the Project Properties and you'll find "Default Namespace" specified.
Wrong, code without a namespace ends up in the global:: namespace. The "Default Namespace" in the Project Properties is used for the autogenerated classes like resources and settings, etc.
"Don't confuse experts with facts" - Eric_V
|
|
|
|
|
Crap, my bad. I was thinking about VB.NET's version.
|
|
|
|
|
Must be a slow news day. 
|
|
|
|
|
in C# a method may or may not have a return type (other than void), and when it does you may or may not be interested in it.
The same idea has existed ever since C and C++ came to be; and it is different from the Basicy function/subroutine dichotomy.
So there is no error whatsoever.
However, there is one particular case where a warning message would be extremely welcome:
string text="...";
text.Insert(0, "aha");
since strings are immutable, string methods like the one shown are returning strings, ignoring the return value does not make much sense (unless you really want to test for valid parameters and dealing with a possible exception).
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
