Hi Yan,
Hi Andreas,
Now the problems of immediate changes after modifying a key could be
solved by adding changes listener on the m_xCfg root node.
Nice to hear that. :-)
Currently one problem: the listener couldn't be notified after the
m_xCfg has been renewed in the AcceleratorConfiguration::Reset().
Because when the configuration is only reopened , but no such
operations like setPropertyValue(), insert/removeByName()...so some
instances like svtools/acceleratorexecute couldn't be notified. Shall I
implement some methods like addResetListener/removeResetListener ?
I dont think we need such special listener. Further I dont think you can
use it real. Because there is no central shortcut handler instance (you
can have many of them) you wont be listener on all those instances
really. It will end in a network of registered listener with might
recursive structure ...
If you reopen the configuration access m_xCfg of course you have to
reestablish your listener connection also. Further you use the new
m_xCfg member to reload your cache inside impl_ts_load(). So after
reset() was called your cache should be up to date.
All changes made on these shortcut instance (made before reset() was
called) are not thought to be send to any listener. Because they was not
public. Only your instance could see it ... and you decided to forget it
inside reset(). So why any other instance should be informed about that
after reset() was called ?
If notification about changes works as expected you should start to
split the current implementation into two base classes as already
discussed. So we can make our code more maintainable ... and it will be
clear which data cames from (or must be written to) (which) source/target.
Regards
Yan
Regards
Andreas
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
