should I send win form control as parameter? - c#

A winform forms.cs contains a gridview. This gridview(many columns) get populated with an xml elements and its attributes.
Another class "XMLReader.cs" that reads XML file and returns
List <someclassObjects>
Now I am sending gridview as a parameter from form.cs to another class "UpdateAppUI.cs" that receives the Gridview as parameter and update it.
Question is: Is there any issues with passing controls as parameter? Experienced professionals said donnnn't pass controls.
Then How I can access form controls to other classes?
What is the solution for above situation?

why you want to pass the grid view?
If simply you want to update it in UpdateAppUI.cs file then pass the datafrom gridview in the datatable. And from datatable you can update the database from the class.
No need to pass the control.
If you really want to pass the datagrid then create new object of datagrid as same as yours and pass that as an parameter.

I think that what those developers are refering to is: avoid making your UI unrepsonsive. You might want to look at your design ( read: conceptual model / design diagram ) before your deside how to implement this functionality.
There's an article on MSDN covering "Give .NET Apps a Fast and Responsive UI with Multiple Threads".
Consider this, if you have a Parent form that needs to update its child controls you might want to make the whole form accessable by the "update helper". But then again, try not to make to much heavy lifting on the UI Thread.
Also remember that your controls are Objects and when Objects are passed as parameters they are sent as reference types so another "danger" is that your method might do something malicious to your control.
To make the design understandable and manageable by others as well, I would step back one step and think about the design of your software.

Related

Creating dynamic UI in ASP.NET web forms

I need to create a survey page with the following structure read from database.
Survey QuestionA
a) Answer1 [Radio button]
b) Answer2 [Radio button]
c) Answer3 [Radio button]
d) Answer4 [Radio button]
repeats..
The page has many questions that needs to be dynamically added. I need to store the result of the form on in an array of Question object on submit.
One way I know to do this is create dynamic UI in a table and get the values by FindControl.
Is there a better (elegant) way to do this?
In ASP.Net MVC it handles the dirty work for you with default model binders. Of course you can also create your own. Though this does not give you the automatic solution you were hoping for in ASP.Net Web Forms, my preference in this situation would be to follow a similar common pattern that ASP.Net MVC is using for it's naming convention thus simplifying it. You could then start writing code that could be reused over time. Here is a link to an article explaining the naming convention on Haack's blog
http://haacked.com/archive/2008/10/23/model-binding-to-a-list.aspx.
Long term recommendation is to come to ASP.Net MVC, life is just better here :)
I suggest create a userconrol that implement a question(label) and answers(radio buttons) and each controls(labels,radios) is binded to a property of your usercontrol, Then you can read questions from database and for each data create this usercontrol object and set correspond data to that property of usercontrol, And to read data from control this state doing vice versa.
Albeit you must recreate usercontrols in each post back and set default data to those.
Also you can create multiple usercontrols with different UI that inherit a interface such as IQuestion, and a factory class that create each of usercontrols depend of environment varibles.
You can use jQuery to get the selected radio buttons by the checked property and append them with the question number.
e.g. for question 1 you have
So you can get the values iterating throught the radio buttons like so:
$("input[type='radio']").checked
You could always add the controls in programmatically.
Say you have a aspnet Panel control you can perform...
RadioButton rb = new RadioButton();
rb.ID = "rbRadioButton";
rb.Name = "rbRadioButton";
rb.cssClass = "radioClass";
Panel1.Controls.Add(rb);
Excuse the harshness of the example, not got visual studio to hand at the moment to check it but I hope you get the idea. You could in essence build up the whole question this way based purely on the database. The downside is getting the values as you have to override the Render method (if I remember right, it has been a while, I do have an example if you want me to find it).
I admit it is a little overkill but it is a possible solution.
use radiobuttonlist (which you can see in the the toolbox ,it is a asp.net standard control) control for this purpose. It is up to your needs.

Not sure on class design

i originally had a main form with 2 panels, one had a graph in that i clicked on the other had the results displayed related to what you clicked.
All this code was dumped in the main form.
I tried to be a smart alec and use inheritance, so now i have a main form which has a graph objet and i have a superclass graph -> subclass specific graph heirarchy
however now when the graph is displayed in the main form, how do i get the data back to display in the other panel? The reason i ask this is now that the graph stuff is in its own heirarchy, it has no knowledge of the panel on the main form so i have no hwere to set the data when it is set
i hope someone can help
thanks
edit: i think i might just pass the control collection for the panel in to my graph class so i can add the relevant items in there
Depending on the relation between the two forms, you can use events to message data between them.
A click event handeled in the graph can raise an event with the data you need to display, which would end up on the owning form. Depending on the relationship, you either call a function on the 2nd form to display the data, or raise an event to which the 2nd form subscribed to send over the data.
[Edit]
I read Forms instead of Panels.
The main idea remains the same though. From your style of writing, it looks like you have an Objective C history. I know on the Mac, these things would be done in Interface Builder, setting bindings to make this stuff happen, but in the .NET Winforms you do these things in code (handeling events, calling methods, etc). If you like to stick more to the way it's done with Interface Builder, you might want to take a look at WPF applications; bindings work in a very similar way to how it's done on the Mac.
I would design this as an object that aggregates another object. Have a look at the way master-detail view works.

WinForms data binding with a Save button?

How is data binding in C# WinForms supposed to work when you have a Save button? I don't want the data updated until I press Save!
I have two forms (list and detail) backed by a BindingList<T> collection and my custom object from that collection, respectively. I can bind each form to the list or object appropriately. However, any changes made in the detail form are immediately reflected in the list form - I don't want to save the changes and update the details shown in the list until the Save button is pressed.
Is data binding designed to support this? Is there a common pattern for doing so?
Whichever way I look at it, binding doesn't seem to be able to support this scenario. I've considered the following:
Pass a clone of the object to the detail form, but then I have to reconcile the changes on Save - changes may have been made to the copy in the list in the meantime.
Implementing IEditableObject and calling EndEdit on save almost works as I can prevent the list being notified of the changes made until Save is pressed, but if something else causes a refresh the list is updated with the interim data.
I'm currently left with dispensing with data binding in my detail view, and doing it all manually. Which is rather annoying.
Data binding really wasn't designed for this kind of thing, unfortunately.
The best solution we've found here is to edit object clones, then reconcile the changes, as you mentioned. You may want to come up with a custom collection and/or object interface that helps you manage this type of thing.
Even if the cloning method is slightly more work up front, it's going to be wayyyy less complicated and frustrating than using IEditableObject trying to catch all the possible events that update the data. Not only that, it's a more straightforward approach, and you won't end up with spaghetti code.
If you are set on using a binding list, your best bet would be to implement IBindingList to create the functionality that you desire. It may also be possible to pull this off by simply inheriting from BindingList and overriding the appropriate methods to change the binding list's behavior.
http://msdn.microsoft.com/en-us/library/system.componentmodel.ibindinglist.aspx
If you are not set on using a binding list, it is probably best to do the data manipulations manually based off of the control's events.
Best of luck.

How to catch user changes in databound controls?

I have application full of various controls databound to my classes. I would like to ask user "You are closing application and you made some changes. Do you want to save your changes?". For this I need to recognize that user made any changes.
How to catch user made changes in databound controls? Is textBoxXXX_TextChanged the only way to do this?
Thanks in advance for all your answers.
It depends on the datasource; for example DataTable and DataSet sources contain the GetChanges() methods which allow you to easily see if rows have been added/removed/modified. Other data sources will have their own implementations, if any. If there is no implementation then it's up to you to determine how to check for those changes.
In any event this is something you should do at the data-level, not the UI (by watching for "changed" events). Watching events doesn't scale beyond a couple controls and maintenance can be iffy.
Update: Not sure why I didn't think of it, but a second option is to add a BindingSource to your UI object and use it as a databinding proxy (your UI controls databind to the BindingSource and the BindingSource binds to the real datasource). It provides a better approach than handling all your individual "Control_Changed" events, and requiring rework of your other layers (esp. if they aren't custom data-types).
You need to provide custom logic for that, there's not really an automatic way of doing this. As I see it there are several options:
At the start of the editing, save a copy of the original data object, and when you need to check, compare the current object with the saved one. The comparison can be custom (field by field) or semi-automatic by use of serialization (compare the serialized forms) - if it is serializable.
In each of your data object's property set accessors, test for a change in value and mark the object as 'dirty'.
As been discussed, there are many ways to do this depending on how granular you want to get.
A relatively easy way using client side javascript would be to do something like the following:
Hook into the onchange events of the form elements. You could do this dynamically on page load using javascript/DOM.
When the onchange error handler is called, you could set a page level variable: pageHasChanged = true;
Hook into the page's beforeonunload event (occurs when the user tries to navigate away from the page) and check the pageHasChanged variable to see if any changes were made. If changes were made you could alert the user.
This doesn't give you the detail of what changed, but would be fairly easy to modify to track which form elements changed.

Advice on patterns/design

I could use some advice/help on a piece of software I've developed.
The application is a wizard style app where users fill out fields on each form before choosing to go to the next form or back to the previous. Fairly simple.
Right now the menu calls frmWiz1(InitialData) and when frmWiz1 returns with DialogResult.OK the menu will call frmWiz2(frmWiz1.Data) (not exactly, it stores all of the Data from each form, and passes those references in to the next form). Each data object inherts from an IPrintable interface that defines methods for printing itself, so at the last page in the wizard (print preview/sign), it adds each Data object to a custom PrintDocument object that just iterates through the data objects, calling their print functions and manages pagination etc.
Initially I thought this was a good idea but now I'm thinking that:
- The menu form is handling too much flow logic.
- The Data objects (which handle all of the business logic that applies to their particular set of data) should be decoupled from print logic (cause as they are now, they're in the printing namespace - maybe just a relocation will set my mind at ease).
I don't know. I'm decent with the language, but I'm still a rookie at design.
Screw "frm" prefixes!
With respect to the overall flow of the application, I would recommend using Application Controller or something of the kind in order to centralize the logic.
As far as the UI goes, each Wizard stage should be a separate User Control (with no "Cancel", "Finish", "Next" or whatever buttons) wich is placed on the root form with the aforementioned buttons.
No object should be responsible for printing itself - use IPrinterService for doing that.
Just a few general thoughs:
This is a great Wizard control. We use it here at work, and I must say this guy did a real good job with it. Not sure if it can be useful to you, but check it out
Figure out exactly what you need to know about an object in order to print it. Try to come up with methods and/or events that you would need an object to have in order to be "printable". Put those into an interface, and have your business objects implement that interface. Then, have your printing helper class deal strictly with interfaces.

Categories