Mattias Gaertner wrote:
On Wed, 04 Oct 2006 13:38:03 +0200
Marc Weustink <[EMAIL PROTECTED]> wrote:
Mattias Gaertner wrote:
On Wed, 04 Oct 2006 12:46:27 +0200
Marc Weustink <[EMAIL PROTECTED]> wrote:
Mattias Gaertner wrote:
On Wed, 04 Oct 2006 11:29:51 +0200
Marc Weustink <[EMAIL PROTECTED]> wrote:
Mattias Gaertner wrote:
On Wed, 4 Oct 2006 09:27:03 +0200
"Graeme Geldenhuys" <[EMAIL PROTECTED]> wrote:
Changing a property can change various others as well. For
example changing the Width can change child controls,
siblings and parent.
Yes, but applying this change to the child form should result
in exactly the same consequences, unless the affected
components were changed already... ?
Michael.
Mattias,
This is where my implementation of the Observer using
BeginUpdate and EndUpdate plays a roll. See the tiOPF code I
sent you. Normally the Subject (FormA) would fire off the
Notify method for every small change which could cause lots of
screen redraws. BeginUpdate and EndUpdate allows you to make
all those small changes and then fire off a single Notify call.
BeginUpdate can only be called for the IDE tools (OI, AE, ...).
The component editors will only call the Modified event.
But there is a solution:
We could call the update on Idle.
Not really a nice option and hard to work with if some who knows
future designer plugin needs the result of a modification (I'm
just making things up here).
Then the plugin can force an update.
But...
component editors call Modified. This Modified method can use
Begin/EndModification. If this is passed to the
"derived form" observer, it knows whan all modifications are done
(and can update itself)
Do you mean, all methods, that now call the Modified method should
be changed to call Begin/EndModification?
No,
Modified needs to be modified :)
procedure Modified;
begin
SendBeginModificationToAllBeginEndObeservers;
SendModifiedNotificationToAllModifiedObeservers;
SendEndModificationToAllBeginEndObeservers;
end;
But then Begin/End is useless, isn't it? The modification took place
before 'Begin'. For example:
NewToolButton.Parent:=CurToolBar;
Modified;
Indeed, I was more thinking of controls reacting on the
ModifiedNotification which would trigger more modifications.
In your example, an editor sets the Parent and calls Modified. Why
would setting the parent trigger other code which will call
Modified ? Afterall, Modified is a Designer/Editor method, and
should/can not be called from the component itself. So I see no chain
of modified there.
There are some components, that call Modified. For example
changing the PageIndex of a TNoteBook. But this is very rare and can be
changed. Let's ignore these things.
More important is that we don't have a working Begin/End enclosement.
So, we can only react, but not prepare. Or in other words: Only a
OnModified event, but no OnChanging.
At the moment the solution is to swallow the bitter pill and implement
a dynamic property propagation system. The more information the
changer (e.g. OI) provides, the less the system will copy.
The OI can call BeginUpdate/ChangeProperty/EndUpdate, while others
can call Modified and the whole forms are scanned/copied.
Whats wrong with adapting modified ?
That is the difference of having one OnModified, or having observers
which subscribe themselves to begen/end notifications
Marc
_________________________________________________________________
To unsubscribe: mail [EMAIL PROTECTED] with
"unsubscribe" as the Subject
archives at http://www.lazarus.freepascal.org/mailarchives
