Re: [lazarus] Need ideas: Visual Form inheritance
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
Re: [lazarus] Need ideas: Visual Form inheritance
On Thu, 05 Oct 2006 10:45:25 +0200 Marc Weustink [EMAIL PROTECTED] wrote: [...] 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 Begin/EndUpdate and notifications are a good idea and needed. I'm just unhappy, that there is no more elegant solution for copying the data to the descendants. Mattias _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Need ideas: Visual Form inheritance
Mattias Gaertner wrote: On Thu, 05 Oct 2006 10:45:25 +0200 Marc Weustink [EMAIL PROTECTED] wrote: [...] 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 Begin/EndUpdate and notifications are a good idea and needed. I'm just unhappy, that there is no more elegant solution for copying the data to the descendants. It may be the case, but, what would a elegant way help if it isn't used that often. I mean, you need this to be able to efficiently update descendant forms. How often will one edit ancestor while descendants are open. So question is, is the efford needed Marc _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Need ideas: Visual Form inheritance
On Thu, 05 Oct 2006 11:50:03 +0200 Marc Weustink [EMAIL PROTECTED] wrote: Mattias Gaertner wrote: On Thu, 05 Oct 2006 10:45:25 +0200 Marc Weustink [EMAIL PROTECTED] wrote: [...] 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 Begin/EndUpdate and notifications are a good idea and needed. I'm just unhappy, that there is no more elegant solution for copying the data to the descendants. It may be the case, but, what would a elegant way help if it isn't used that often. I mean, you need this to be able to efficiently update descendant forms. How often will one edit ancestor while descendants are open. So question is, is the efford needed Don't forget: The default is to open the form when opening the unit. I disabled this 'feature' and I guess you too. And I know many users, who keep many units open. That's why I think, when people edit an ancestor at least one descendant will be open. Mattias _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Need ideas: Visual Form inheritance
On 05/10/06, Mattias Gaertner [EMAIL PROTECTED] wrote: Don't forget: The default is to open the form when opening the unit. I disabled this 'feature' and I guess you too. I always found this annoying, but never knew you could change it's behaviour. Hey, maybe we should change the default to be off. F12 is just one keypress away when needed. Graeme. _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Need ideas: Visual Form inheritance
On Tue, 3 Oct 2006, Mattias Gaertner wrote: On Mon, 2 Oct 2006 23:41:43 +0200 Graeme Geldenhuys [EMAIL PROTECTED] wrote: On 02/10/06, Marc Weustink [EMAIL PROTECTED] wrote: The observer pattern will work here. Every descendant subscribes itself to a change notification. IIRC, the ancestor knows when something is changed (you need this enyway to reflect changes in the desinger). So when changes the ancestor notifies its observers, which reload them selves. That the ancestor can be edited in severla ways, doesn't matter in this case. Yes. Note: The IDE is notified after something has changed, not before. Marc Ok, and any idea how we can optomize the subscribers Update method, so they can know what changed. Normally the subject calls the Update method of all it's subscribers passing itself as a parameter. Maybe we could pass a second parameter (data object - maybe a list of some sorts) containing the names of the components that changed. Even a TStringList might do. Just another thought. 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. _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Need ideas: Visual Form inheritance
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. Regards, - Graeme - _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Need ideas: Visual Form inheritance
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. Mattias _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Need ideas: Visual Form inheritance
On Tue, 3 Oct 2006, Mattias Gaertner wrote: On Mon, 2 Oct 2006 21:58:14 +0200 (CEST) Michael Van Canneyt [EMAIL PROTECTED] wrote: On Mon, 2 Oct 2006, Mattias Gaertner wrote: Hi all, I want to implement visual form inheritance, but there is one problem, for which I don't see a good solution. The situation: Both the ancestor and descendant forms are open in the IDE. The Problem: When the ancestor is edited, then the descendants need to be updated. The ancestor can be edited by: Object Inspector: Here we can add detailed notifications if needed. Designer: the same. Anchor Editor: the same. Some more tools: the same. Component Editors: These can alter the component in various ways. They only notify by an unspecific Modified event. Experts: Same as Component Editors. Descendants are loaded by applying first the ancestor values (.lfm) and then the descendant overrides. You can not clear/reset a component. You can only destroy it and create it again. You don't need to ? You just need to re-read the changed properties. Example: Form1 - Button 1. Form2 - Descendent of Form 1. On Form2 I change the caption of Button 1. I change the location of button 1 on form 1. On form2 the location is also changed to match the location of the button on form1, but the caption remains changed. So all you need to do is to: 1. Stream the parent component (button1 on form1) Do you mean, after the change of the caption, don't you? Yes, and after the change of location. 2. Apply this stream to the descendent component (button1 on form2). 3. Apply the previous inherited stream to the descendent component. What do you mean with 'previous inherited stream'? The stream of the descendent form as it was before point 2. Or am I missing something ? It's not necessary to stream the whole form ? The problem are the default values. If you change the Form1.Button1.Caption back to the default value, it won't be saved to the stream. When this stream is loaded by Form2.Button1 the Caption remains unchanged. Or am I missing something? I checked in delphi, and the default value is propagated. I think that it should be done differently: - if you change a value of a property in the object inspector, The IDE should check whether any descendent is open, and apply the changed value to any inherited components, if the original value was the same. So: - Store current value of property. - Change value - for all inherited components in the IDE. Set property value if original value was the same. - If you do it through a component editor, there is no alternative but to scan all properties and apply the changed properties. The case where the descendent is not opened in the IDE you should not consider, since then the streaming will take care of it anyway... Michael. _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Need ideas: Visual Form inheritance
On Wed, 4 Oct 2006 08:59:32 +0200 (CEST) Michael Van Canneyt [EMAIL PROTECTED] wrote: [...] Ok, and any idea how we can optomize the subscribers Update method, so they can know what changed. Normally the subject calls the Update method of all it's subscribers passing itself as a parameter. Maybe we could pass a second parameter (data object - maybe a list of some sorts) containing the names of the components that changed. Even a TStringList might do. Just another thought. 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... ? Not necessarily, but I *think* this is so rare, we could live with it and instead fix the component to allow this scheme. The above would be an optimization to not stream the whole forms every time. But there is still the 'default values' problem: If an ancestor property is changed to the default value it is not written to the stream. So applying this stream to the descendants does not change the property in the descendants. Mattias _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Need ideas: Visual Form inheritance
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? Mattias _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Need ideas: Visual Form inheritance
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; Marc _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Need ideas: Visual Form inheritance
On Wed, 4 Oct 2006 12:24:21 +0200 (CEST) Michael Van Canneyt [EMAIL PROTECTED] wrote: On Tue, 3 Oct 2006, Mattias Gaertner wrote: On Mon, 2 Oct 2006 21:58:14 +0200 (CEST) Michael Van Canneyt [EMAIL PROTECTED] wrote: On Mon, 2 Oct 2006, Mattias Gaertner wrote: Hi all, I want to implement visual form inheritance, but there is one problem, for which I don't see a good solution. The situation: Both the ancestor and descendant forms are open in the IDE. The Problem: When the ancestor is edited, then the descendants need to be updated. The ancestor can be edited by: Object Inspector: Here we can add detailed notifications if needed. Designer: the same. Anchor Editor: the same. Some more tools: the same. Component Editors: These can alter the component in various ways. They only notify by an unspecific Modified event. Experts: Same as Component Editors. Descendants are loaded by applying first the ancestor values (.lfm) and then the descendant overrides. You can not clear/reset a component. You can only destroy it and create it again. You don't need to ? You just need to re-read the changed properties. Example: Form1 - Button 1. Form2 - Descendent of Form 1. On Form2 I change the caption of Button 1. I change the location of button 1 on form 1. On form2 the location is also changed to match the location of the button on form1, but the caption remains changed. So all you need to do is to: 1. Stream the parent component (button1 on form1) Do you mean, after the change of the caption, don't you? Yes, and after the change of location. 2. Apply this stream to the descendent component (button1 on form2). 3. Apply the previous inherited stream to the descendent component. What do you mean with 'previous inherited stream'? The stream of the descendent form as it was before point 2. Ah. This is another interesting point. How do you get that? The descendant stream is created by using an ancestor instance. So, to create the old stream, you must stream the descendant with an ancestor instance *after* the descendant was changed and *before* the ancestor is changed. At the moment we don't have an event for *before* ancestor is changed. And it would be quite slow, to stream/save the descendant after every change. Hmm. Maybe using a second ancestor instance could solve some problems. Or am I missing something ? It's not necessary to stream the whole form ? The problem are the default values. If you change the Form1.Button1.Caption back to the default value, it won't be saved to the stream. When this stream is loaded by Form2.Button1 the Caption remains unchanged. Or am I missing something? I checked in delphi, and the default value is propagated. What do you mean with propagated? In the RTTI? Maybe my term 'default' values was a bad choice, as there is a 'default' property value. I meant the value that is not stored to the stream. This is defined by the default property value and the *stored* function. The default value I was talking is the value, when the component is created. This is not necessarily the default property value. Maybe better: 'not stored' value. I think that it should be done differently: - if you change a value of a property in the object inspector, The IDE should check whether any descendent is open, and apply the changed value to any inherited components, if the original value was the same. So: - Store current value of property. - Change value - for all inherited components in the IDE. Set property value if original value was the same. Yes, this could be done for the OI. And something like that for the anchor editor. And something more complex for the collection editor. And something more complex for the designer moving. But what about the 20 component and property editors that uses special techniques to alter the component? And the third party component and property editors? - If you do it through a component editor, there is no alternative but to scan all properties and apply the changed properties. What about DefineProperties? The case where the descendent is not opened in the IDE you should not consider, since then the streaming will take care of it anyway... Yes, this thread is only about having both open. Mattias _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Need ideas: Visual Form inheritance
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; Mattias _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Need ideas: Visual Form inheritance
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. Marc _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Need ideas: Visual Form inheritance
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. Mattias _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Need ideas: Visual Form inheritance
On Mon, 2 Oct 2006 21:58:14 +0200 (CEST) Michael Van Canneyt [EMAIL PROTECTED] wrote: On Mon, 2 Oct 2006, Mattias Gaertner wrote: Hi all, I want to implement visual form inheritance, but there is one problem, for which I don't see a good solution. The situation: Both the ancestor and descendant forms are open in the IDE. The Problem: When the ancestor is edited, then the descendants need to be updated. The ancestor can be edited by: Object Inspector: Here we can add detailed notifications if needed. Designer: the same. Anchor Editor: the same. Some more tools: the same. Component Editors: These can alter the component in various ways. They only notify by an unspecific Modified event. Experts: Same as Component Editors. Descendants are loaded by applying first the ancestor values (.lfm) and then the descendant overrides. You can not clear/reset a component. You can only destroy it and create it again. You don't need to ? You just need to re-read the changed properties. Example: Form1 - Button 1. Form2 - Descendent of Form 1. On Form2 I change the caption of Button 1. I change the location of button 1 on form 1. On form2 the location is also changed to match the location of the button on form1, but the caption remains changed. So all you need to do is to: 1. Stream the parent component (button1 on form1) Do you mean, after the change of the caption, don't you? 2. Apply this stream to the descendent component (button1 on form2). 3. Apply the previous inherited stream to the descendent component. What do you mean with 'previous inherited stream'? Or am I missing something ? It's not necessary to stream the whole form ? The problem are the default values. If you change the Form1.Button1.Caption back to the default value, it won't be saved to the stream. When this stream is loaded by Form2.Button1 the Caption remains unchanged. Or am I missing something? Mattias _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Need ideas: Visual Form inheritance
On Mon, 2 Oct 2006 23:41:43 +0200 Graeme Geldenhuys [EMAIL PROTECTED] wrote: On 02/10/06, Marc Weustink [EMAIL PROTECTED] wrote: The observer pattern will work here. Every descendant subscribes itself to a change notification. IIRC, the ancestor knows when something is changed (you need this enyway to reflect changes in the desinger). So when changes the ancestor notifies its observers, which reload them selves. That the ancestor can be edited in severla ways, doesn't matter in this case. Yes. Note: The IDE is notified after something has changed, not before. Marc Ok, and any idea how we can optomize the subscribers Update method, so they can know what changed. Normally the subject calls the Update method of all it's subscribers passing itself as a parameter. Maybe we could pass a second parameter (data object - maybe a list of some sorts) containing the names of the components that changed. Even a TStringList might do. Just another thought. Changing a property can change various others as well. For example changing the Width can change child controls, siblings and parent. Mattias _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
[lazarus] Need ideas: Visual Form inheritance
Hi all, I want to implement visual form inheritance, but there is one problem, for which I don't see a good solution. The situation: Both the ancestor and descendant forms are open in the IDE. The Problem: When the ancestor is edited, then the descendants need to be updated. The ancestor can be edited by: Object Inspector: Here we can add detailed notifications if needed. Designer: the same. Anchor Editor: the same. Some more tools: the same. Component Editors: These can alter the component in various ways. They only notify by an unspecific Modified event. Experts: Same as Component Editors. Descendants are loaded by applying first the ancestor values (.lfm) and then the descendant overrides. You can not clear/reset a component. You can only destroy it and create it again. To save the descendant values you need an ancestor instance to find the differences/overrides and write them to the .lfm. And last but not least: Saving/Loading a component can take long, if it contains special data like images and lists. Mattias _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Need ideas: Visual Form inheritance
To add to that, I suggested to Mattias using something like the Observer pattern, but I find it difficult to see how we could trigger the Notify event of the Subject (ancestor form), with so many places that the ancestor form can be modified form. So this might not be a solution, just though I would mention it anyway. Maybe it sparks some other ideas. ;-) Regards, - Graeme - On 02/10/06, Mattias Gaertner [EMAIL PROTECTED] wrote: Hi all, I want to implement visual form inheritance, but there is one problem, for which I don't see a good solution. The situation: Both the ancestor and descendant forms are open in the IDE. The Problem: When the ancestor is edited, then the descendants need to be updated. The ancestor can be edited by: Object Inspector: Here we can add detailed notifications if needed. Designer: the same. Anchor Editor: the same. Some more tools: the same. Component Editors: These can alter the component in various ways. They only notify by an unspecific Modified event. Experts: Same as Component Editors. Descendants are loaded by applying first the ancestor values (.lfm) and then the descendant overrides. You can not clear/reset a component. You can only destroy it and create it again. To save the descendant values you need an ancestor instance to find the differences/overrides and write them to the .lfm. And last but not least: Saving/Loading a component can take long, if it contains special data like images and lists. Mattias _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives -- There's no place like 127.0.0.1 _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Need ideas: Visual Form inheritance
On Mon, 2 Oct 2006, Mattias Gaertner wrote: Hi all, I want to implement visual form inheritance, but there is one problem, for which I don't see a good solution. The situation: Both the ancestor and descendant forms are open in the IDE. The Problem: When the ancestor is edited, then the descendants need to be updated. The ancestor can be edited by: Object Inspector: Here we can add detailed notifications if needed. Designer: the same. Anchor Editor: the same. Some more tools: the same. Component Editors: These can alter the component in various ways. They only notify by an unspecific Modified event. Experts: Same as Component Editors. Descendants are loaded by applying first the ancestor values (.lfm) and then the descendant overrides. You can not clear/reset a component. You can only destroy it and create it again. You don't need to ? You just need to re-read the changed properties. Example: Form1 - Button 1. Form2 - Descendent of Form 1. On Form2 I change the caption of Button 1. I change the location of button 1 on form 1. On form2 the location is also changed to match the location of the button on form1, but the caption remains changed. So all you need to do is to: 1. Stream the parent component (button1 on form1) 2. Apply this stream to the descendent component (button1 on form2). 3. Apply the previous inherited stream to the descendent component. Or am I missing something ? It's not necessary to stream the whole form ? Michael. _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Need ideas: Visual Form inheritance
Graeme Geldenhuys wrote: To add to that, I suggested to Mattias using something like the Observer pattern, but I find it difficult to see how we could trigger the Notify event of the Subject (ancestor form), with so many places that the ancestor form can be modified form. So this might not be a solution, just though I would mention it anyway. Maybe it sparks some other ideas. ;-) The observer pattern will work here. Every descendant subscribes itself to a change notification. IIRC, the ancestor knows when something is changed (you need this enyway to reflect changes in the desinger). So when changes the ancestor notifies its observers, which reload them selves. That the ancestor can be edited in severla ways, doesn't matter in this case. Marc Regards, - Graeme - On 02/10/06, Mattias Gaertner [EMAIL PROTECTED] wrote: Hi all, I want to implement visual form inheritance, but there is one problem, for which I don't see a good solution. The situation: Both the ancestor and descendant forms are open in the IDE. The Problem: When the ancestor is edited, then the descendants need to be updated. The ancestor can be edited by: Object Inspector: Here we can add detailed notifications if needed. Designer: the same. Anchor Editor: the same. Some more tools: the same. Component Editors: These can alter the component in various ways. They only notify by an unspecific Modified event. Experts: Same as Component Editors. Descendants are loaded by applying first the ancestor values (.lfm) and then the descendant overrides. You can not clear/reset a component. You can only destroy it and create it again. To save the descendant values you need an ancestor instance to find the differences/overrides and write them to the .lfm. And last but not least: Saving/Loading a component can take long, if it contains special data like images and lists. Mattias _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Need ideas: Visual Form inheritance
On 02/10/06, Marc Weustink [EMAIL PROTECTED] wrote: The observer pattern will work here. Every descendant subscribes itself to a change notification. IIRC, the ancestor knows when something is changed (you need this enyway to reflect changes in the desinger). So when changes the ancestor notifies its observers, which reload them selves. That the ancestor can be edited in severla ways, doesn't matter in this case. Marc Ok, and any idea how we can optomize the subscribers Update method, so they can know what changed. Normally the subject calls the Update method of all it's subscribers passing itself as a parameter. Maybe we could pass a second parameter (data object - maybe a list of some sorts) containing the names of the components that changed. Even a TStringList might do. Just another thought. Regards, - Graeme - _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
