On 20/05/2010, Henry Vermaak wrote: > enough technical basis, you will convince people. Like Linus says, > talk is cheap, show me the code.
You are welcome to look at the tiOPF code. http://sourceforge.net/projects/tiopf/ I also attached a simplified example to my previous reply to Macro and code to show how it would attach to a base class and how to use it. Talk IS cheap, so see the code. :-) > disagreeing. The point was that it opens the door for a lot of other > (perhaps questionable) stuff to weasel its way into the base classes With that we should ban all modifications to FPC code because it might introduce bugs or break something. Pointless! Why not handle each "future enhancement" on a case by case basis IF they are ever suggested, and not simply ban all enhancements on a "what if" scenario. I think Michael and I have given sufficient benefits to this idea, and seeing that nobody else has proposed a better alternative (and reimplementing the RTL, FCL, LCL, fpGUI is *not* an alternative), I see no reason why this cannot be added. > Anyway, I do hope that there is a feasible to implement this, because > the observer pattern is very powerful. I'm confused. One minute it sounds like you are saying no it's a bad idea, then the next paragraph you say is this is a good idea? :) Anyway, review the code I supplied earlier and what is available in tiOPF. Even run Demo 21 of tiOPF to see how a complete Address Book application is implemented using a database and standard components (LCL, VCL or fpGUI) and never does it need db-aware components. Every component on every form uses Observer, and thanks to the Mediator design pattern the communication is a two-way street. -- Regards, - Graeme - _______________________________________________ fpGUI - a cross-platform Free Pascal GUI toolkit http://opensoft.homeip.net/fpgui/ _______________________________________________ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
