Prev: An attempt was made to access a socket in a way forbidden by its access permissions
Next: Suscribe event of deleted in a datatable
From: Jehu Galeahsa on 6 Apr 2010 22:59
Hello:

I implemented IDataErrorInfo using a simple Dictionary<string, string>
in a business object. What I noticed was that even after erroring a
"column" or setting the Error property, the ErrorProvider never
displayed the red exclamations.

So, I modified my code so that when an error was set a PropertyChanged
event was raised. This seems to be working... sorta.

Is raising PropertyChanged necessary? or should this be working
without it?

Thanks,
Travis
From: Willem van Rumpt on 7 Apr 2010 03:31
Jehu Galeahsa wrote:
> Hello:
>
> I implemented IDataErrorInfo using a simple Dictionary<string, string>
> in a business object. What I noticed was that even after erroring a
> "column" or setting the Error property, the ErrorProvider never
> displayed the red exclamations.
>
> So, I modified my code so that when an error was set a PropertyChanged
> event was raised. This seems to be working... sorta.
>
> Is raising PropertyChanged necessary? or should this be working
> without it?
>
> Thanks,
> Travis

Reading the MSDN entry on IDataErrorInfo, the interface seems to just
describe a dictionary like structure that /can/ provide extra
information regarding errors (or whatever string - string pair
information you would like, actually). It's a bit of weird framework
interface, if you ask me, especially given the documentation present.

Not being too familiar with both types, I'd say you have to implement
your own notification mechanism. Whether you do that through
implementing INotifyPropertyChanged or something else, is up to you of
course.

--
Willem van Rumpt
From: Jehu Galeahsa on 7 Apr 2010 09:43
On Apr 7, 1:31 am, Willem van Rumpt <noth...(a)nowhere.com> wrote:
> Jehu Galeahsa wrote:
> > Hello:
>
> > I implemented IDataErrorInfo using a simple Dictionary<string, string>
> > in a business object. What I noticed was that even after erroring a
> > "column" or setting the Error property, the ErrorProvider never
> > displayed the red exclamations.
>
> > So, I modified my code so that when an error was set a PropertyChanged
> > event was raised. This seems to be working... sorta.
>
> > Is raising PropertyChanged necessary? or should this be working
> > without it?
>
> > Thanks,
> > Travis
>
> Reading the MSDN entry on IDataErrorInfo, the interface seems to just
> describe a dictionary like structure that /can/ provide extra
> information regarding errors (or whatever string - string pair
> information you would like, actually). It's a bit of weird framework
> interface, if you ask me, especially given the documentation present.
>
> Not being too familiar with both types, I'd say you have to implement
> your own notification mechanism. Whether you do that through
> implementing INotifyPropertyChanged or something else, is up to you of
> course.
>
> --
>    Willem van Rumpt- Hide quoted text -
>
> - Show quoted text -

I was playing around yesterday. A lot of examples online show ways of
using this interface. Many of those examples are actually performing
validation within the indexer. I am not sure if that was the
intention, though.

Some further analysis shows that this interface is called during
validation (when a control loses focus). Needing to notify the user
interface of a change is similar to the need for
INotifyPropertyChanged - without it, the UI has no way of determining
whether it needs to update.
From: Willem van Rumpt on 7 Apr 2010 11:11
Jehu Galeahsa wrote:

>
> I was playing around yesterday. A lot of examples online show ways of
> using this interface. Many of those examples are actually performing
> validation within the indexer. I am not sure if that was the
> intention, though.
>

From the samples I can find on the internet, nothing hints that
INotifyPropertyChanged is required. The samples I found just hook up the
various datasource properties, and everything just works (according to
the description on the sites that is, I didn't actually try them).

They all seem to do their business in the indexer indeed.

> Some further analysis shows that this interface is called during
> validation (when a control loses focus). Needing to notify the user
> interface of a change is similar to the need for
> INotifyPropertyChanged - without it, the UI has no way of determining
> whether it needs to update.

From what I found on the web, I can't say I like the concept of
IDataErrorInfo. It looks messy. Maybe it's practical in terms of use,
but I think it pollutes the model.

Whether or not to use INotifyPropertyChanged is still your own choice.
If you want an observer like pattern, then yes, INotifyPropertyChanged
(and INotifyCollectionChanged) is the way to go. But it is by no means
the only way to update a UI, nor necessarily the preferred way.

The job is to decide where the responsibility for updating the UI will
go. More likely than not, it will turn out to be a combination of
observer pattern (which could be INotifyPropertyChanged, and have part
of that responsibility in the UI through databinding), and some
controller or presenter.

--
Willem van Rumpt
From: Jehu Galeahsa on 8 Apr 2010 00:41
On Apr 7, 9:11 am, Willem van Rumpt <noth...(a)nowhere.com> wrote:
> Jehu Galeahsa wrote:
>
> > I was playing around yesterday. A lot of examples online show ways of
> > using this interface. Many of those examples are actually performing
> > validation within the indexer. I am not sure if that was the
> > intention, though.
>
>  From the samples I can find on the internet, nothing hints that
> INotifyPropertyChanged is required. The samples I found just hook up the
>   various datasource properties, and everything just works (according to
> the description on the sites that is, I didn't actually try them).
>
> They all seem to do their business in the indexer indeed.
>
> > Some further analysis shows that this interface is called during
> > validation (when a control loses focus). Needing to notify the user
> > interface of a change is similar to the need for
> > INotifyPropertyChanged - without it, the UI has no way of determining
> > whether it needs to update.
>
>  From what I found on the web, I can't say I like the concept of
> IDataErrorInfo. It looks messy. Maybe it's practical in terms of use,
> but I think it pollutes the model.
>
> Whether or not to use INotifyPropertyChanged is still your own choice.
> If you want an observer like pattern, then yes, INotifyPropertyChanged
> (and INotifyCollectionChanged) is the way to go. But it is by no means
> the only way to update a UI, nor necessarily the preferred way.
>
> The job is to decide where the responsibility for updating the UI will
> go. More likely than not, it will turn out to be a combination of
> observer pattern (which could be INotifyPropertyChanged, and have part
> of that responsibility in the UI through databinding), and some
> controller or presenter.
>
> --
>    Willem van Rumpt

Thanks for your reply. With a little sweat and luck I was able to get
this working. However, it has strange effects on the UI, such as the
ErrorProvider not blinking.

I have observed that MVC and binding don't work well together. Our
user interfaces allow a lot to be done between saves, which makes
tracking changes and validation major headaches. Oh well, I am going
to assume I have this working and move on. Next week we'll find
something else that doesn't work quite right. :-)
 |  Next  |  Last
Pages: 1 2
Prev: An attempt was made to access a socket in a way forbidden by its access permissions
Next: Suscribe event of deleted in a datatable