public abstract class BindableBase implements INotifyPropertyChanged
protect _properties := Dictionary<string, object>{} as Dictionary<string, object>
public event PropertyChanged as PropertyChangedEventHandler
protected method _Get<T>( [CallerMemberName] name := null as string ) as T
local value := null as object
if _properties.TryGetValue( name, out value )
if value == null
return Default(T)
else
return (T) value
endif
endif
return Default(T)
protected method _Set<T>( value as T, [CallerMemberName] name := null as string ) as void
if ( Equals( value, _Get<T>(name) ) )
return
endif
_properties[name] := value
OnPropertyChanged( name )
return
protected virtual method OnPropertyChanged([CallerMemberName] propertyName := null as string ) as void
local handler as PropertyChangedEventHandler
handler := self:PropertyChanged
if handler != null
handler( self, PropertyChangedEventArgs{ propertyName } )
endif
return
end class
Wolfgang
Wolfgang Riedmann
Meran, South Tyrol, Italy
wolfgang@riedmann.it
https://www.riedmann.it - https://docs.xsharp.it
I know the power of #command and I like you showed this.
I commented in the context of Phil's question where.
I still don't like a #command solution or an auto solution. Whenever we code something we should answer the question: what is the cost of change. When doing like me or Phil now, we only add some lines of code if we want.
In case of a command: What if we need special behavior that cannot be resolved in a general manner. The same with the auto. I think it is too much work later. A snippet would do it at first place with a few key strokes. And then it's right.
this code is what is - not exactly - in MVVMlight. And it's ok to avoid being undepended from this library. But I stongly recommend to return a logic instead of a void showing changed or not. In you calling code you can ignore it if you like.
Phil,
The /ppo compiler switch just write the <source>.prg into a file <source>.ppo. If you don't set the switch the pre-processor output will only be available in memory. In essence if you don't have any defines/#command/#translate etc the .prg and the .ppo will have exactly the same content.
I in principle always have the /ppo switch set in debug mode. If you work with #command/#translate a lot then the .ppo is where you look at debugging your #command errors.
Hope this was the explanation you wanted.
Jack
______________________
Johan Nel
Boshof, South Africa
If we look back at Clipper and to a large extend VO/Vulcan, all commands were actually #command pre-processor driven.
I agree there are some cases where it might just be too much for the pre-processor to handle, but in your case of the auto, we can easily have an optional "auto" in the command if required. There are so many possibilities, my motto will be that when you see repetition investigate the possibility to create a #command to ease the amount of typing.
Jack
______________________
Johan Nel
Boshof, South Africa
