Provide a 'global' PropertyChanged event (e.g. at the Consumer)

[radio42]

In order to get notified about a parameter value change, you must today subscribe to the PropertyChanged event of that specific Parameter instance.
This individual event subscription is fine and works perfect.

But in case you are interested in ANY parameter value change (e.g. because your are implementing a general viewer/consumer app), you must subscribe to ALL parameter PropertyChanged events - which might be hundreds or thousand of events to subscribe to (depending on the provider you are connected to).

This seems in some cases quite uncomfortable and cumbersome.

Is there a possibility to provide a single/global PropertyChanged event (e.g. at the Consumer class level) which is being raised, in case ANY parameter is changing. The PropertyChangedEventArgs PropertyName member in this case contain the full path of the related Parameter being changed?!

Many Thanks in advance,
Bernd

[andreashuber-lawo]

Is there a possibility to provide a single/global PropertyChanged event (e.g. at the Consumer class level) which is being raised, in case ANY parameter is changing. The PropertyChangedEventArgs PropertyName member in this case contain the full path of the related Parameter being changed?!

Can you elaborate why you need this? What is the real-world use case? I'm asking because this could difficult to implement efficiently.

[radio42]

I tried to elaborate this already above... but again:
Think of implementing a full and generic Ember+ Tree Viewer, which displays all nodes and parameter leafs including its parameter values.
You of course want(need) to update the UI in case a parameter value changes.

Today you would need to subscribe to ALL parameter PropertyChanged events - which might be hundreds or thousand of events to subscribe to (depending on the provider you are connected to).
This is quite inefficient.

If there would be a single, central, global (however you name it) event on the consumer level, which tells you:
a) the full path of the element/parameter which has been changed
or
b) gives you the related IParameter already
-> you could very easily identify the changed parameter and update the UI accordingly.

This simply saves and eases the implementation of a consumer app.

Here is another scenario/use-case:
Assume you implement a consumer app, which needs to trigger certain logical actions in a connected radio automation or play-out system. This consumer app should be flexible and dynamic and be able to connect to ANY Ember+ provider is a very generic fashion (meaning you do NOT want to 'hard-code' anything for a specific provider).
This means you MUST use the dynamic mode to mirror the providers ember schema/tree/nodes.
Now your consumer app needs to implement in a very generic way rules to trigger the above mentioned actions based on parameter changes.

In order to implement something like this: you would need a central, global event at the consumer level which gets raised, whenever ANY parameter value changes.
Else, the only solution is to again subscriber to ALL existing parameters... which is again very inefficient.

[andreashuber-lawo]

Think of implementing a full and generic Ember+ Tree Viewer, which displays all nodes and parameter leafs including its parameter values.
You of course want(need) to update the UI in case a parameter value changes.

Agreed.

Today you would need to subscribe to ALL parameter PropertyChanged events - which might be hundreds or thousand of events to subscribe to (depending on the provider you are connected to).
This is quite inefficient.

What GUI technology are you using?

Assume you implement a consumer app, which needs to trigger certain logical actions in a connected radio automation or play-out system. This consumer app should be flexible and dynamic and be able to connect to ANY Ember+ provider is a very generic fashion (meaning you do NOT want to 'hard-code' anything for a specific provider).
This means you MUST use the dynamic mode to mirror the providers ember schema/tree/nodes.
Now your consumer app needs to implement in a very generic way rules to trigger the above mentioned actions based on parameter changes.

Ok, IIUC, you are saying that you have one or more sets of parameters. Whenever one parameter of such a set changes, then you need to process the values of all parameters in the set to produce some kind of output, correct?

[radio42]

What GUI technology are you using?

C#/WinForms: further I am using the DevExpress lib in my UI.
If you want I can send you a sample project of a simple viewer.

Ok, IIUC, you are saying that you have one or more sets of parameters. Whenever one parameter of such a set changes, then you need to process the values of all parameters in the set to produce some kind of output, correct?

I am not sure where you are heading, as no, I don't necessarily have a predefined set of parameters. The mapping of ANY parameter value change should be dynamic. Meaning even at runtime of the application new mapping rules should be added or modified;as such, a global event would simply be optimal.

[andreashuber-lawo]

C#: further I am using the DevExpress lib in my UI.

Ok, DevExpress supports data binding, correct? If you have DevExpress UI elements bind directly to IParameter.Value you don't need to bother with subscribing/unsubscribing yourself, right?

I am not sure where you are heading, as no, I don't necessarily have a predefined set of parameters. The mapping of ANY parameter value change should be dynamic. Meaning even at runtime of the application new mapping rules should be added or modified;

That's fine, at runtime you'd still have one or more sets of parameters, as described before. It doesn't matter whether the number of parameters in a given set changes dynamically or not.

as such, a global event would simply be optimal.

I would argue that it depends, as always. If you have only a single set of parameters and you absolutely need to recalculate everything whenever the value of any of those parameters changes, then yes, a mechanism as the one you're proposing is probably a good idea. OTOH, if you have many independent sets of parameters, I would think it's probably more efficient to subscribe the calculation method for each set to only the PropertyChanged events of the parameters that belong to the set, right?

Sure, you do have to write the code to subscribe and unsubscribe from the different parameters as needed, but such a generic system would do that in a single place anyway, right?

[radio42]

DevExpress supports data binding, correct?

Yes, but I don't want to use that, as it comes with certain limits, which are much easier to overcome without using data binding (especially for larger trees).

In the end it is a philosophical discussion.
If it is too hard/complex to implement on your side, then don't do it. There is no issue with doing so!

I just thought, that it might be easy to implement on your side; e.g. as you already raise an event on a single IParameter; you might simply propagate that to the related IConsumer level...

[andreashuber-lawo]

Yes, but I don't want to use that, as it comes with certain limits, which are much easier to overcome without using data binding (especially for larger trees).

Ok, fair enough.

I just thought, that it might be easy to implement on your side; e.g. as you already raise an event on a single IParameter; you might simply propagate that to the related IConsumer level...

Raising an event on the parameter level can be implemented such that you basically only have a measurable cost if there's a handler subscribed to the event. Once you start propagating such events up the tree, that is no longer possible. I have the suspicion that it's going to be rather inefficient, if you consider the fact that some providers change thousands of parameters in a single message. Let me think about this some more, it seems there should be a way to implement this such that there is no cost as long as no handler is subscribed to the event.

BTW, given the "some providers change thousands of parameters in a single message" scenario above, you'd get thousands of change messages with said event. Would that be what you want?

[radio42]

BTW, given the "some providers change thousands of parameters in a single message" scenario above, you'd get thousands of change messages with said event. Would that be what you want?

I am afraid yes, as I would also get thousands of change messages when subscribed to the individual parameters events ;-)
However, while thinking of it, if there might be an IConsumer property to define this, that would be best. E.g. something like bool RaiseIndividualChangeEvents.
If that's set to false, only one event per received Glow message would be raised (its event args properties might be set to null in that case).
... just thinking loud ;-)