Why can't I have a read only property with notify?

Elements Oxygene
1

In order to bind a property in xaml, I need to declare a property and use “notify” directive. But why do I have to have a read AND write accessor. This is the complaint I get.

Error 2 (E192) “notify” cannot be applied properties without both a “read” and “write” accessor C:\Users\Mark\Documents\Visual Studio 2013\Projects\SW\GuardianEditObservation\LocalizedStrings\Strings.pas 633 13 LocalizedStrings

The binding for this property will only happen once and it will use the read accessor. But my code will NEVER set this. I can’t indicate that by not having a write accessor now because of the error generated. I get this error in one project 775 times. The project is for localizing strings. And the property getter just gets stuff from a global static. So there is no need of a write accessor.

I just started converting my old Delphi Prism app to the latest Oxygene and Visual Studio 2013. A read only property with notify USED TO be supported. Is there some option that would let me turn off this error?

I guess I will make a BogusSetter method and put it as a setter and have it do nothing for all 775 properties. Not fun.

2

What’s the point? If your property can’t be written to, when would it notify?

3

I’ll be darned. I could have SWORN after using xaml for a few years now that I HAD to have the notify directive or it wouldn’t bind. I just tried a property without notify and it DID bind.

So I guess there ISN’T a requirement after all. So I can just take all the notify directives off.

Maybe the propertychange notification used to be required a long time ago and isn’t now. Or I had some situation that caused me to have to use the notify.

Anyway, I’m glad you asked the question because it forced me to try one without notify and see if it worked. It seemed to.

I’ll still have to change 775 places in that assembly, but I should be able to just do a replace all fairly easily.

Still I’m somewhat surprised that not having a write method is an ERROR versus a WARNING. I’ll get rid of all the notify directives in there and that should solve my problem easier than putting a bogus write method on all those properties.

1 Like
4

One example of a readonly property that could still have property change notification would be if the getter got it from some common place and it is the common place that changes. So when the common place changes IT could signal the property change event on the object that contains the readonly property. This would then cause the bindings to recall the getter which would get the new value from the common place.

For instance, the app might hold some global settings, but some viewmodel might have a property that it wants to have bound. But the viewmodel’s property would never change since it is always going to get it from the app’s settings. So the app could trigger the viewmodel’s property changed on the readonly property when the app determines that it is appropriate.

And that is what I was actually doing and why I used readonly with notify. The actual situation is even a bit more complicated as my co-worker and I are using my xap through dynamic loading and MEF. I fear that when I get past all the compiler errors, I will probably have to put that notification back in again so that our pieces/parts interact properly again, but it will be quite a while before I can test that out.

5

right, but how would you encode that with a notify omg the property? what would the “common place” do that would trigger the notification, in that case?

6

Isn’t that a property with a private write ? It compiles if I declare it like that. Its then up to that object to listen for the global setting changing.

7

I don’t remember what in the 52 projects is doing what, at the moment, and can’t review it until I can get it all compiled and running again, but at worst, I would think I could have the common place call a DoNotifyProperty or some such named method on the viewmodel that could then do a RaisePropertyChanged call.

8

Not quite sure what you mean John.

What I had was a class with some 775 properties that were all declared something like:

property MyString : String read getMyString; notify;

I don’t ever want that property to be set by anything, it only gets its information from the global settings that actually gets created by my co-worker’s code through MEF. I have to get all this stuff to compile and run again and then I’ll see if I really needed the notify or not. It MIGHT be the way it is bound in the xaml that I don’t need the notify and it will all be okay when the global changes. Not sure at this point.

(the reason for all these properties was to localize all the strings and error messages etc. Didn’t much care for creating them as resources for various reasons)

9

I meant, I think you should of declared the property as

property MyString:String read private write; notify;

10

Ah, interesting. Of course, I don’t really want to have a setter at all, but your suggestion is pretty close. At least nothing else would be able to try to set the property. (except that class).