|
How to create parent form and child form usin c#.
I want to create a parent form and two or three radio buttons should be on parent form, when user click on 1st radio button then a child form should be opened related to 1st radio button and another radio button vice-versa.......
Please reply Quickly.........
DSPNEO
|
|
|
|
|
Put a button on there, doubleclick;
public void Form1_Button1_Click(object sender, EventArgs e)
{
using(var myForm = new FormChildWithCoolName())
{
myForm.ShowDialog(this);
}
}
DSPNEOqqq wrote: Please reply Quickly.........
Quickly, quickly Zathras..
Bastard Programmer from Hell 
if you can't read my code, try converting it here[^]
|
|
|
|
|
Eddy Vluggen wrote: Quickly, quickly Zathras..
Babylon 5?
Why is common sense not common?
Never argue with an idiot. They will drag you down to their level where they are an expert.
Sometimes it takes a lot of work to be lazy
Please stand in front of my pistol, smile and wait for the flash - JSOP 2012
|
|
|
|
|
Yup 
|
|
|
|
|
Create your forms, set the parent form as Owner of the child. May be MDI forms can helps too.
That's all.
Christian Amado
MCITP | MCTS | MOS | MTA
Olimpia ☆ ★★★
Please mark as answer, if it helps.
|
|
|
|
|
Hi,
First, I believe that Child Forms should never be used, that they lead to awkward user-interfaces, and the old MDI-architecture, which supported MDIChildForms with "special features," deserves the status of a "dinosaur" skeleton: to be looked at, but not re-animated
I think you can get better responses to this scenario if you describe what the function of your proposed use of "Child Forms" are, in relation to their "Parent" Form.
Is it possible a Dialog can fit your needs here ?
Consider that you create a "Child Form" with code like this in response to some event:
Form form2 = new Form();
form2.TopLevel = false;
form2.ShowInTaskbar = false;
form2.Parent = this;
form2.Name = "form2";
form2.Text = "form2";
form2.Size = new Size(300, 200);
form2.Show();
form2.BringToFront();
You now have a Form that is in front of your MainForm, and that, depending on FormBorderStyle, can be moved around so parts of it are invisible, as they extend beyond the DisplayRectangle of the MainForm. Depending on its z-order within the Form ... that is if some other control on the Form has been brought-to-the-front: it could appear "behind" other Controls on the Form.
Consider that you create a Form which is not a ChildForm: like this:
Form form2 = new Form();
form2.ShowInTaskbar = false;
form2.Name = "form2";
form2.Text = "form2";
form2.Size = new Size(300, 200);
form2.Show();
form2.BringToFront();
Now you have a Form you can move anywhere on the screen, depending on the setting of FormBorderStyle, and it will always be visible ... unless you activate the MainForm and bring it to the front, and the MainForm covers part of the second Form.
If you wanted this new Form to always remain on top, no matter whether the MainForm was activated, or not: just set the new Form's TopMost property to 'true, while making the sure the MainForm's TopMost property is set to 'false.
Another area to investigate, if you are concerned with your new Form always appearing on top, is the use of 'ShowModal(), in contrast to 'Show().
Keep in mind that: if your WinForms project opens in the rather standard way by creating an instance of the MainForm in the Program.cs class: that closing the MainForm will always automatically close any secondary Forms created.
In either case, if you need to exchange information between the MainForm and ChildForm, or MainForm and/or new, "independent" Form, the issues will be exactly the same: you'll need to keep a reference to the newly created Form in the MainForm ... assuming that's where you'll always create this new Form, whether Child, or "independent;" so: make sure that outside the method that creates the Form (i.e., at Form level scope) you create a reference you can access, like:
private Form form2;
private void SomeButton_Click(object sender, EventArgs e)
{
form2 = new Form();
form2.ShowInTaskbar = false;
form2.TopMost = true;
form2.Name = "form2";
form2.Text = "form2 within Form class scope";
form2.Size = new Size(300, 200);
form2.Show();
form2.BringToFront();
}
If you do need access to whatever in the MainForm to whatever in new Form, or vice-versa (data, contents, position, state, etc.): then there are plenty of solutions for how to do that here on CP in the QA forum (it's one of the most frequent questions asked). Hint: expose public properties.
... edit 1 ...
For example:
In the MainForm, create a Public Property that will "expose" the instance of the MainForm you create:
public static MainForm TheMainForm { get; set; }
ThisMainForm = this;Once you have done this, you can access anything declared Public on the MainForm, from outside the MainForm, by simply using: "MainForm.ThisMainForm."
Warning: this technique should only be used on Forms where you create one instance only ! Why: because a Form-level public static Property is always going to point to one, and only one, instance: if you had multiple instances (heaven help you) of your MainForm, changing some public variable's value there would also change it "globally:" so in all other instances: it would have the same value !
For your secondary Forms, you do not wish to use this same technique of a static Form-level Property to enable access to their "public stuff:" because, after all, each instance of a secondary Form is going to have the same controls, the same Public Form-scoped variables, etc., and, at run-time these may take on unique values.
But, your MainForm can access every instance of a secondary Form it creates (and everything scoped Public on it) by simply putting it in a unique public variable when it is created.
Finally, note there are other "models" for passing information between Forms, including using custom Events, and EventArg data structures: you'll find examples of other approaches, and lots of debate about the different ways of enabling Form to Form interaction in the QA section here on CP.
... end edit 1 ...
best, Bill
"Everything we call real is made of things that cannot be regarded as real." Niels Bohr
modified 12-Aug-12 23:35pm.
|
|
|
|
|
BillWoodruff wrote: First, I believe that Child Forms should never be used, that they lead to awkward user-interfaces, and the old MDI-architecture
..I'd like to see a version of Visual Studio with an SDI-interface. MDI isn't dead, it's merely abused a lot. We'll say the same thing about that Ribbon on a few years
BillWoodruff wrote: I think you can get better responses to this scenario if you describe what the function of your proposed use of "Child Forms" are, in relation to their "Parent" Form.
Good point; when an apparant beginner talks about child-forms, I usually assume (I know, we should check, not assume) that they need to display a dialog, and that they forgot to specify the owner of the form (often confused with the parent).
+5 for giving a very elaborate answer that does not only benefit the TS.
Bastard Programmer from Hell
if you can't read my code, try converting it here[^]
|
|
|
|
|
Hi,I developed a application which contains some panels.my desktop screen resolution is 1280X768.When the same application runs in some other system whose desktop resolution is 1024X768 it is showing in another way.
Eventhough I changed the Form and its UI elements size programmatically in the form constructor like below there is no change in their dimensions.
int screenWidth = Screen.PrimaryScreen.Bounds.Width;
int screenHeigth = Screen.PrimaryScreen.Bounds.Height;
this.Size = new Size(screenWidth, screenHeigth);
this.Invalidate();
this.Update();
InitializeComponent();
this.pnlSi.Size = new Size(screenWidth, screenHeigth);
this.pnlSi.Invalidate();
this.pnlSi.Update();
this.pnldjt.Size = new Size(screenWidth, screenHeigth);
this.pnldjt.Invalidate();
this.pnldjt.Update();
Anybody please inform me how to resolve this issue?I mean changing the form and its UI elements programmatically at run time as per application running system desktop resolution?Thanks in advance.
|
|
|
|
|
How is it not showing in the correct way? what is the actual issue. All I can see is that you are setting 2 panels and the form to the same size at runtime
Lobster Thermidor aux crevettes with a Mornay sauce, served in a Provençale manner with shallots and aubergines, garnished with truffle pate, brandy and a fried egg on top and Spam - Monty Python Spam Sketch
|
|
|
|
|
InitializeComponent(); should be the first statement after the constructor. Do you know what happens in that function? A lot of values, among them positions and sizes, are set.
I'd rather use a this.WindowState = FormWindowState.Maximized; in the Form_Shown event. If you want to re-order the elements, you can additionally subscribe to a Resize event, and do that there.
|
|
|
|
|
I believe Bernard Hiller gave you the correct answer (I voted his answer #5, naturally): move the call to InitializeComponent() to before your Form and Panel adjustment code.
An edge-case hypothesis could be: the monitors have different aspect ratios, but I doubt that.
best, Bill
"Everything we call real is made of things that cannot be regarded as real." Niels Bohr
|
|
|
|
|
Hi,
I need to create a windows forms application having collapsible panel with some controls like label and picture box inside the panel.How to do this?Please help me by providing a sample solution or steps.Thanks in advance.
|
|
|
|
|
ukraju wrote: Please help me by providing a sample solution or steps.
That's the wrong way of learning to develop; you start with a book or easy tutorials and work trough that - starting a project without knowing where to begin and asking for help on every step of the way will not be a "fun" way of learning, because of comments like mine
If you've been assigned this "problem" by a teacher, please introduce him/her to this thread.
Drop a Panel on your form. Notice that you can hide/show the panel using it's Visible property, or the Hide/Show methods. Also note that a Panel inherits from Control, and that it can notify you if the user enters or leaves the panel (see MSDN[^]).
Drop your other controls on the Panel, and implement the logic to show it when the mouse enters the control, hides it when it leaves the control.
Next, you'll notice that it will not unhide; that is because you cannot "enter" an invisible control. So, we'll introduce the Size property right away: if the mouse enters the control, make the Panel a 100 pixels wide, if it leaves the control, make it 25 pixels wide. First state is called "Normal", seconds state is called "Collapsed".
You can earn bonus-points by wrapping it all in a re-usable UserControl and writing an article (submit on this site of course) on the topic. Yes, we welcome articles that provide a sample solution and/or steps.
Bastard Programmer from Hell
if you can't read my code, try converting it here[^]
|
|
|
|
|
I think you got the best possible advice from Eddie Vluggen in his post above: you need to "ground" yourself in the fundamentals of what Forms, and "container controls," like the Panel Control, are:
And, the fact that true "container controls," at design-time in Visual Studio, allow you to drag-and-drop other Controls within them, at which point those dropped Controls have their Parent property set to the Container Control they were dropped into: you hide the Parent container control: everything within it is hidden.
The only thing I can add here is to suggest that, to me, a "collapsible" Panel, implies that some part of it will always be visible: the simplest way to achieve that is, as Eddie suggested, to manipulate the Size property of the Panel using the Enter and Leave events of the Panel. If you want to leave the Panel "fully open" some of the time, when the user moves the mouse outside the Panel: that requires a different solution.
There are other, more sophisticated techniques (but still rather simple to code), for when you need multiple Panels that open and collapse within an outer Panel, leaving only one open, as in the famous "Outlook Bar" interface.
edit ... Hint: use Panels set to Dock.Top within an outer Panel, and respond to Click events on the inner panels by iterating the ControlCollection of the outer Panel, and doing the right thing to hide and collapse the inner Panels.
good luck, Bill
"Everything we call real is made of things that cannot be regarded as real." Niels Bohr
modified 11-Aug-12 21:34pm.
|
|
|
|
|
Again, Eddy's advice rules. But of course you could also use a command button to control the panel size. That way it changes when you tell it to rather than based on where the mouse is.
I've only recently used the panel for the second time and on this occasion I am placing an image, label and command button on at run time rather than design time one per row, based on the number of rows on a particular database table.
Its well worth the effort.
Ger
|
|
|
|
|
Good point, Ger,
Indeed, a given UI of this type (sub-panels in a Panel) is may be designed to allow any number of sub-panels to be expanded, or collapsed,or "accordion style," allow only one sub-panel to be open at-a-time: that may mean you need to deal explicitly with visibility, assuming you have the Panel's 'AutoScroll property set to 'true, and there are sub-panels in the Panel's ControlCollection which are scrolled out of view.
I assume you add these controls to your sub-panels at run-time because: either you don't know the number of rows until run-time, or, the end-user may set a parameter that affects number of rows to be rendered into sub-panels on Load, or the user "on-the-fly" changes the number of rows they want rendered into sub-panels (via selection or query or whatever).
Personally, I'm a "true believer," in this situation, in creating a UserControl that can be multiply instantiated, that contains all sub-elements: such as the ones you described: image,label, command button, and then keeping a Collection of those back on the "ranch" (some "MainForm") in a form of a Generic Dictionary, which will vary depending on the scenario, but may be like: Dictionary<subPanel, bool>, where the Boolean might indicate if its "open," or "collapsed."
... edit ...
Assuming a scrollable outer container Panel: if the user does some selection activity ... outside the container Panel ... that will then determine that sub-panel#x needs to be visible, you may have to adjust the scroll-position in your code, if the targeted sub-panel is currently scrolled out-of-view: this is a reason why I like using a generic collection here: to get away from code like
panel2.ScrollControlIntoView(panel2.Controls[0]); ... end edit ...
But, that's just another recipe from Mama's Kitchen, and I am not questioning the way you are doing things now: just extending your comment a bit.
"Each scenario may require a different UI solution that is optimal" is such a cliche, that I won't even mention it here 
best, Bill
"Everything we call real is made of things that cannot be regarded as real." Niels Bohr
modified 13-Aug-12 9:25am.
|
|
|
|
|
hello,
I have to open web page with address bar, specified width, Height from window forms without using
WebBrowser control.
help is appriciated
|
|
|
|
|
Then how are you going to show the page??
Without the WebBrowser control you'll have to implement your own rendering engine. Good luck with that!
|
|
|
|
|
Dave Kreskowiak wrote: Good luck with that!
Wheres that dammed sarcasm smiley!
Never underestimate the power of human stupidity
RAH
|
|
|
|
|
vikaskardode wrote: without using
WebBrowser control
Enjoy 
Bastard Programmer from Hell 
if you can't read my code, try converting it here[^]
|
|
|
|
|
In back-and-forths with this poster on QA in this thread:[^]:
I am left with the idea about writing perhaps three articles, aimed at relative beginners with WinForms, showing how to use inheritance to create Forms that essentially duplicate an existing Form (where, for example, you want a set of standard identical controls with identical behaviors on every Form created).
Second, I would like to discuss the shortcomings of that approach when you, for example, wish one Form that inherits from a "master Form" to not have one of the inherited controls (which in the designer appear "locked" when: you create a new Form, add it to the Project, and then make it inherit from the "master Form.")
Third, I'd like to compare the strategy of switching between identically sized and positioned Forms to vary the user interface (which is what the OP of the QA post linked to above was after), vs. the simpler strategy of using Panels which are switched at run-time on one Form (but where said Panels may also use inheritance in the same way as described above with Forms).
My question is: given the possibility that WinForms is now no longer of that much interest to CP members compared to the latest "hot stuff:" is it really worthwhile to write this up, and include tricks like use of a static class to manage multiple Forms, or Panels, or modifying the Program.cs class to call an 'Initialize method in a static class, etc.
thanks, Bill
The glyphs you are reading now: are place-holders signifying the total absence of a signature.
|
|
|
|
|
I don't see any harm in doing this even though WinForms is not as hot as new technology with .NET, but you never know when someone might have a need for it and an article would be useful for them.
"Real programmers just throw a bunch of 1s and 0s at the computer to see what sticks" - Pete O'Hanlon
|
|
|
|
|
BillWoodruff wrote: WinForms is now no longer of that much interest to CP members
I get the impression there are still lots of CPians using this technology, and will be for a good few years to come. If you think the article(s) would be useful then give it a go.
|
|
|
|
|
BillWoodruff wrote: is it really worthwhile to write this up
Yes, it is. Not every shop uses WPF, a lot of them still build on the controls that they and their customers are familiar with. I'm still using WinForms as WPF isn't implemented in Linux. Yes, Gtk# might be an alternative, but that would introduce a learning-curve for anyone unfamiliar with Gtk#.
Bastard Programmer from Hell
if you can't read my code, try converting it here[^]
|
|
|
|
|
i want to display large content i.e data may be 50 to 60 mb for example bible in desktop application.how i can do that?
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
