C# Discussion Boards - CodeProject

Re: Issues in using Observable<T> to fire Property notification events (WinForms)

11-Aug-11 3:45

.NET 4.0

I have just finished finally figuring out how (in WinForms) to make changes to Properties in an ObservableCollection<T> fire notifications ... attaching events to ObservableCollection items, like adds, and deletes, are, of course, easily handled ... and it required a rather ugly hack to do it which involved casting an instance of an Observable<t> to the INotifyPropertyChanged interface.

Attempting to figure out if I have created a monstrosity, or if there's a better way, I have been searching CP for information on generic ObservableCollections<T>, and INotifyPropertyChanged, and just about everything that comes up is WPF or SilverLight related.

My impression is that WPF and SilverLight offer much more flexibile facilities for wiring-up property changes than WinForms, that 'INotifyPropertyChanged' is a different critter in WPF, and that one would not have the problem I encountered in WinForms in getting Property changes to raise events.

But, I would appreciate an opinion from those of you who I am sure know both WinForms and WPF well, if my impression is correct.

In the unlikely case I have discovered some useful technique for WinForms, I'll certainly publish an article on it here on CP.

thanks, Bill

"In the River of Delights, Panic has not failed me." Jorge Luis Borges

modified on Thursday, August 11, 2011 2:23 PM

BobJanova11-Aug-11 22:27

BobJanova

11-Aug-11 22:27

First question, if you're data binding, why not use a BindingList<T>? Binding to that automatically causes the collection changes to be attached to, though I think that is the case for anything which implements INotifyCollectionChanged.

If your element type (i.e. 'T') implements INotifyPropertyChanged, the data consumer will hook to it and will update its display when you fire it (for the property which you declare as notified). I have tried this at least for a DataGridView and basic one-property controls (text box, check box etc) and it works as expected. You shouldn't need to do any casting if T implements that interface.

I'm not quite sure if you're asking a question here or just providing information about your experience so replying to the post is a bit tricky!

Re: Issues in using Observable<T> to fire Property notification events (WinForms)

BillWoodruff11-Aug-11 23:23

Re: Issues in using Observable<T> to fire Property notification events (WinForms)

11-Aug-11 23:23

Hi Bob, thanks for your response !

BobJanova wrote:
if you're data binding, why not use a BindingList<T>?

In this case I am not binding anything; there's no dataset in the woodpile Smile | :)

I will go and take a look at Binding<T> now that you've pointed that out to me. fyi: I am familiar with implementing property notifications, like for the Text in a TextBox changing without any use of a dataset, or datasource.

BobJanova wrote:
not quite sure if you're asking a question here or just providing information about your experience

I'm not quite sure either; I believe I am asking the question of whether the requirement, in the case of using an OC<T>, to cast an instance of it to INotifyPropertyChanged, in order to use its internally implemented property change notifications ... which I consider a very odd thing to have to do ... is worth the 'ugliness' involved.

And, I am hoping that you, or someone else here, who I am sure are at very advanced levels in .NET development, will give me some insights into what seems like a 'mystery' (to my 'naive' eyes). Perhaps, insights, based on your knowledge of how .NET has evolved. I know that OC<T> has changed library locations, and possibly some internal behavior, from .NET 3.0=>3.5=>4.0.

My intent in exploring this area is somewhat academic ... but certainly not homework (I'm nearing 68 years old) ... I am just deeply interested in understanding .NET's implementation, in WinForms, C#.

On a practical level, the ability to get a notification when a value is changed of a member of an arbitrarily typed collection, independent of binding to a datasource, seems valuable to me; I focused on OC<T> because that gives you 'out-of-the-box' notifcations when an item is added, or deleted, from the Collection<T>. It seemed natural, once I found out that OC<T> implemented property notification, to want to use that.

I did 'stumble' into finding out how to use the native property notification facility in OC<T>, but finding even a 'clue' about how to use it took pretty thorough research here, on StackOverFlow, and on MSDN. And, the way I found to actually use it, in a fairly standard scenario, I came up with on my own; didn't find a single example of that in my research (which of course doesn't mean it isn't there, somewhere on the internet).

Let me see if I can 'wrap this up:' for example, if you, or Pete O., or Shameel, or others here, said to me: 'yeah the fact that OC<T>'s INotifyPropertyChanged implementation is kind of 'sealed,' and you have to cast an instance of your collection to it to be able to use it, really is weird, probably better ... because of .?. not to use it, I'd feel enlightened, temporarily.

On the other hand, if I heard here that it might be valuable to use a technique for making an OC<T>'s property notifications available, I'd certainly at least write up a tip/trick for CP.

On the broader level, I do look forward to one-day, perhaps, having something like Property Extensions in .NET, and I understand that has been considered seriously, but is not on the .NET time-line now. I'd definitely like to be able to do some of the things that it seems WPF offers you in terms of property bindings, etc.

best, Bill

"In the River of Delights, Panic has not failed me." Jorge Luis Borges

BobJanova11-Aug-11 23:57

BobJanova

11-Aug-11 23:57

Unfortunately I'm not really that familiar with ObservableCollection, though I have used the Silverlight version (is it the same?).

If I understand you correctly, you want to get an event on the collection when a property of an element is changed (and notified through INotifyPropertyChanged on the element – T must implement INotifyPropertyChanged and fire the notification event for any method of having observer updates). The ObservableCollection explicitly implements the INotifyPropertyChanged interface, so yes, if that event is correctly fired when a member element is updated, you will need to cast the collection to hook it. I haven't tried it so I don't know if it works.

(I.e., does the event get fired in this test case, and if so are the arguments useful:

void Test(){
 var c = new ObservableCollection<Notifier>();
 ((INotifyPropertyChanged)c).PropertyChanged += (s,e) => MessageBox.Show("Property "+e.PropertyName+" on "+s+" updated");
 c.Add(new Notifier());
 
 c[0].NotificationProperty = 42;
}

class Notifier : INotifyPropertyChanged {
 public event PropertyChangedEventHandler PropertyChanged;
 public int NotificationProperty {
  get { return notificationProperty; }
  set { notificationProperty = value; PropertyChanged(this, "NotificationProperty"); }
 }
}

)

The fact that they made that interface implementation explicit and force the cast implies they probably aren't expecting you to use it in this way, but if the event is fired when properties on the elements change and that is useful to you, I don't see a problem with using it in that fashion.

Re: Issues in using Observable to fire Property notification events (WinForms)

BillWoodruff12-Aug-11 12:27

Re: Issues in using Observable<T> to fire Property notification events (WinForms)

12-Aug-11 12:27

Thanks, Bob, for your response ! I will study your code over the weekend (I'm on GMT+7).

I think the best thing for me to do here, in order to clarify what I have found, and get reactions, is to go ahead and write up a Tip/Trick demonstrating fully what I started out to do, what the problem was I encountered in trying to do it, and what the 'odd' solution was that I finally came up with.

Then if the Tip/Trick leads to great gnashing of teeth, and I am cast into outer darkness, so be it.

best, Bill

"In the River of Delights, Panic has not failed me." Jorge Luis Borges

Pete O'Hanlon12-Aug-11 0:15

Pete O'Hanlon

12-Aug-11 0:15

I'm not sure what effect you are trying to achieve. ObservableCollection does not raise an PropertyChanged event - it raises events from INotifyCollectionChanged. What you could do, is inherit from ObservationChanged, and override the OnChanged method - and use this to raise a PropertyChanged event.

I hope that helps.

Forgive your enemies - it messes with their heads

My blog | My articles | MoXAML PowerToys | Mole 2010 - debugging made easier - my favourite utility

Re: Issues in using Observable to fire Property notification events (WinForms)

BobJanova12-Aug-11 2:48

BobJanova

12-Aug-11 2:48

According to the documentation[^], ObservableCollection also implements INotifyPropertyChanged, but explicitly (i.e. requiring a cast to hook to).

Re: Issues in using Observable to fire Property notification events (WinForms)

BillWoodruff12-Aug-11 12:29

problem with process.waitforexit(timeout)

12-Aug-11 12:29

Hi Pete, Thanks for responding !

As Bob says, in the post just above this one, ObservableCollection<t> does implement INotifyPropertyChanged, and my whole problem here was finding the way to use facility.

I think the best thing for me to do now, as I just wrote to Bob, in order to clarify what I have found, and get reactions, is to go ahead and write up a Tip/Trick demonstrating fully what I started out to do, what the problem was I encountered in trying to do it, and what the 'odd' solution was that I finally came up with.

Then, if the Tip/Trick leads to great gnashing of teeth, and I am cast into outer darkness, so be it.

best, Bill

"In the River of Delights, Panic has not failed me." Jorge Luis Borges

pprasanthk11-Aug-11 3:37

11-Aug-11 3:37

process = Process.Start(psi);
process.WaitForExit(executionTimeOutSecs * 1000); // convert seconds to milliseconds
if (!process.HasExited)
{
    StringBuilder text = new StringBuilder();
    text.AppendFormat("Having to kill {0}, executed longer than timeout value, {1} sec.", taskName,
                        executionTimeOutSecs);
    if (logging)
    {
        log.writeLogFile(text.ToString());
    }
    log.writeEventLogWarning(text.ToString());
    process.Kill();
    process.WaitForExit(1000);
}
process.Close();

Here i am getting "hasexited" false my process not exited in given time how to handle this.

Not Active11-Aug-11 4:27

Not Active

11-Aug-11 4:27

Properly format your code snippet and people may answer you

I know the language. I've read a book. - _Madmatt

pprasanthk11-Aug-11 5:41

11-Aug-11 5:41

process = Process.Start(psi);
process.WaitForExit(executionTimeOutSecs * 1000); // convert seconds to milliseconds
if (!process.HasExited)
{
StringBuilder text = new StringBuilder();
text.AppendFormat("Having to kill {0}, executed longer than timeout value, {1} sec.", taskName,
executionTimeOutSecs);
}
process.Close();

I think this is ok here Hasexited is retur nfalse i want to avoid this

Not Active11-Aug-11 5:58

Not Active

11-Aug-11 5:58

I said FORMAT the code snippet not REPOST it.

Read the forum guidelines, that post at the top of this list that you have ignored.

I know the language. I've read a book. - _Madmatt

pprasanthk11-Aug-11 7:02

11-Aug-11 7:02

The code which i pasted is enough to answer
see the question "How to get answer" and try to help developer

Not Active11-Aug-11 7:32

Not Active

11-Aug-11 7:32

Don't get cocky son. If you want to help here, follow the rules.

It is your responsibility to read, understand and comply with the posting guidelines. If you do this can be a very rewarding experience for you and us.

You were asked to format the code snippet according to the guidelines. You choose to ignore it and simple repost the same thing. You get back the same effort you've given.

I know the language. I've read a book. - _Madmatt

pprasanthk11-Aug-11 7:05

11-Aug-11 7:05

Read "how to answer a question" carefully and try to help
if you dont want to help keep quiet

Pete O'Hanlon11-Aug-11 7:20

Pete O'Hanlon

11-Aug-11 7:20

If you want help from people, it's not a good idea to tell them to keep quiet. Questions in the forums are answered by volunteers, so antagonising them doesn't help - more importantly, the regulars tend to band together, so having a go at one is a poor way to get others to help you.

Forgive your enemies - it messes with their heads

My blog | My articles | MoXAML PowerToys | Mole 2010 - debugging made easier - my favourite utility

pprasanthk11-Aug-11 7:34

11-Aug-11 7:34

i dont like critisizing the people that is the reason i said like that
if i know the answer sure i will give i expect other people also

thatraja11-Aug-11 7:43

thatraja

11-Aug-11 7:43

Man, you should have posted your code in code block like below.

process = Process.Start(psi);
process.WaitForExit(executionTimeOutSecs * 1000); // convert seconds to milliseconds
if (!process.HasExited)
{
StringBuilder text = new StringBuilder();
text.AppendFormat("Having to kill {0}, executed longer than timeout value, {1} sec.", taskName,
executionTimeOutSecs);
if (logging)
{
log.writeLogFile(text.ToString());
}
log.writeEventLogWarning(text.ToString());
process.Kill();
process.WaitForExit(1000);
}
process.Close();

But you posted the same un-formatted code in new message which is ugly one & against the rule. BTW He suggested you the same in his message like what I did now.

thatraja

My Tip/Tricks
My Dad had a Heart Attack on this day so don't...

pprasanthk11-Aug-11 7:45

11-Aug-11 7:45

sorry really i dont know how to do all these things just i got the problem i posted

jschell11-Aug-11 13:09

jschell

11-Aug-11 13:09

pprasanthk wrote:
Here i am getting "hasexited" false my process not exited in given time how to
handle this

Depends on what you need.

You can wait longer or kill the process.

pprasanthk11-Aug-11 17:57

11-Aug-11 17:57

Exactly but client is doing process.kill in process.hasexited condition
is there any way to wait for exit other than calling oveloaded of process.waitforexit()