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.
Related
I am using the EventAggregator in Caliburn.Micro in a Windows Phone 8 App.
There are a number of places where the view-models implement IHandle<SomeClass>.
My Question is since multiple classes will be handling when an object of SomeClass is published, even though they may not be the intended recipient. So what is the best way to deal with this....
Design message classes with different names (but essentially the same content) so that all communication between view-models is strictly point-to-point ?
Or put a source property in message classes so that all receivers know the source of the message so that it can be conditionally processed ?
There is no right or wrong answer to this question. As I see it:
There are cases when you want point-to-point and it is okay to have a specific message type (class) for solely this purpose
There are cases when you want an event like (broadcast) behavior
You can also have broadcast with active cancellation just like the one you have in System.Threading.Task, or like the one in the WPF eventing model where each handler is a visitor and can set the Handled flag of an event argument (say SomeClass) to true so that the other handler know they shouldn't be processing it anymore.
Also the name EventAggregator typically points to the fact that it's most common use is to aggregate handlers i.e. do broadcasting (at least this is how I see it)
Think about the WPF eventing model as an analogy.. You raise the event (publish it) but don't really care about how many handlers you have or what they are doing.
When should I be using an Event Handler versus an Event Aggregator?
In my code, I have two ViewModels that controlled by a parent ViewModel, I am trying to decide if I should just use an event handler to talk between them? Or use an Event Aggregator? It is going to just be simple method call, I don't require parameters to be passed between them.
The way I see it, the EventAggregator is usually the heavy gun used when you want to publish an event to the entire application and more specifically - when you don't know who exactly is listening.
In your scenario that's not really the case, you have 2 view models that want to communicate, but they both know each other. So there is no real reason you can't use events.
I'll just mention that if you want to keep it a little more loosely-coupled - make an interface for each of the viewmodels that exposes the event. This way each VM will use the other VM's Interface instead of a specific instance.
Here is a link with some good info (that is alive as of 5/2019)...
https://learn.microsoft.com/en-us/previous-versions/windows/apps/xx130639(v%3dwin.10) (Microsoft, Prism)
The "Making key decisions" section describes when to use it.
Events in .NET implement the publish-subscribe pattern. The publisher and subscriber lifetimes are coupled by object references to each other, and the subscriber type must have a reference to the publisher type.
Event aggregation is a design pattern that enables communication between classes that are inconvenient to link by object and type references. This mechanism allows publishers and subscribers to communicate without having a reference to each other. Therefore, .NET events should be used for communication between components that already have object reference relationships (such as a control and the page that contains it), with event aggregation being used for communication between loosely coupled components (such as two separate page view models in an app). For more info see Event aggregation.
I crudely see this as suggesting C# events are good for layers (UI listening to bus logic) or parent/child (an instrument listening to its contained devices) and event aggregation is good for siblings (e.g., sibling UI panels or device to device communication).
I want to achieve a simple Subscribe/Publish mechanism within a WPF application so i can subscribe to events from different places in the application specifying the event type and handler method, and then when publishing the event, my mechanism will call all the subscribed methods on the subscribers. I cannot use the RoutedEvent as I want to raise events freely without being forced to the visual tree.
I am able to achieve the above using c# reflection. But as I am pretty new to c# and WPF(coming from Java), I want to be sure that this is the preferred way.
Is It ??
Many Thanks,
It looks like you want the "Event Aggregator" pattern from the Prism framework. Surely you can implement it by yourself, although I don't see why you might need reflection for it.
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.
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.