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.
Related
For an application that I'm working on I use SpotifyLocalAPI, and I want to use the events that the API has. But, as someone who is into C# for a couple of months now, I'm not sure where to start. There is another project based on this API that uses the events, but it's in WPF, and that makes it a different deal if I understand my googeling correctly. This means that for a WinForms I have to do things a bit differently, but I can't seem to figure out how.
The documentation of the API states that You can set a SynchronizingObject, then the events will be called on the specific context. When I look at how the WPF project did this, it has a function (found here) to do some magic, and poof, it works.
If I understand this answer correctly the SynchronizingObject is a property of the ISynchronizeInvoke interface, which "provides synchronous and asynchronous communication between objects about the occurrence of an event.".
Okay, so far so good. I think I understand the basic working of the interface, but how am I supposed to work with it? How do I convince the application that it should react to the event? How should I define the _spotify.SynchronizingObject? (Which is the main problem for me right now)
You can set the SynchronizationObject to be any UI element that implements IShynchronizeInvoke (Form, UserControl etc). Check out the example Winforms app here. Note that this is optional, and in that example app, they have chosen to use Invoke() explicitly in the event handlers. The important thing to remember is that if you want to update the UI, then the code to do so must be run on the UI thread. Some more details on this here.
I've come into an issue that must be quite common, but with little insight around the world of Google.
You see, my project has 3 parts that I use:
CommunicationClass.cs (Asynchronous Socket Class)
Form1.Designer.cs (Containing the objects of Form1)
Form1.cs (Main constructor and contains event handlers for objects)
Pretty basic setup.
However, I don't know where I put my communication class instance. The communication class sends/receives messages. So, my instance of ComClass in Form1 would use its void Send() in the event handler for the enter key being pressed (while in a textBox).
That works fine. What doesn't work fine is when the ComClass RECEIVES a message. It can't use the non-static voids of PrintMessage() in Form1.cs, and PrintMessage can't be a static void because richTextBox1, where the messages are shown, is non-static.
I'm wondering if another component of C# will help me access these and overcome my problem, but I'm too new to C# to know. I want to keep using the layout I have rather than switch to one like an example TCP chat client, where the form is created outside of Program.cs.
In C#, the standard paradigm for stuff like this is to use events. This ties in with the idea of the Observer Pattern in software design.
You are already using that for handling the key-press. The "trick" is to implement an event on your CommClass that the Form instance can subscribe to, in order to receive notification of incoming data.
The usual .NET Forms implementation is usually a kind of "poor man's MVC", in which the Form class winds up acting as controller and view all at the same time. Of course, doing so negates the main benefit of an MVC design, which is that the view is completely independent of the controller.
But you could (after learning more about the MVC design pattern) create a third "controller" class that ties together the view (your Form) and the model (your CommClass where the actual meat of the work is implemented).
If you want to go really cheesy, you could just pass your Form instance directly to the CommClass and have some special method that the CommClass knows to call when it receives data. But that's just doubling-down on the failure to separate concerns between your class, tying them even more closely. Maybe okay for a quick-and-dirty proof of concept, but that's no way to write code that you have any interest in reusing some time in the future.
I'm currently trying to create an application with Prism and I have some problems with communication between modules.
I have a StatusModule which basically shows Statusmessages, but can also show the user that some work is in progress (indeterminate), show different icons, show / hide the control and so on.
For that normally i'd use a status object that has all these properties and use it as a parameter, but because in prism strong coupling is advised I don't know how I should do it.
Creating 4-5 Events for every property is probably bad practice, .. i also thought of creating an interface in my "Interaction" Module where the event's and resources are.
What would you guys recommend?
Many events for status might indeed not be the best solution; however if there's one or two that are used a lot (like showing a status message in a statusbar), I would expose them as events anyway for convenience.
For the rest, you can expose the StatusModule, or rather an interface IStatusModule that is implemented by StatusModule, via MEF or Unity depending on what you use. This way any component that wants to show status imports the IStatusModule and uses it.
in c# what is Event? Is it similar to ActionScript Event ? Is it different? In what?
An event in C# is a way for a class to
provide notifications to clients of
that class when some interesting thing
happens to an object. The most
familiar use for events is in
graphical user interfaces; typically,
the classes that represent controls in
the interface have events that are
notified when the user does something
to the control (for example, click a
button).
This tutorial shows how to declare, invoke, and hook up to events in C# http://msdn.microsoft.com/en-us/library/aa645739%28VS.71%29.aspx
An event in C# is a way for a class to provide notifications to clients of that class when some interesting thing happens to an object
An event is a mechanism via which a class can notify its clients when something happens. For example when you click a button, a button-click-event notification is sent to the window hosting the button. Events are declared using delegates.
for more detail : http://www.codeproject.com/KB/cs/csevents01.aspx
"An event in C# is a way for a class to provide notifications to clients of that class when some interesting thing happens to an object. The most familiar use for events is in graphical user interfaces; typically, the classes that represent controls in the interface have events that are notified when the user does something to the control (for example, click a button)."
From here:
http://msdn.microsoft.com/en-us/library/aa645739(VS.71).aspx
Yes, it is similar to ActionScript Events.
as the Event class is passed as a parameter into an event listener I would say EventArgs
MSDN is an excellent place to start.
Short version: Events are a conceptual nicety that allows simpler implementation of a callback/subscription model for notification.
Event is programming construct by which a class or an object, to be specific, inform(notify) a particular change of state to a list of subscribed objects in a multicast fashion.
I've been looking in to the Composite Application Library, and it's great, but I'm having trouble deciding when to use the EventAggregator... or rather - when NOT to use it.
Looking at the StockTraderRI example, I'm even more confused. They are using the EventAggregator in some cases, and "classic" events in other cases (in for example the IAccountPositionService interface).
I've already decided to use it for communication with a heavy work task, that should run on a background thread. In this case the EventAggregator offers marshalling of threads behind the scenes, so I don't have to worry much about that. Besides that I like the decoupling this approach offers.
So my question is: When I've started using the EventAggregator in my application, why not use it for all custom events?
This is a good question. In Composite WPF (Prism) there are 3 possible ways to communicate between parts of your app. One way is to use Commanding, which is used only to pass UI-triggered actions down the road to the actual code implementing that action. Another way is to use Shared Services, where multiple parts hold a reference to the same Service (Singleton) and they handle various events on that service in the classical way. For disconnected and asynchronous communication, as you already stated, the best way is to use the Event Aggregator (which follows closely Martin Fowler's pattern).
Now, when to and not to use it:
Use it when you need to communicate between modules. (for example, a Task module needs to be notified when a Task is created by any other module).
Use it when you have multiple possible receivers or sources of the same event. For example, you have a list of objects and you want to refresh it whenever an object of that type is saved or created. Instead of holding references to all open edit/create screens, you just subscribe to this specific event.
Don't use it when you only have to subscribe to normal events in the Model View Presenter area. For example, if your presenter listens to changes in the Model (for example the Model implements INotifyPropertyChanged) and your Presenter needs to react on such changes, it's better that your Presenter handles directly the PropertyChanged event of the Model instead of diverting such events through the Event Aggregator. So, if both the sender and receiver are in the same unit, there's no need to "broadcast" such events to the whole application.
I hope this answers your question.