TPERSISTENT hickups

[jamie]

I found that adding duplicating observers is allowed and causes multiple triggers to the observed object.

 I dont see any option to stop this or access to the list?

 Also, i'v noticed that in TStrings the notifiy observers isnt in the base so if any obersers are attached they will get processed, signaled for change, add, delete.
  If it was this way i could attached a observer to any conttol that has a Tstring object in it without modifying its code.

[cdbc]

Hi
Every 'IFPObserved' supports multiple observers attached to it.
Alas, the implementation throughout the RTL, of 'Notify' etc. is at the most, kinda like an afterthought In other words it could be a lot better, IMHO 
Regards Benny

[jamie]

Hi
Every 'IFPObserved' supports multiple observers attached to it.
Alas, the implementation throughout the RTL, of 'Notify' etc. is at the most, kind of like an afterthought  In other words it could be a lot better, IMHO 
Regards Benny

Yes I understand it may have been an afternoon thought however, the issue I am pointing at is that it allows duplicates of the same object in the list so notices get sent multiple times for the same even to the same object, that is a problem because now I have to somehow keep track locally if I have already assigned an observer to it.

 As for various controls not obeying the option It's getting into sloppy code land, and I am trying to keep this neat as possible so I can look at it at some later date and don't ask myself what I was doing that day! 

 Currently controls like the TTabcontrol, TPageControl etc, offer no simple way to alert observers or even an event that can be tied to a master form that a page/Tab has been added or deleted etc.

 These controls I have barried deep has a reference to such controls in dynamically created objects in things like Generic Lists etc., and I need a clear way to talk to the main form, currently it looks like a mess!

 I was thinking on the lines of posting messages however, it seems the LCL widgets have some limits and blocks many uncommon messages along with the OS (windows) with options to filter messages. the WM_COPYDATA comes to mind, but I really don't need cross process linking this way, I can do those other ways like with local sockets etc.

Jamie

[cdbc]

Hi jamie
I find that built-in observer-framework too limited, so I rolled my own, which is way more flexible and checks if the observer has already subscribed, before letting it subscribe...
You can have a looksee in the attachment 
Regards Benny

eta: It's AMO. used in my MVP-framework, marshalling all the comms towards the 'View'(s)

[jamie]

I looked at it 

Looks good, but I would still need to replace the TOBJECT with TPersistent because I still need the Assign and AssignTo functionality.

I could pretty much ignore the current implementation there I guess.
 

[jamie]

I can fix whatever issues in classes that are not part of the LCL drag and drop operation, but it would be nice if GUI objects that employ TSTRINGS to integrate what is already in the TPERSISTENT which is there doing nothing but maybe using the Assign and AssignTo.

 For example, The TNBOPage class, and the TPages class within the Tab controls could support that forward triggering, in case there are any assignments there.

 Currently I can give them the observer but the code within never sends any notifications just in case there are any listeners in the list.

  I am sure there are many that have forgotten about it and never even knew they existed!

 I even took a shoot at using TActions and TActionlist, even those have been road blocked from any easy usage if you plan on using the OI, you will need to create your own subclasses of them and use the TBASEACTIOn class.

 Frankly, I've never really found a lot of use for TActions.

Jamie