|
What you are really looking at here is usually known as a client-server application. The database will be placed on the server and the client will reside, well on the client. There are many different ways you can partition your application; for instance, you could partition it so that using MVC and an n-tier architecture.
As to what type of app you should write - that really depends. If you need to interact with the local file system, I'd go with a desktop based approach. If everything could be handled through a browser, then I would go with a web based architecture. Only you know your requirements.
|
|
|
|
|
Thanks for ur quick reply.
Everything can be handled through browser. so I think I will go with web based application.
Can you provide some links on these kind of applications or a small sample ?
|
|
|
|
|
Here is a MVC4[^] implementation but I wouldn't use EF.
Edit I forgot to add the link.
Edit 2 Link paste bug.
David
|
|
|
|
|
See this[^] step-by-step tutorial.
/ravi
|
|
|
|
|
Pdeveloper wrote: Windows ? or Web based ?.
What is your client looking for?
Are they ok if you install the client on their local machines.
|
|
|
|
|
I have "bought into" the view that programmers in WinForms should not put a Form inside a Form. My reasoning has gone something like this: [1]
1. A Form is a "heavy-weight" object; using "lighter-weight" objects. like a Panel on the Form, a UserControl (for re-usability), or other ContainerControl(s) on the Form, is better practice. And, I believe the idea of using a TabControl to implement a multi-document work-space is a good one.
2. A Form within a Form (if it is movable: that is, if it has a TitleBar) can easily be moved at run-time so almost all of it is "outside" its Parent Form. It's actually possible to "lose track," visually, of a Form within a Form if: you do "just the wrong thing" while the outer Form is Maximized, and then set the Form WindowState back to 'Normal. Of course, the programmer, can easily write code to control for such cases.
3. Particularly for newcomers to programming in WinForms, putting a Form in a Form is "bad practice" that leads to programming errors, hair growing on the palms, etc.
If I consider what, if any, advantages there might be to using a Form within a Form, I find it hard to come up with anything tangible. Using multiple independent windows (Forms) in an app: yes, I can see that (and I write apps that way); each Form can have its own Opacity value, for example. And, the programmer, with a small amount of effort, can implement docking of the independent Forms to their "main Form," or other Forms, etc.
Based on the belief that questioning one's technical assumptions (frequently) is a healthy thing to do, I'm curious to ask you, my peers, and betters, what you think about putting Forms inside Forms:
1. is it something you do yourself in your own practice (in situations you are not using MDI) ?
2. is it a very "bad thing" in terms of consuming resources (like memory) compared other possible containers ? Does it diminish performance ?
3. do you think it is a mistake for beginning programmers to use Forms inside Forms ?
all-ears, bill
[1] I've left MDI out of this discussion, even though CP is still getting questions on MDI: questions from people working with/on legacy apps; and, questions that I believe are coming from students who are assigned to create an MDI app in their classes. I go along with the view that MDI is outmoded, and read that MS has "deprecated" it. Bias: I find MDI apps butt-ugly.
Google CEO, Erich Schmidt: "I keep asking for a product called Serendipity. This product would have access to everything ever written or recorded, know everything the user ever worked on and saved to his or her personal hard drive, and know a whole lot about the user's tastes, friends and predilections." 2004, USA Today interview
|
|
|
|
|
I must say I have never placed a form inside another form and can see no reason to do so - none of the situations I have ever found myself in have needed this.
So it would be interesting to hear about its benefits, if there are any(I think it would just mess my head up trying to debug that sort to of scenario).
“That which can be asserted without evidence, can be dismissed without evidence.”
― Christopher Hitchens
|
|
|
|
|
I'm just a newbie to C#, but… I'm just starting to read about and understand some of, Polymorphism… Whatever methods you have in your main class, you could change them to virtual methods then by using inheritance… The methods in your child classes could use override.
Like I said, I'm just a newbie… But, just a thought.
|
|
|
|
|
- No, sounds like a bad idea.
- I would say yes it's a bad thing, but I have never tested it to see the effect on resources/performance.
- Certainly, they do enough bad things as it is.
Veni, vidi, abiit domum
|
|
|
|
|
BillWoodruff wrote: And, I believe the idea of using a TabControl to implement a multi-document work-space is a good one.
I believe that different users are attracted to different MDI implementations.
BillWoodruff wrote: A Form is a "heavy-weight" object; using "lighter-weight" objects.
Not by definition; an application is a Window, just like a button is a Window. One can set a new parent, and could choose to set the apps' parent to a button.
BillWoodruff wrote: If I consider what, if any, advantages there might be to using a Form within a Form, I find it hard to come up with anything tangible.
Encapsulation and re-use.
BillWoodruff wrote: is it something you do yourself in your own practice (in situations you are not using MDI) ?
I sometimes use a complete executable as described above; that's heavier than declaring a thread, but also robuster
BillWoodruff wrote: is it a very "bad thing" in terms of consuming resources (like memory) compared other possible containers ? Does it diminish performance ?
How much more resources does a Form use compared to a Panel? Yes, it costs performance, the question should be whether it's "expensive". If you're looking for optimal performance, then you should not be creating a window using a managed language.
BillWoodruff wrote: 3. do you think it is a mistake for beginning programmers to use Forms inside Forms ?
I think it's a mistake to make it a black-and-white decision, without any context. The only thing that's "always" wrong is to swallow exceptions.
BillWoodruff wrote: Bias: I find MDI apps butt-ugly.
..yes, most important thing about the car is the color - not whether it's an efficient design.
Bastard Programmer from Hell 
If you can't read my code, try converting it here[^]
|
|
|
|
|
Eddy Vluggen wrote: an application is a Window, just like a button is a Window.
I'm not sure what you meant to say. A Form is a ContainerControl, while a Button is a ButtonBase.
/ravi
|
|
|
|
|
On the WinAPI level, they're all just Windows.
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
|
|
|
|
|
Thanks, Eddy, I hoped someone would respond who would advocate the position that it's okay to put Forms in Forms, or, at least, okay in some circumstances.
I do not understand this statement: "One can set a new parent, and could choose to set the apps' parent to a button," but it's provocative in a fascinating way: would you care to give an example of why you would implement this, and how you would use this type of relationship ?
I also fail to see how using a Form within a Form inherently promotes "Encapsulation and re-use" in a way that a Form that is not contained in another Form does not.
I also believe, but have not verified through any formal analysis, that if you had an Application whose Main Form contained many other Forms, and the Opacity properties of the Main Form, and contained Forms, were different, that you could well have a significant performance hit depending on your memory, CPU, GPU, etc.
I adhere to William of Occam's idea (Occam's Razor, Latin: lex parsimoniae) that parsimony in design is a very good thing: why use a Form instead of a Panel or other ContainerControl unless using the Form provides some significant functionality the Panel does not ?
Using a Form within a Form in WinForms means you sacrifice the ability to do design-time layout of the Form's position in its containing Form.
Another thing a Form in a Form offers is ... if it has a TitleBar ... instant movability, but WinForms provides no "easy" way to constrain a contained Form's location in its Parent Form.
I look at an Application (in WinForms) as a "totality" that includes Objects that have Windows, Forms, UserControls, other Controls with UI's, etc., and other Objects that do not have Windows: Classes, Enumerations, Structs, Interfaces, etc.
While you are free to dismiss my bias against MDI architecture with the ad hominem argument that it's a "skin deep" point-of-view on my part, I assert that MDI architecture has the effect of diminished productivity compared to other multi-window management strategies, and I do not believe there's any inherent "efficiency" in MDI compared to managing multi-documents with a Tabbed UI (TDI).
It is interesting to review the current state of window management of many of the most widely used Applications: [^]. It's a "mixed-bag," as you might expect. But, a trend away from MDI seems apparent ... the "kicker" being that if you regard a tabbed multi-window management application as a form of MDI: well, then MDI is going strong.
I suspect one thing you and I could completely agree on would be the idea that one cannot make any absolute rule about application design
Google CEO, Erich Schmidt: "I keep asking for a product called Serendipity. This product would have access to everything ever written or recorded, know everything the user ever worked on and saved to his or her personal hard drive, and know a whole lot about the user's tastes, friends and predilections." 2004, USA Today interview
|
|
|
|
|
BillWoodruff wrote: "One can set a new parent, and could choose to set the apps' parent to a button,"
SetParent[^].
BillWoodruff wrote: give an example of why you would implement this, and how you would use this type of relationship ?
Most simple scenario would be to put MS Access Runtime (free version of Access) (or the Foxit PDF reader) in a Panel; nice reports, no extra code. Added bonus; no dependencies, making it easy for someone else to write a replacement.
BillWoodruff wrote: I also fail to see how using a Form within a Form inherently promotes "Encapsulation and re-use" in a way that a Form that is not contained in another Form does not.
It doesn't "promote" it. Given that you need to display a bunch of controls in two separate area's, one of them as a dialog; would you put it in a user-control and use a dedicated form to display that control? Isn't the UserControl overhead? And yes, as long as it's a SOLID control, it'd be possible to re-use the code. Both as a form and a control.
BillWoodruff wrote: Using a Form within a Form in WinForms means you sacrifice the ability to do design-time layout of the Form's position in its containing Form.
Yup, but it also means that I only see the controls for that form, and not all other crap.
BillWoodruff wrote: Another thing a Form in a Form offers is ... if it has a TitleBar ... instant movability, but WinForms provides no "easy" way to constrain a contained Form's location in its Parent Form.
Movability is usually disabled when the form is used as a control.
BillWoodruff wrote: he ad hominem argument that it's a "skin deep" point-of-view on my part, I assert that MDI architecture has the effect of diminished productivity compared to other multi-window management strategies, and I do not believe there's any inherent "efficiency" in MDI compared to managing multi-documents with a Tabbed UI (TDI).
It wasn't an attack on the person. What is your "belief" based on? It's more efficient than SDI for multiple documents in an XP-environment, where the taskbar-button can not yet be used to switch to the correct document. It saves space on the taskbar by limiting the open taskbarbuttons, and it'd be only logical to have multiple documents in a single application. That is, for anything but the people used to a phone-UI.
BillWoodruff wrote: the "kicker" being that if you regard a tabbed multi-window management application as a form of MDI: well, then MDI is going strong.
Well, it is a multiple document interface, even if the interface changed. Still, I prefer MDI in XP - think Microsoft Word.
BillWoodruff wrote: I suspect one thing you and I could completely agree on would be the idea that one cannot make any absolute rule about application design
Precisely; it pays more to be pragmatic than pedantic.
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
|
|
|
|
|
That's an excellent rebuttal ! +5
My one "instant quibble" is with your example of using 'SetParent: that changes the Parent of a Window; while it may, indeed, make another Application visible in the Window, it doesn't change the Application "host" that has created the Window.
If I use 'SetParent and its associated P/Invokes to display some other Application's window in my C# Application, essentially I have simply "loaned" one of my windowing areas to the other Application; or, you get fancier and say that the window is now a "viewport" into the other Application's window(s).
bill
Google CEO, Erich Schmidt: "I keep asking for a product called Serendipity. This product would have access to everything ever written or recorded, know everything the user ever worked on and saved to his or her personal hard drive, and know a whole lot about the user's tastes, friends and predilections." 2004, USA Today interview
|
|
|
|
|
Because a Form represents a top level window (that is usually identified by a unique entry in the task bar), it seems nonintuitive (IMHO) to put a Form within another Form.
An acceptable alternative is to use an MDIClient in a Form. The MDIClient can of course contain any number of Forms. This preserves the task bar entry association and allows the app to offer multiple peer windows within the top level window.
/ravi
|
|
|
|
|
Hi Ravi,
As is probably clear from my post, I don't like the idea of putting a Form in a Form, in general.
But, it's interesting to note that you can do it in WinForms only if:
You set the Form to-be-contained's 'TopLevel property to 'false before you add it to the ControlCollection of its to-be-container Form: if you didn't do this, you will not receive a compile-time error, but will receive a run-time error.
MS does provide the 'ShowInTaskBar property for Forms in WinForms to control whether or not a Form appears in the TaskBar, but even if its 'ShowInTaskBar property is set to 'true, a Form contained in another Form will not show in the TaskBar, appear in the TabOrder facility, etc.
So, we're free to make a mess
bill
Google CEO, Erich Schmidt: "I keep asking for a product called Serendipity. This product would have access to everything ever written or recorded, know everything the user ever worked on and saved to his or her personal hard drive, and know a whole lot about the user's tastes, friends and predilections." 2004, USA Today interview
|
|
|
|
|
Why not use a TabControl and open a new TabPage i.s.o. a new Form in a Form?
|
|
|
|
|
joost.versteegen wrote: Why not use a TabControl and open a new TabPage i.s.o. a new Form in a Form?
Hi, that's exactly how I feel ! I am strongly against using Forms within Forms except in very exceptional circumstances. I find an Application that uses a Tabbed UI to present multiple documents, or "workspaces," intuitive, natural to use.
For the case that you need floating palettes and other windows the user may want to move around, I always use UserControls.
I experiment with writing application prototypes that use multiple "independent" Forms as a form of research on UI design.
bill
Google CEO, Erich Schmidt: "I keep asking for a product called Serendipity. This product would have access to everything ever written or recorded, know everything the user ever worked on and saved to his or her personal hard drive, and know a whole lot about the user's tastes, friends and predilections." 2004, USA Today interview
|
|
|
|
|
|
I have two forms.
there is a button in the first form, when clicked will open up the second form.
Now what i want is that when i click the button on the first form again i want the second form to close.
i am aware of the code for opening a second form from the primary.
secondform.show();
but can any one help me in providing with the code for closing this second form???
the second form should close and the first form should stay open.
|
|
|
|
|
The simplest possible way to do this is:
private void btnVisibleControl_Click(object sender, EventArgs e)
{
secondForm.Visible = ! secondForm.Visible;
}But, what if the second Form shows a 'CloseBox, and the user closes it ? To guard against that you can define a FormClosing EventHandler in the second Form:
private void secondForm_FormClosing(object sender, FormClosingEventArgs e)
{
this.Hide();
e.Cancel = true;
}Note that 'secondForm will be closed when your first Form is closed automatically only if the 'secondForm was created and shown in your first Form's code. Automatic closing of Forms created in the "Main" Form's code, when the Main Form closes, is a standard behavior of the Windows Form programming model.
But, there's a better way, where all the code is put in the main Form:
private secondForm f2;
private string strClose = "Close Second Form";
private string strOpen = "Open Second Form";
private void FormTemplate_Load(object sender, EventArgs e)
{
f2 = new secondForm();
f2.FormClosing += f2_FormClosing;
btnVisibleControl.Text = strOpen;
}
private void f2_FormClosing(object sender, FormClosingEventArgs e)
{
f2.Hide();
btnVisibleControl.Text = strOpen;
e.Cancel = true;
}
private void button1_Click(object sender, EventArgs e)
{
if (f2.Visible)
{
btnVisibleControl.Text = strOpen;
}
else
{
btnVisibleControl.Text = strClose;
}
f2.Visible = ! f2.Visible;
}
Google CEO, Erich Schmidt: "I keep asking for a product called Serendipity. This product would have access to everything ever written or recorded, know everything the user ever worked on and saved to his or her personal hard drive, and know a whole lot about the user's tastes, friends and predilections." 2004, USA Today interview
modified 23-Oct-13 10:45am.
|
|
|
|
|
thanx for the reply...
secondform.close();
this code worked
|
|
|
|
|
I can not make a data connection to SQL Server 2012. Everything is located on my laptop. I am a beginner trying to learn C#. I can access the database via a dataset with no problem. I have tried both: using System.Data.SqlClient;
using MySql.Data.MySqlClient;
SQLServer Login = SINGER1990-PC\SQLEXPRESS
Laptop Admin = singer1990
Here is the code to populate a combo box
using System;
using System.Collections.Generic;
using System.ComponentModel;
using System.Data;
using System.Drawing;
using System.Linq;
using System.Text;
using System.Threading.Tasks;
using System.Windows.Forms;
using MySql.Data.MySqlClient;
using System.Data.SqlClient;
namespace Access
{
public partial class Form1 : Form
{
public Form1()
{
InitializeComponent();
}
private void Form1_Load(object sender, EventArgs e)
{
// TODO: This line of code loads data into the 'pOSNowDataSet.tblItem' table. You can move, or remove it, as needed.
this.tblItemTableAdapter.Fill(this.pOSNowDataSet.tblItem);
}
private void Form1_Load_1(object sender, EventArgs e)
{
}
private void button2_Click(object sender, EventArgs e)
{
//This still causes error because cannot get correct server name
SqlConnection cs = new SqlConnection("SERVER=singer1990-pc\\sqlexpress-PC;DATABASE=POSNow;Trusted_Connection=True");
SqlDataAdapter da = new SqlDataAdapter("Select * FROM tblItem", cs);
DataTable dt = new DataTable();
da.Fill(dt);
//for (int i = 0; i < dt.Rows.Count; i++)
{
// cboSelectName.Items.Add(dt.Rows[i]["itemSKU"]);
cboSelectName.Items.Add("itemSKU");
}
}
}
}
|
|
|
|
|
Quote: "SERVER=singer1990-pc\\sqlexpress-PC;DATABASE=POSNow;Trusted_Connection=True"
Shouldn't that be:
"SERVER=singer1990-pc\\sqlexpress;DATABASE=POSNow;Trusted_Connection=True;"
Notice the removal of the -pc on the end of SQLExpress...
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
