Calling a window form from a Window UserControl

Question

1.20/5 (3 votes)

See more:

I to open a Window Form, from a UserControl.. is it possible any ways... i tried but it is not listing me any of the forms...!

eg:
1) I have created a userControl1
2) I have a windowForm1
3) NOW, I have to open a windowForm1 from userControl1's textbox keyDown event.

How can i do that...?

Please HELP...!

Posted 20-Feb-12 6:53am

AJV King

Updated 24-Oct-19 14:56pm

Add a Solution

Comments

BillWoodruff 20-Feb-12 19:15pm

Sri Ajay, if you respond in detail to the questions in the comment below, I will take the time to post what I think is a solution, and that will also give the other two people who posted solutions already the chance to revise their answers.

imho, this is a good example of premature answers to a question that needs clarification.

First, re the new Form you will create: is that going to be an instance of a pre-defined Form that you have already designed, created, possibly created publicly accessible features of, or just a plain generic new Form ?

Why are you using some KeyDown event in a TextBox on a UserControl in a Form to create a new Form ? This is a very strange design, and it would help to know your exact reasons for doing this (because it's a homework requirement ? because it's absolutely required by the nature of your project ... ?).

And, do you wish to create and show a new Form only once, or any time your particular Key press is performed by the user. If you want to allow the creation of multiple Forms: why ?

You need to clarify exactly what happens in the KeyDown event of the UserControl TextBox that creates of an instance of a new Form, and then calls its Show method to make it visible.

Surely you do not mean that you intend to create a new Form on any KeyDown of any Key ? In that case: imagine your application running, and the user types "whoops a daisy:" do you really want to create 14 new Forms :)

Do you realize that the new Form(s) you create by some user-action in the UserControl will have their 'Parent property set to "null:" which means they will be totally independent of both the UserControl, and the Form the UserControl is sited upon : unless:

As in most real-world applications, your new Form is going to need to exchange data or interact with either the UserControl, or a Main Form, or both. Then you will need to store a reference to any Form, or Forms, you create in the UserControl, at the moment you create them. Do you have any strategy for this ? This is where we need to know what the purpose of the Form created in the UserControl is: and how it is used.

One can guess what you mean, here, is that you need to recognize some specific Key press, possibly in combination with the modifier Keys (alt, shift, control), and only then create and show a new Form in response to that specific Key combination.

2 solutions

Add a Solution

Add your solution here

Treat my content as plain text, not as HTML

Preview 0

…

Existing Members

Sign in to your account

...or Join us

Download, Vote, Comment, Publish.

Your Email
Password
Forgot your password?

Your Email
This email is in use. Do you need your password?
Optional Password

I have read and agree to the Terms of Service and Privacy Policy
Please subscribe me to the CodeProject newsletters

When answering a question please:

Read the question carefully.
Understand that English isn't everyone's first language so be lenient of bad spelling and grammar.
If a question is poorly phrased then either ask for clarification, ignore it, or edit the question and fix the problem. Insults are not welcome.
Don't tell someone to read the manual. Chances are they have and don't get it. Provide an answer or move on to the next question.

Let's work to help developers, not make them feel stupid.

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

Ed Nutting · Accepted Answer · 2012-02-20T07:09:00

Solution 2

For your example use (roughly) the following :

C#

//Check what the exact arguments for this method should be but you get the idea
void OnKeyDown(object sender, EventArgs e)
{
    //Create an instance of your form to open
    windowForm1 TheForm = new windowForm1();
    //Now show it
    TheForm.Show(); //(alternatively TheForm.ShowDialog(); depending on your desired result
    //Your form should now be showing
}

This is all you should have to do to open a new form from any event. Be very careful though - this code will produce a massive number of windows open if a user just holds down the enter key say... I would suggest better code would be:

C#

//Create an instance of your form to open - outside the event so that it can be reused.
windowForm1 TheForm = new windowForm1();
//Store whether the form has already been shown
bool TheForm_Shown = false;
//Check what the exact arguments for this method should be but you get the idea
void OnKeyDown(object sender, EventArgs e)
{
    //Check to see if the form is already open or not
    if(TheForm_Shown)
    {
        TheForm.Close();
    }
    //Set the check to true as the form is now showing - set it before so that even if showing the form fails there isn't suddenly a mass of errors! 
    TheForm_Shown = true;
    //Now show it
    TheForm.Show(); //(alternatively TheForm.ShowDialog(); depending on your desired result
    //Your form should now be showing
}

Hope this helps,
Ed

Posted 20-Feb-12 7:09am

Ed Nutting

Comments

Sergey Alexandrovich Kryukov 20-Feb-12 13:21pm

Sure, a 5.
--SA

BillWoodruff 20-Feb-12 20:00pm

Reason for my vote of #2:

0. See my comments to SAK above on why giving any answer to this question without clarification from the OP is probably useless.

1. +1 because at least you do show the user some code.

2. when you 'Close the Form in your second example, if it is already 'Shown: you destroy it: you will have to re-create it using 'New to show it again.

Your code will crash the second time the user presses a key because TheForm will be null.

You can fix this by using 'Hide on the Form rather than 'Close, but this is still bad design.

Ed Nutting 21-Feb-12 2:14am

Sorry for my omission of the "new" line - I had meant to put it in. I have always found closing and recreating a form is better - it guarantees the form is reset regardless of what state the user might have gotten it into (even if theoretically and after testing there wasn't anything wrong with it).

BillWoodruff 21-Feb-12 2:34am

Actually, your code will will work if you just change using the 'Close method to 'Hide. If I see code I know will crash, I just can't help commenting on it: but I do note how much easier it is for me to see things that will crash in other peoples' code than my own :)

Whether or not it's better to re-create a Form: well, I think that depends on the context of the solution and its requirements. I balk at any suggestion of a "one-size-fits-all" position.

There have been many times I have hidden Forms, such as configuration Forms: because I wanted to retain the user's content in those Forms when they were made visible again, so the user could then edit only the content they wanted to change.

But, my main focus here is to point out that, in this case, our lack of information from the OP really limits how effective an answer we can give.

That's why I use this question, and its answers, as an example here:

http://www.codeproject.com/Messages/4162340/Perfect-example-of-the-QA-problem-I-now-call-Vague.aspx

Of what I, and many other people on CP, perceive as one of the structural problems with QA as it is now.

When you have some of the most brilliant people on CP, like Pete O'Hanlon, refusing to take part in QA any more because of what I call the "vague question followed by premature or digressive answer" syndrome: well, "Houston, we have a problem."

Please see the Site Bugs and Suggestions forum for many discussions we've had about this, and other issues. You can be sure that Chris Maunder, and the CP staff, are definitely aware of the problems in QA and doing their best to plan to ameliorate them in the future.

best, Bill

Sergey Alexandrovich Kryukov 21-Feb-12 5:16am

Bill, I commented on this comment, too. In particular, found one mistake in you note, please see below.
--SA

Sergey Alexandrovich Kryukov 21-Feb-12 5:14am

I must disagree that recreating a form is better, at least not always.
More typically, reset is not useful, but just the opposite is needed: fully preserved state of the form. Most useful pattern is overridden OnFormClosing to catch an attempt to close a form and hide it itself.

I don't know what Bill considers as a bad design, but the best design is using just one form. This is just out of scope.

I totally disagree with Bill about answering the question without clarification, as you can see in my comment to my answer. His note that the form will by null is just his mistake -- yet another. The form is created in first place and you never assign null to it. So, this is Bill's fantasy. It happens. But you will have another problem. When a form is closed, it is disposed, so you cannot show it again (just try to test the code and you will see). Sad but true -- you will have to create it again, but you don't do it. It is strange that in your comment you mention re-creation, but don't do it in code. I suggest you fix it, just to justify my vote of 5 (which I'm not going to change; not looking at your code thoroughly was my fault, too).

As to guesswork and Bill's denial of it -- I totally disagree with Bill. Of course, your idea to show and close the form repeatedly is strange, but I can consider is as an illustration of how bad is the unlimited creation of forms over and over. You don't have to wait for clarification: the OP's idea is weird enough, so you could not hold your breath. It cannot be further clarified. You business is different -- to lay out some facts and illustrate them to show what's involved. You did it in your own way, there is nothing wrong with it.

--SA

BillWoodruff 21-Feb-12 5:35am

SAK what is wrong with your brain today ?

"but the best design is using just one form" What are you thinking: I and other people create multiple Form applications all the time.

SAK wrote: "His note that the form will by null is just his mistake"

I never said that the form would be null as you state above: I specifically said that when the instance of the Form is created its Parent will be null, and I used this to preface the next paragraph which brings up the issue of keeping a reference to the Form.

You need to take a break, and regain your focus.

Sergey Alexandrovich Kryukov · Accepted Answer · 2012-02-20T07:01:00

Solution 1

There is no such verb as "open" a form. You just create it with a constructor and then show it with System.Windows.Forms.Form.Show, http://msdn.microsoft.com/en-us/library/system.windows.forms.form.aspx[^], http://msdn.microsoft.com/en-us/library/system.windows.forms.control.show.aspx[^].

To use your user control on some other form, you need to add to your user control and expose some event like "TextBoxKeyDown", because exposing the reference to the text box itself would be a bad practice; and hard-coding the event handler of your text box event KeyDown internally in the code of the user control would be even worse. If you handle the event outside the user control, you do it some other context where you may already have an instance of the form to be shown or where you can create one.

For better understanding, please read about loose coupling: http://en.wikipedia.org/wiki/Loose_coupling[^].

Generally, showing a form on a click in a text box looks like an ill UI design.

—SA

Posted 20-Feb-12 7:01am

Sergey Alexandrovich Kryukov

Updated 20-Feb-12 7:22am

v3

Comments

Ed Nutting 20-Feb-12 13:11pm

Good comments and links, my 5+ :)

Sergey Alexandrovich Kryukov 20-Feb-12 13:21pm

Thank you, Edward.
--SA

BillWoodruff 20-Feb-12 19:33pm

My reason for voting this answer #1:

0. unnecessary pedantry and digression: the user doesn't really need a lecture on why they should not use the word 'open:' you'll even find that term in some .NET books published by MS Press.

1. vague: "just create it with a constructor:" not vague: you create a new Instance of a Windows Form Object using 'New, which is a standard Constructor for Objects.

2. vague: "To use your user control on some other form, you need to add to your user control:" not vague: "to add an Instance of a UserControl to a Form, you can either add it at design-time from the ToolBox (in which it will appear when it is compiled), or add it at runtime by creating an Instance of it using 'New and then calling the 'Add method on the Forms ControlCollection, passing the Instance of the UserControl as the parameter to the 'Add method.

3. off-topic speculation: the OP clearly states that he wishes to create a new Form in response to a KeyDown in a UserControl: you go off on a tangent here that ignores the question.

In this case we do not know enough about the user's intention, or design, to speculate about such topics as "loose coupling." Which is why you should have asked the user the kind of questions I ask him in my comment before going on an all-too-typical, for you, digressive and vague answer.

By the way, I agree with you that, in general, the idea of a key-combination in a TextBox as a trigger for creating a Form is bad design, unless there is some exceptional reason here. But that is just more speculation.

Sergey Alexandrovich Kryukov 20-Feb-12 20:05pm

What happened to you, Bill?

I don't know if I really need to reply... Well, let me try:

0. You say this like this is something bad. :-)

1. Not vague because it's absolutely irrelevant what constructor to use; any instance constructor providing instance returns an instance; this is all what matters; besides, "using New, which is a standard Constructor for Objects" is gibberish: "new" is not a constructor, and there is no such thing as a standard constructor; I'm asking again: what happened to you, Bill? I thought you knew programming a bit; look, my advice is: don't expose your shame, remove it, and I will gladly remove my comment.

2. You just did not get it. I explained what event should be added to a user control class, and you are talking about adding a user control member to a form; I assumed that OP knows why creating a user control; one of its purposes is to be able to be added by a Designer;

3. Let me decide on the scope of my answer; sometimes I tell a whole anecdote on the topic; I am providing some help to an enquirer, not answering exact question because I think this is much more valuable.

With "loose coupling" you just missed the point because you missed the point in your item #2. There are two options: 1) to handle a click with opening of some window in the event handler of TextBox.KeyDown; 2) create some event of the user control, and invoke this event (after a check for null) from the event handler of TextBox.KeyDown. Case #1 is too tight coupling making the control less universal and expanding its access scope; #2 is loose coupling making handling of the event more flexible.

Maybe I wasn't clear enough, but in this comment I've explained more of it.

Best wishes,
--SA

BillWoodruff 21-Feb-12 1:10am

Hi SAK, l

Let me note that I never used the word "bad" in my comments to you. My criticisms are quite specific. And, the issue of this being a "vague question" has far greater "weight" in my mind than anything else.

If I had wanted to pass some "summary judgement" on your solution (which I did not), I would have used language like: "not worthy of your intellect and abilities, as demonstrated on QA quite often." :)

Feel free to "skewer" me, here, on "Site Bugs and Suggestions," if you wish:

http://www.codeproject.com/Messages/4162340/Perfect-example-of-the-QA-problem-I-now-call-Vague.aspx

Where I have used this question as an example of what I see as one of the key problems on QA today.

best, Bill

Sergey Alexandrovich Kryukov 21-Feb-12 2:58am

I don't mind if you call bad thing "bad". If I see I really did bad thing, I will try to fix it and express my gratitude. Did you ever hear I complain when someone criticize me, even as a person? I don't think so. There are many things I do pretty badly, so what? If someone tells me something bad, I'll either argue if I think this is not true, or will try to improve myself.

You probably noticed that I never hesitate to call spade a spade. I think this is fair and ultimately more useful for those who is being criticized. In sciences, technology and arts the criticism is one of the main driving forces of the progress.

My attitude to your post is not an exclusion. I just pointed out what I thing was your mistakes and clarify my answer, which could be not clear enough. If my answer was unclear, I could readily agree, but I cannot agree about vagueness (which is a very different concept), and I think I explained that.

I think I understand your concerns about the QA problem and I share some of them and try to appeal to other experts to take my opinion into consideration. I've just read your comments to the question. However, the approach should be balanced; and there is nothing wrong if it depends on personality. In case of laziness and impudent behavior a litter harder treatment is quite appropriate, but the little vagueness in the question sometimes is not a reason for turning the question down. I would like to explain my view on that. Answering the question is not a main criteria. The answer should be interesting enough to some of the readers, or hopefully useful. The answer should help, not just answer. Helping is more important. A very formal answer to a pointless question can be useful, too, not as the answer to the question, just as a demonstration of the effect of inaccurate answer.

For example:
-- Excuse me, do you know what time is it now?
-- Yes I do. [end of dialog] :-)

Does it make any sense. Of course.

The purpose it to increase the total amount of good and reduce the total amount of evil in the World. :-)

Thank you for the reference to your post, which is certainly a respectable one.
--SA

Manfred Rudolf Bihy 21-Feb-12 2:38am

While I agree with Bill on the pedantery on the verbage "open a form ", which very much goes with common usage, I strongly agree with the rest of your statement. Thus my 5!

As a side note I want to once again appeal to you as a valuable CP member to take a step down once in a while when dealing with requests of members that do not have as good of an understanding and command of proper English. While it is true that some are just plain lazy there are also some that just can't do any better and they deserve our help just the same.

Best Regards.

Manfred

Sergey Alexandrovich Kryukov 21-Feb-12 3:15am

Thank you very much, Manfred -- for your vote but especially for your comments, even though I'm not quite agree.
You see, I totally agree with you when you argue that the people of different cultures who have some problems with English, not related to their careless or lazy attitude. I don't know if you notices how accurately I tried to help such people. (After all, I have some problem with English myself; leaving in US, I wish I could know it much, much better, which would make my everyday life easier.)

I only disagree with your note on this particular case. Why would you talk of my pedantry as of something bad? Why do you think it shows any negative suggestion against OP? I think this sentence is nothing but help, and pretty important piece of it. You see, this is not even related to the particular language, but more to a concept. The open/close form terminology can be translated in any language and express a pretty common misconception. (I knew other such cases, I wish I could remember some of them now.) The term "close" suggests the presence of "open", and this can mislead anyone. One can open and close the file or a stream, but not a form or a window. All APIs contain the word "Close", but never the "Open" (a windows or a form). A novice sees "Close" and tries to find a "counterpart" named "Open"; and the absense of "Open" is counter-intuitive. That's why the phrase "there is no such verb" is a valid hint: "don't waste time searching for it -- there is no such concept".

I really don't understand why such a helpful hint (sorry if it was not quite clear) could be possibly perceived negatively.

So, do you have better understanding now?

Thank you again,
--SA

Manfred Rudolf Bihy 21-Feb-12 3:47am

All I was saying SA was that "to open a form" is common and proper usage of English meaning of course, translated to programmer language, that we need to instantiate and show it. So please do not misunderstand me when I say that, while being semantically correct, that you do miss the target in being to pedantic regarding, what you conceive as proper wording. While I do agree that some verbal imagery has to be stopped (inappropriate use of parent child relationships) there is no need to extend this to common and understood language patterns such as "opening" a form.
As a side note I have to mention that using natural language in a programmers context is always prone to leave us with ambigious interpretations, these can usually be easily resolved in the given context. though.

Best,

Manfred

Sergey Alexandrovich Kryukov 21-Feb-12 4:56am

Yes, I hear you. Perhaps my attempt to create a blending and metaphor expression with the word "verb" failed to make its metaphoric meaning clear enough, maybe due to my insufficient sense of English language. I still consider my finding of this "linguistic" incoherence as useful, but if you did not get it the way I wanted to express, I can believe that my attempt was not particularly successful. Interestingly, I started thinking with much longer sentence but finally decided that a short sentence with the "verb" would be more expressive.
By the way, your last "side note" only encourages some extra pedantry, as a little tool to reduce the ambiguity. :-)
--SA