[fpc-devel] Interface delegation fix: backport to FPC 2.4.2 ...?
graemeg.lists at gmail.com
Thu May 20 12:18:52 CEST 2010
Florian Klaempfl het geskryf:
> Can you give a real world example what you want to do with it?
* This applies to fpGUI's implementation. TfpgAction can be observer by
other components like TfpgButton, TfpgMenuItem etc.. The Action instance is
changed, and the observers are notified about this change automatically. No
need for a parallel hierarchy like TBasicActionLink and the family of
* A text editor which uses TStrings as a buffer (property Lines).
Scrollbars and Gutter can observe the Editor.Lines property and adjust
accordingly as the content of Editor.Lines change. Similar applies to
* A StringGrid component observes a Dataset. As records/fields change in
the dataset, so the grid is automatically updated. No need for DB-aware
components. This can be applied to any components (TLabel, TEdit, TComboBox
* You have a business object that is based off TPersistent. This business
object represents a business report. You have two windows each with a
TChart component displaying visually the results of that report (say a line
chart and a pie chart). The two TChart components are observers of the
business object. As the business object's data changes the two reports are
automatically updated (a nice "what if" scenario like often done in
* A spellchecker component observers the TMemo.Lines property. As the Lines
property changes the spellchecker get notified and knows exactly what line
was modified and can spellcheck that specific line only. The notification
system also gives the reason for the change: was it a simple line change,
line addition, line removal etc.. The Spellchecker can then act accordingly.
These are just a few things I would like to implement in our applications.
I am sure, given sufficient time, I can think of a lot more real-world uses.
- Graeme -
fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal
More information about the fpc-devel