This is more of a theory based question. I am working on the design for my final project in C#, which is to create Jeopardy. My question is, what would be the best way to pass data between them? For instance, the rubric requires the game opens with an options screen after the splash shows. Here, they will select the number of players and their names. I know that in my gameform load event, I can just specify those things as parameters and pass them as arguments from the optionsform. This seems messy though, is there a more efficient way to create project wide variables that I could reference no matter the form I am currently using?
Thanks for any answers, it's always appreciated!
-- Young Padawan Coder
How about creating a separate business object (i.e. class) with either static properties or singleton pattern. You would then store all your application values there and you can refer to them from anywhere in your application without the messy work of passing around variables all over the place.
Related
I have two different WPF projects. The first one should start a new instance of the main window of the second project.
The class of project one, which should initiate the main window, is a VM in the MVVM pattern and provides useful information for the second project.
Based on the information the behavior of the second project changes. Let's say I have to transfer 10 variables and there are 5 different behaviors of the project, which are determined by those variables.
The requirement is to instantiate the main window with only one constructor.
It would be pretty bad if I had only one constructor with 10 variables and 5 if statements for every possible behavior.
What is the accepted way to handle such a problem?
I am unsure in what way you're instantiating the second window while passing these arguments to a constructor, but when you want to pass a lot of information between objects, I'd suggest wrapping your parameters into a class or struct that both projects recognize. This way, you're only passing one parameter as opposed to 10 or more.
This way, regardless of whether you're reading these parameters from a file or passing them from the first application as arguments, the constructor will only require that one parameter.
I studied in programming and graduated in 1998... yeah i'm old LOL Long story made short, I never worked in that field, but decided to get back to it to make myself a membership management program.
There is one thing I can't recall about object oriented programming and I'd need help if someone could please clarify a few things for me.
I have a program I'm working on that has a main Windows Form calling on different other forms to perform different actions on a database containing information about a sports center that I own.
After a while working on the project, I realized that a few methods I'm using in my different child forms are exactly the same. For example, if the user enters a first and last name, i often have to find what's the memberID. I just copied the code to fasten the process.... BUT !
I DO remember my teachers kept saying:
"If you need something to be accessed by many, then why should it
belong to someone?"
and I know it's not a good way to program.
My question is: How do I work that correctly? Should I put my method in the main parent form and call it from the others? Is that the right way to do it? Do I just need to use a class containing these methods and then I can call them from anywhere in the app? I'm confused.
Thank you for your time and help.
To solve these kind of issues we have some options:
1. Helper Class: Create Helper class. Make it public, this class will be available for all forms. Now you can use methods of this class in all forms.
2. Static class: Create a static class with static properties. by using this you can access use this property value any where throughout application. Main advantage of this you don't need to hit database again and again to get same record.
Hope this will help you.
After spending the last two years as a C#/WPF/MVVM developer, I recently took over a VB/Winform project at a new company.
I've successfully converted the project to C#. I've been doing a large amount of research, trying to figure out the best methods for this project, but I'm trying to figure out exactly how much refactoring and re-configuring to do.
My issue is this: the previous developer created two huge static classes. There are 30+ forms that are used for a variety of tasks. Each form is called from an event driven by a button click on a "main menu" type of screen. When the program initializes, a function from one of these mega-classes is called that instantiates EVERY form. There are also an incredible number of statics and constants.
I've broken the constants out and created a specific class for them. I'm piecing apart the mega-classes into smaller, more manageable (and responsibility specific) classes, but I've got this incredibly large initialization function that instantiates all of these forms.
Thus, my questions (finally) are these: Is what I wrote above a resource nightmare? Or, is this some sort of normal VB/Winform design pattern that I should keep? Should I re-write this so that each form/class is instantiated when the button calling that form is clicked, so it can disposed of when closed?
Thank you for any direction you can give me. If I can provide more information to make this more specific, please comment and I will edit.
Is what I wrote above a resource nightmare?
Yes
Or, is this some sort of normal VB/Winform design pattern that I should keep?
Absolutely not. The design of the system is pretty much identical in VB and C#. With some very minor exceptions the difference between the languages is just syntax.
Should I re-write this so that each form/class is instantiated when the button calling that form is clicked, so it can disposed of when closed?
Yes in theory. The forms should operate just as they would if you were writing in C#. Of course if the original dev liked global state so much there could be all sorts of state lurking between one appearance of the form and the next.
There are a few features of VB that can lead weaker devs astray. The presence of the Module (essentially a static class, but sometimes more convenient) can lure some people into adding much more global state than they should. Also in VB, it automatically creates as needed a single, global instance of each form with the same name as the class. This can cause devs to confuse the form as a class and object - leading to the single instance of a form, rather than constructing and disposing as needed.
I'm making a project to get myself more familiar with Windows Forms and Graphic User Interfaces.
I have created this program for the Department of Motor Vehicles that uses polymorphism in CONSOLE. So when I input a taxi, it will call the base class of an industrial vehicle rather than a personal vehicle.
The program works fine in console.
But I'm wondering if that's implementable through a Graphical Interface. I know I can just have buttons with the types of vehicles, then have a new form open up to input that data for that specific type of vehicle. But that wouldn't be polymorphism....
Is this a type of project that could be done with polymorphism? and GUI's or no?
I think you would get more bang for the buck if only one form was created which handled the base class as mentioned. But it would turn on/off or make visible items as required by the derived classes. The GUI doesn't have to be polymorphic, it just needs to handle the polymorphism of the data. HTH
You'll have to be more specific about what you want to achieve. Polymorphism can be applied to most problems, if you like. Whether or not it's a good technique varies, and depends very much on how you use it. You seem to be forming ideas about how your object hierarchy will work early on, whereas I would suggest that you don't start there - instead specify what your application should do and how it should do it, and design your object model around that. It may turn out that your idea of how to represent (given your example) a taxi actually isn't useful.
There is no reason why you can't benefit from polymorphism in any object-oriented application, regardless of what user interface you elect to use. In your scenario, it may make sense to use only references to the base class in your list view, and then open up the appropriate details view suited to the specific type of the object.
Also, I recommend WPF for what it's worth. There's no use learning Windows Forms now unless you have a very good reason.
Perhaps what you are looking for is a way to dynamically build your GUI according to the type of (polymorphic) object you are passing? This can be done by using reflection, asking the object passed to the Form which attributes or properties it has and generate automatically input fields, text boxes etc. for each attribute.
For some examples, read this SO post:
Dynamic options dialog (using reflection)
What are the best way to store variables in a silverlight application?
Need to transfer store a customer ID throught the application but im not sure what is the best way
Disclaimer: This is a purely subjective answer. Others might object or have better suggestions.
I work mostly in VB.NET and over there, we've got the My.Application namespace where we can keep global variables. VB.NET users also have the option of using a Module for such purposes.
A Module, if I remember right, is equivalent to a static sealed class in C# so you can essentially do something of that sort.
To replicate VB.NET's functionality when I work in C#, I create a static class, with access level set to internal so its members are accessible from within the entire application.
Thus, when I assign a value to a member of the static class, it is accessible from all other classes in the application.
Hope this helps
Store the variable in a place where those things that need to get to it, can; and those things that don't need to get to it, can't. Can't say anything more specific without more information.
If you were following an MVVM pattern then I would have said as a property of the Customer model, with an instance of the customer model being accessed via the ViewModel.
Even if you aren't I would say within the application code and use binding where its needed in the UI. Otherwise you run the risk of changes to your UI causing the loss of customer ID storage at somepoint in the future.
If needed in more than one place then just create a repository that stores all of your data and have that accessed as needed (this way you can decouple your UIs from each other even if they use the same data source.
You may look at using InitParams, without knowing the situation I can't say much more.
http://msdn.microsoft.com/en-us/library/cc838255(VS.95).aspx