This is pure curiosity...
Most 'professionals' will likely never use "Form1" as a valid class name in their Windows Forms projects. I usually end up renaming it to MainForm.
What do you do?
Edit: For those of you that use hungarian notation (frmMain) - why? I don't think it would still be considered a standard practice... is it?
MainForm. I loathe Hungarian notation, and FxCop complains about it in any case, so MainForm, OkButton, AboutDialog, etc.
{AppName}Form.
frmMain is my typical choice.
Dennis. My form's name is Dennis.
frmMain for MDI applications. I don't bother changing it for single-form apps..
I prefer MainForm, not FormMain. Using Form as a prefix breaks alphabetical order!
I often use some variation of ApplicationShellForm.
This is because it's really, in most of my "real" work, nothing more than a thin shell where I inject the real behavior at runtime. My "main form" usually has very little in it, in and of itself.
That being said - I'd always call it something based on its behavior. What does your main form or application do? That's what would determine what I'd call it, if I wasn't building everything around dependency injection and trying to maintain some separation of concerns.
I usually name my main form to keep in line with the project. For instance, I'm (slowly) writing a small application that was intended to help manage peer reviews at my previous employer. My main form in this project was simply called ReviewManager.
Generally I rename it to frmMain, similar to statenjason. But if it has a different purpose, or is being used as a prototype that will get rolled into a larger project I will rename it to something more descriptive. So Form1 might become frmSomeComplexTest, or frmSomeMethodOutputTester.
I don't change it unless a different Form ends up being the main one. In which case, I'll rename that one Form1.
Form1, FormMain, it's essentially the same thing. It's not like your users will ever know/care, nor will it be confusing for someone maintaining your code.
If my program is named Fred, and its UI lives in a form, FredForm is what that form gets called. The moment there's more than one form, it gets promoted to FredMainForm, so long as it's actually still the centerpiece of the UI.
frmMain for single form apps, MDIMain for MDI apps. I name the project specific to the business purpose and let the business decide the form's text.
Related
I'm trying to implement Blackjack via Visual Studio, but have just been introduced to it. Suppose I have a PictureBox representing a card in a hand. This box starts with an image of a face-down card, representing a card slot that hasn't been dealt to yet. I have a function in my Form object that changes the PictureBox image to another card image resource based on an integer parameter. This is all pretty standard.
What I'm having trouble with is actually calling the method from main. I could create a new Form object and set the auto-generated one to invisible, but I'd rather work with the form that's auto-generated. Should I just put all the game logic in the Form1.cs file? Does the auto-generated form object have some default name I can use?
I realize this seems pretty novice level, but it seems like Microsoft's support documentation would prefer you create entire projects from the designer view and doesn't help much for actually coding.
The typical model for a simple Forms program is to allow the Main() method in Program.cs to remain in its default form: set some things up, create an instance of your primary Form subclass (the class name by default will be Form1), and pass that to the Application.Run() method.
It is good design to have a "controller" object outside of the UI object. But especially if you are starting out, you may well find it simpler and easier to understand if that "controller" logic is also in your primary Form subclass.
In that case, yes…all of the code winds up in the one .cs file, and indeed in the one object.
Even with the controller logic in the Form object, you will still find it useful to keep the code that is essentially controller logic separate from that which is user-interface logic, and to use the C# #region directive to label these sections of code. That will help you keep a mental model that still separates the two roles within the same class.
Beyond this, there are lots of differing opinions, from the complete "shoot-from-the-hip" approach, to the extremely strict and rigorous adherence to specific design patterns. But the above is consistent with the pattern that the Visual Designer leads you to, and so is a fine place for beginners to start.
In the WindowsForms what is the better way to initalize components:
in the properties window?
or in the code (in constructor)?
If I make it in the properties window, then I often have a situation, when I'm changing the value in the code and then closing the form. When I open it again, I'm getting old value (which I've written in properties) and it can confuse.
What is the differences between these two ways? Didn't found it in google.
It's equivalent.
When you change values using the properties window, that values are saved in the resx file. Then the method InitializeComponents(), that is written by the WinForms designed in the Form's constructor, performs the form initialization.
If you do it manually in the constructor, you must place your initialization code, after InitializeComponent() method, then, the form will be initialized with your values.
What method is better? In my opinion, both method are equivalent. You can choose the way you prefer. But my recommendation is not mix them. Use pure Winforms designer or pure code initialization.
We are using usercontrols in c# to have separate classes for features inside a tabm which works perfectly.
Our problem arises, when an usercontrol uses a Service Reference to any Webservice.
The first time dragging the control on the form works. The second time, the designer will show an error:
Could not find default endpoint element that references contract 'testSR.WebService' in the ServiceModel client configuration section. This might be because no configuration file was found for your application, or because no endpoint element matching this contract could be found in the client element.
The app.config contains the correct endpoint and it works as long as the calling code is inside the form itself, as soon as we move the code to the usercontrol, we have these problems.
I even tried to put the user control inside another project within the solution referenced it correctly and copied the endpoint/binding configurations from the app.config of the DLL to the EXEs app.config - then also the problem arises again...
It seems that user controls cannot reference webservices, but there should be a solution!?
EDIT: From my testing it now seems that user controls can use service references, but the VisualStudio Designer will only work for the first time, after that the programm still works, but the designer shows the error and when I ignore it, the designer removes the user control from the form. As long as I do not touch the containing form, the usercontrol is editable and working fine ...
I assume you are working with winforms. have a clear separation between UI and WCF and avoid this and other issues by making the usercontrol not to call wcf directly but call an intermediate class library which calls the service layer for you. In this way the WCF will be called by such class library and your UI will be isolated.
Actually thinking about this problem you are describing, are you requiring WCF connectivity at design time as well? if so you shoul probably avoid it by checking if running at design time in which case do nothing. removing the dependency and having your UI independent from Service References is anyway surely a good idea.
Only four years late, but I actually found a fix to the WCF issue when instantiating the service in the usercontrol.
As #DavidePiras stated, make a service class library and reference the binary .dll. (Call the .dll, Worker in this case for my answer)
In your user control, rather than instantiating the Worker class in the constructor, make a new method, call it LoadWorker in this case.
..
private Worker worker;
public CustomUserControl()
{
InitializeComponent();
}
public void LoadWorker()
{
worker = new Worker();
}
--
In your form where you are calling this userControl, but can't see it, then either in another method or in the constructor for the form, call usercontrol.LoadWorker().
--
public MyForm()
{
InitializeComponent()
customUserControl.LoadWorker();
}
An extra step I took from here was to close all open windows/files and do a Build Solution. Then reopen the form that the designer was failing on and it should be good to go.
Cause?
The form that worked at runtime versus what you saw in the designer window in VS20xx has to deal with what is instantiated at the runtime versus what occurs when the designer window is loading your user control. I don't know the fine details or the terminology to necessarily describe it, but that is what is causing it. I have found that throwing the loading of the WCF service into a separate method to be the easiest solution.
I hope it helps anyone else who runs by this answer now.
In C#, using winforms, what is the best way to make forms talk to each other? Sending data, messages, strings, whatever, from on to the other?
Delegates?
Ideas?
We'ved used something called the Event Pattern successfully in several Winform applications. Here's a good link that will help you get started.
You can create events in one form and then register for those events in the other form. You can also simply access properties from one form to the other. For example maybe in the constructor of the second form, you would pass a variable for the first form.
It sounds like what you're looking for are events though. When some event happens any delegate that is registered will be called.
There is a tutorial on MSDN for events here.
all depends on what you want to communicate.
Let's say it is configuration data; You could create a static property on main form called Settings, which would expose your object. Than all forms would see that same Settings instance, and all would see any changes.
for extra credit you could implement INotifyPropertyChanged, and have it trigger an event. that way all forms looking at Settings would be notified if anything changed.
I have a windows form app written in C#. the main_form class instantiates an AccessProcess named AccessProcessWorker which is a class that inherits from BackgroundWorker, then main_form then initializes Process with the following code
AccessProcessWorker.DoWork += new DoWorkEventHandler(processWorker.worker_DoWork);
AccessProcessWorker.RunWorkerCompleted += new RunWorkerCompletedEventHandler(processWorkerCompleted);
AccessProcessWorker.ProgressChanged += new ProgressChangedEventHandler(processProgressChanged);
this application has just gone from POC to "make it work fast".
I wrote this app to work against an Access database but now want to make it go against MS Sql, but leave the option to work against access also. So, I could do something ugly like instantiate and initialize a SqlProcessWorker or AccessProcessWorker based on some UI selection made by the user. But what I'd like to do is make it so main_form always creates something like an IProcess so I didn't have to add logic to main_form every time there is a new ProcessWorker. The problem in my design is that the initializing breaks when I do it the way I described.
If anyone has any ideas, or need further clairification please let me know.
What you look for is called "dependency injection".
At some point you will need to instantiate the correct type, but The Factory Pattern is usually to the goto here. Now, that may be a bit much if you will only ever have one of two types to 'new' in order to get your IProcess object.
In the interests of keeping it simple, I would actually just go with the "ugly" approach.
You've mentioned Access and SQL Server as the two current databases, but how many do you realistically believe your app is needing to support? In my experience an application's database platform is very rarely changed and not without serious thought.
If there were a large set of database platforms to support and you can't predict which in advance, then maybe a decoupled design would be useful. Otherwise KISS.
If both of the database are the same layout and structure, you can just use EntitySpaces and change the default connection of the application. I.e. you have one code base when it comes to data access and then you just set the current connection based on whether you want the Access or SQL Database.
I would wrap the "ugly" bits of code in a separate method, or preferably a class which takes care of choosing which DB to talk to and the synchronization with the actual BackgroundWorker instances. The important point here is to adhere to the DRY principle: Don't Repeat Yourself.
I think that for a work project, you should do it as fast as possible, without thinking of future databases, because it's probably not gonna happen.
Are you sure there's not, somewhere, a class which already works with both Sql Server and MS Access? For example, OleDbConnection, OleDbCommand?
For simple SQL, all you need is to change the connection string and you can work with both databases.
If you haven't coded the rest of the application yet, you should take a day or two to look for some frameworks, compare and choose one of your liking. It'll make you write less code, and in future apps you'll be spared most of the database plumbery code. I guarantee that the time invested will be returned to you manyfold (if you work with databases once in a while, that is).