Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question
For example I have a method in the Booking class that updates a dataGridView control in the BookingForm.
Booking booking = new Booking();
booking.getBookings(dataGridViewBooking);
Similarly:
booking.getTables(comboBoxTables);
Is it bad practise to use controls as parameters? I have changed all the textBox parameters to strings and passed textBox.Text but how would something similar be done with other controls or are there any better ways to do this?
You can pass controls as parameters. They are normal objects that can be passed around.
It's questionable to pass UI objects to some kind of business logic, though. The business logic is not supposed to know anything about the UI.
Also, if you have the option of passing textBox.Text instead that simplifies the logic of that method. Probably, that method should not concern itself with extracting data from the UI. The SRP applies.
Usually you try to detangle the control from the data. i suggest you read up on BindingList . Create an intermediate record class that has all the fields you want to display, each field is one Property. Then create a. BindingList of that type and assign it to the DataSource of your grid.
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 1 year ago.
Improve this question
I am new to unity ( <200 hours) and I don't know what the proper practice is regarding when to create a new script vs. modify an old one.
For example:
My UI elements all share a script which has booleans for 'isSlider' and 'isButton', etc.
This toggle is used to activate or deactivate unique functions depending on the type of UI element while reusing some generic functions used across all of them.
Would it be better practice to create a new script for each UI element and just copy the generic code or is it okay to have toggleable functions to modify the functionality in the inspector.
Thanks for your help!
in OOP, you want to abstract functionality, rather than put it all under the same class
Look at the principle of single responsability: https://en.wikipedia.org/wiki/Single-responsibility_principle
it states that each class should be responsible for a single unit of functionality, therefore buttons and sliders should be different classes
if you have some generic it would make sense to share between all components, you can make your ui elements inherit of a parent class that handles that logic, for that, look at the concept of abstraction: https://www.guru99.com/java-data-abstraction.html
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
Is it common to store "non-model" classes (maybe helper classes) that I don't wanna use in a ViewModel inside Model directory in MVVM project?
For example:
Models\SongModel
Models\ID3TagReader
ViewModels\SongViewModel
If no, how should I encapsulate these classes?
In this design, the views know of the ViewModel and bind to its data, to be able to reflect any changes in it. The ViewModel has no reference to the views—it holds only a reference to the model.
For the views, the ViewModel acts both as a façade to the model, but also as a way to share state between views (selectedContacts in the example). In addition, the ViewModel often exposes commands that the views can bind to and trigger.
refer to the link..
http://blogs.msdn.com/b/ivo_manolov/archive/2012/03/17/10284665.aspx
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
I have created a wizard using the winforms tab control (hiding the tabs and using "previous" and "next" buttons). Each page of the wizard is a separate user control, but they all update a common object. I need the ability to move forward or backward and persist the data at each step, even skipping steps if they are optional.
I'm tempted to create a "global" object for the wizard that all user controls can access, but I'm certain that is not a best practice. What is the best approach for this scenario?
Since your modified Tab control resides on a form, simply make the "data" object as a member of the form class.
That way you'll have access to it from anywhere within the form, thus you can pass a reference to it to the custom UserControls whenever you navigate the wizard.
Cheers
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
Assuming I was writing my own version of .Net :)
What would be the downside of such a setup?
Yes, I am talking about a new anti-pattern here to avoid creating endless tuples and EventArgs. I think such a setup would have made coding a lot cleaner.
No. The Tag property has history, it was important in VB6 and Winforms was meant to replace it. It needed to be added to make porting code relatively simple.
It is entirely unnecessary in .NET. It supports implementation inheritance, a feature that VB6 didn't have. So if you want to add extra properties then you just derive a class and add them. And you'll be able to give them a good name and a type so you don't have to cast every time you read the property. This works just as well with Winforms controls.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 9 years ago.
Improve this question
So I'm having trobule figuring out the best way to use the MVVM pattern while creating a WPF control dynamically within
my code. Would this even make sense or is it better to avoid the MVVM pattern all together?
If it does make sense then please share code examples of the view model.
In general, if you're using MVVM, controls will only be created "dynamically" in response to the data changing. If you have an ItemsControl bound to a collection, for example, the controls to represent the items will automatically be created for you.
If you're talking about making a custom control in general, custom controls are really "pure view", so MVVM doens't really make sense in this scenario. The main goal of creating a custom control is to build it in a way so that it can be used by code developed with MVVM, which typically means building the control with proper Dependency Properties (so data binding works properly), etc.