C# Discussion Boards - CodeProject

BobJanova5-Mar-14 0:56

BobJanova

5-Mar-14 0:56

Implementing INotifyPropertyChanged on your item class (e.g. Person) will cause a BindingList to fire ListChanged (subtype ItemChanged) events whenever your object fires a property notification event (usually in property setters). You can then hook up to that to store a list of what's been touched. It will also ensure that whatever you bind the list to in your UI will get updated when the items actually change.

Putting INotifyPropertyChanged on your domain objects is a bit ugly but I think it's the right way to go here.

Gilbert Consellado5-Mar-14 22:19

5-Mar-14 22:19

Thank you for the reply

BobJanova wrote:
Putting INotifyPropertyChanged on your domain objects is a bit ugly but I think it's the right way to go here.

yes your right.

That is the main purpose of GCSCBindingList<t>, creating object without implementing INotifyPropertyChanged.

I am still digging on the internet for solution.

Trying to figure out how to implement IBindingList instead of BindingList<t> as my last resort.

But if i cant figure it, there is nothing i can do but to implement INotifyPropertyChanged.

Gilbert Consellado5-Mar-14 22:42

5-Mar-14 22:42

I think INotifyPropertyChanged is not good to implement, there is some articles saying that, implementing INotifyPropertyChanged will cause performance issue.

modified 7-Mar-14 3:57am.

BobJanova6-Mar-14 6:10

BobJanova

6-Mar-14 6:10

Implementing INPC will cause your property getters to be called every time you notify the binding list that a property is changed. If you have expensive property getters (e.g. talking to an external data source), that could cause a problem – best practice is not to do that. If you're updating a lot of properties on the same item repeatedly, you'll want some kind of BeginUpdate/EndUpdate mechanism whereby you can turn off notifications while you make a lot of changes.

Gilbert Consellado6-Mar-14 22:05

6-Mar-14 22:05

BobJanova wrote:
Implementing INPC will cause your property getters to be called every time you notify the binding list that a property is changed. If you have expensive property getters (e.g. talking to an external data source), that could cause a problem – best practice is not to do that.

Yes that is what i want, to exclude INotifyPropertyChanged

BobJanova wrote:
If you're updating a lot of properties on the same item repeatedly, you'll want some kind of BeginUpdate/EndUpdate mechanism whereby you can turn off notifications while you make a lot of changes.

Could you give me some hint about that.
Please

Actually my plan is, when i initialize the bindingList it will get data from external source, then after that if one of the object property has been modified that object will be mark "Dirty" (its means it should be updated to the external data source). So while the bindinglist data has on the stage that some of its object is modifying, it will not reflected to the external source. then after that if i already finished modifying the bindinglist, that is the time that i should update the external data source.

My big problem here is, what object of the bindingList has been modified? "without implementing INPC".

So What i want is to enumerate all dirty objects, then after that it will update the external datasource.

Thanks.

Eddy Vluggen6-Mar-14 7:10

Eddy Vluggen

6-Mar-14 7:10

Gilbert Consellado wrote:
Is there way enumerating all edited items?

Depends on how you track what has been edited. From your base-class, I'd expect that flag to be set in the setter of the affected properties of all derived classes. It won't be set automatically.

INotifyPropertyChanged isn't "slow", but it'd be a bit overkill if you're using it merely to track which record has changed.

Alternatively, you can override Object.GetHashCode[^] and present a hash of the combined properties. That'd make comparing easy Smile | :)

Bastard Programmer from Hell Suspicious | :suss:

If you can't read my code, try converting it here[^]

Gilbert Consellado6-Mar-14 22:25

Is C# is fully object oriented or not?

6-Mar-14 22:25

Eddy Vluggen wrote:
Depends on how you track what has been edited. From your base-class, I'd expect that flag to be set in the setter of the affected properties of all derived classes. It won't be set automatically.

I am sorry, but how i should do that.

Eddy Vluggen wrote:
Alternatively, you can override Object.GetHashCode[^] and present a hash of the combined properties. That'd make comparing easy

I was thinking if i have huge amount of data, then comparing each of them, could that be potential for performance issue.

Member 102864334-Mar-14 21:48

Member 10286433

4-Mar-14 21:48

Tell me the answer for this one.

Peter Leow4-Mar-14 21:59

Peter Leow

4-Mar-14 21:59

Read this: is-c-sharp-a-100-object-oriented-programming-language[^]

BobJanova5-Mar-14 0:39

BobJanova

5-Mar-14 0:39

That's not really an answer as apparently SO can't agree!

Personally I'd say that it is almost 100% OO, everything in C# is an object, even primitive types ... except methods and classes, which can easily be manipulated into object types (Delegate and Type respectively), but which are not actually objects in and of themselves.

OriginalGriff4-Mar-14 22:14

OriginalGriff

4-Mar-14 22:14

Yes.

Those who fail to learn history are doomed to repeat it. --- George Santayana (December 16, 1863 – September 26, 1952)
Those who fail to clear history are doomed to explain it. --- OriginalGriff (February 24, 1959 – ∞)

BillWoodruff4-Mar-14 23:08

BillWoodruff

4-Mar-14 23:08

Well, I think that all depends on how you define what an OO Language is. If you met someone at Xerox Parc in the 1970's who programmed in SmallTalk, and showed them the C# Language specification, they might say C# is not a full OO Language because it doesn't support "true" multiple-inheritance, and it distinguishes value Types from reference Types. But, that same person would probably also say that Java, Ruby, and Python, are not OO Languages.

But, if you ask the question as: "Is C# an object-oriented language ?:" then, I would say: "yes," because you can't do squat in C# without creating and using objects; and, yes, because C# supports the key-features of object-oriented languages, including classes, and inheritance.

“The best hope is that one of these days the Ground will get disgusted enough just to walk away ~ leaving people with nothing more to stand ON than what they have so bloody well stood FOR up to now.” Kenneth Patchen, Poet

harold aptroot5-Mar-14 1:21

harold aptroot

5-Mar-14 1:21

What exactly do you mean by "fully object oriented"? That doesn't seem to be a well-defined term.

Wayne Gaylard5-Mar-14 1:37

Wayne Gaylard

5-Mar-14 1:37

Please can you define what you mean by well-defined term . Big Grin | :-D

Everyone dies - but not everyone lives

harold aptroot5-Mar-14 1:39

harold aptroot

5-Mar-14 1:39

Oh you

OriginalGriff5-Mar-14 1:56

OriginalGriff

5-Mar-14 1:56

See recursion.

Wayne Gaylard5-Mar-14 1:58

Wayne Gaylard

5-Mar-14 1:58

Recursion.[^]

Everyone dies - but not everyone lives

lukeer5-Mar-14 3:07

lukeer

5-Mar-14 3:07

Not fully recoursive.

This is.

Ciao,

luker

Wayne Gaylard5-Mar-14 3:18

Wayne Gaylard

5-Mar-14 3:18

Ok - you win!

Everyone dies - but not everyone lives

pradeep surya5-Mar-14 7:33

pradeep surya

5-Mar-14 7:33

C# is object oriented.

Pete O'Hanlon5-Mar-14 7:38

Pete O'Hanlon

5-Mar-14 7:38

As Bill points out, just how OO is it? Does the fact that it allows static methods and objects adhere to OO tenets?