Passing data from a handler to another. very basic issue about OOP - c#

This may be a really basic question to experienced programmers but I started on VB6, and now I'm trying to accomplish same stuff on C# which is object oriented.
Suppose I have a class with a method to add two numbers on textboxes and I run that in the click handler of a button (Doesn't matter if it is static or not), then I have the result and I display it on the screen (maybe in another textbox), the user click another button, how do I recover the result on the other button handler?, what's the best practice?, I know I can read the result on the textbox, but if the result was displayed on a Messagebox.Show or in console?.
What's the best practice to save results instead of using helper textboxes or global variables?
On VB6 I use invisible textboxes, so my forms looks really messy, but thats the way to there.
Using C# + XAML + WPF

Usually that is what a model is for. It is the data-state of what is shown (and more, as some information may not be displayed at all times or just used as utility). The view often has a reference to the model which you then can access in the handlers and manipulate.
I'd suggest reading up on design patterns like Model-View-Controller and for WPF specifially Model-View-ViewModel.
Also, WPF has a few powerful mechanics like data binding, which makes synchronizing your data with the view a lot easier, do not treat your view as a model.

Related

C# WPF multiple windows

probably a beginner question,
I develop in c # wpf a graphical application with different windows, if I now open a new window with button and there, for example, capture a customer, then how can the other window still remain interactible with the open table?
or how can I run a function in another window that is supposed to update a DataGrid of another window (other .xaml file)?
Because neither window should actually control the access or view of the underlying data, they both interact with it via a intermediary class/object.
For WPF this pattern is commonly MVVM: Model, View, ViewModel. Your WPF Windows/Forms are the Views, and the data interaction will be in the ViewModel and Model.
I've not had to learn this in a while, but LearnMVVM looks to be reasonable starting point.
I suggest you Implement a ViewModel (if youre lazy there is MVVM Lite) with public or internal access mods. Then call the specified method to update the ViewModel.
You can pass a reference from your 2nd Window to your MainWindow by passing it though the constructor if you, for some reason, cant use static constructs.
What are you looking for is MVVM-Design Pattern (or MVC):
Model − It simply holds the data and has nothing to do with any of the business logic.
ViewModel − It acts as the link/connection between the Model and View and makes stuff look pretty.
View − It simply holds the formatted data and essentially delegates everything to the Model.
Wikipedia: MVVM
Tutorialpoint: MVVM-tutorial

How can i make global textbox?

I work with a lot of page. I calculate some variable other pages and i want write the result other page. How can i make this?
I tried make static textbox but it did not work.
I can make the static variables but i want to static textbox. I want to access to textbox for every page.
A possible solution is to use a utility like MVVM light that implements a messenger service. Every page that needs to change to the textbox can send a message with the new contents and the page with the textbox can subscribe to those messages.
It seems like you're coupling data and pages much too tightly. In general your views and your data should be completely separated. If you do your data calculations in totally separate classes it is usually easier to get that data wherever you need it. If you're not using the MVVM pattern you should consider it.

The best practice to implement custom\user control in WPF

I have a list of custom controls that should look something like this
Before I start to implement them through a custom or user control in WPF (via MVVM), I want to ask if I do everything right. I create a DataTemplate and binding properties I need (these are the numeric values (0.13) in columns) and ItemTemplat'ing it to listview or listbox. Also I'm having an observable collection of viewmodels for these templates and every viewmodel sends some specific numeric data through short intervals from slave device. Also I need this green element to be clicked (just to add a button to a template I guess) and having displayed an additonal window with real time plots. So my question is: Is this the right approach I'm talking about or do I have something wrong? I'm quite new to WPF, so please excuse me. I dont think that it is a great challenge to implement something like this.
I'm rather new to this model as well, however one thing I have found that has helped me with managing multiple View Models has been an IOC Locator. An example can be found here:
http://dotnetpattern.com/mvvm-light-toolkit-example

What is the correct way to pass controls around?

I am creating a new winforms application that will have datagridviews which will load matrix data, and I want the user to be able to do a bunch of operations on the data, like showing/hiding columns, editing cell values, and filtering too.
I thought of using the MVP pattern (Model, View, Presenter).
I wanted to create a presenter class, which would handle all the logic (meaning any events that the user triggers), eventually end up in the presenter which will work on the raw data (the matrices). This seems logical up to now but my question is what do I do if I want to pass the controls themselves (like the datagridviews)? Should these controls be sent the presenter class or is that bad design?
Perhaps it's better to find ways to only modify the raw data and then update my datagridviews?
It is not a good idea to pass around controls. If you're going to use a pattern such as "MVP", then you should have the "model" contain the representation of the "view". In this case if there are various details pertaining to a set of data it belongs in the model. Then you pass the model around.
Perhaps it's better to find ways to only modify the raw data and then update my datagridviews?
So, to answer this question, "yes". Use the model to wrap the data and pass it around.
Update
Specifically, with WinForms controls belong to containers, being that they are reference types and have lots of exposed events you run a HUGE risk of passing a reference from one Form to another Form. Now, imagine that the first Form is done being used and closes and disposes, it kills the reference to the control and attempts to unwire events. Do you see where I'm going with this? It quickly becomes a nightmare trying to correctly cleanup references, and un wire event handler and since controls belong to one container by design it breaks that paradigm.
It's better to have a separation of concerns. If you need a view to have certain data, it's always best to pass around the data itself...

How to a implement ListBox ScrollIntoView functionality in a ViewModel

I have a screen with a TextBox in which the user can type a 2-character state code. Below the TextBox is a ListBox containing all 50 state codes. The TextBox is bound to property in the VM, and the SelectedItem is bound to a property in the VM. That all works fine.
The way I want the UI to work is when the user selects a state from the ListBox, the TextBox is automatically filled in, and this works fine.
Where it gets messy is when the user types in the state in the TextBox. When I get the first character, what I want to do is reposition the list box at the first matching state code for that letter, so for instance, if the ListBox is sitting at "AK" (Alaska) and the user is going to type "ID" for Idaho, when I get the "I" I want to position the ListBox so you can see the first "I" state, which is "IA" (Iowa).
If I use code behind and point SelectionChanged=BringSelectionIntoView with this method coded as follows, it works great:
private void BringSelectionIntoView(object sender, SelectionChangedEventArgs e)
{
ListBox lb = (ListBox)sender;
lb.ScrollIntoView(lb.SelectedItem);
}
All I have to do is scan the list of state codes until the first letter matches, then update the Index property to which SelectedIndex is bound, and poof, the BringSelectionIntoView() method gets invoked and I have exactly the UI behavior I want.
Trying to do this in a purest MVVM methodology, however, has proved quite frustrating. I'm not using MVVMLight or ExpressionBlend--I want a simple way to do this in MVVM. I understand the purest's mindset of not putting any UI code in the view, but the framework is insanely cumbersome to enact this kind of behavior. There's a point of diminishing returns when you have to create such obtuse plumbing to force yourself to adhere to a pattern when it's far more practical to put in the method with 2 lines of code that works perfectly.
So my question is this: am I doing something wrong and is there a simple way to make this work without violating MVVM? It's disappointing if the solution requires additional SDKs or someone's framework. That would suggest that MVVM doesn't have particularly good legs to stand on in a generic OOP sense.
Does someone see an error in what I'm trying to do, or do you see a simplistic solution here? Thanks!
MVVM is not about not having any code behind.
What you're talking about here is VIEW behavior. Which fits perfectly in the code behind, as long as you're not messing with the DATA in the event handlers.
You're using a VIEW event handler to manipulate a VIEW aspect.
That doesn't break MVVM.
Keep it that way. Keep it Simple.
You should still have a ViewModel and a Model to hold the DATA that the UI shows.
This is a perfect use case for an attached behavior. You can write this behavior once and use it for all listboxes without ever having to write any additional code. If you would like me to elaborate, ask and I'll post more information.

Categories

Resources