BorlandTalk.com Borland discussion newsgroups   Archives   FAQ   Search   Memberlist   Usergroups   Register   Profile   Log in to check your private messages   Log in  Objects and TreeViews Goto page 1, 2  Next          BorlandTalk.com Forum Index -> Delphi OO design View previous topic :: View next topic   Author Message Martin Guest Posted: Wed Jan 07, 2004 9:43 am    Post subject: Objects and TreeViews Hi there, I have an app with an OO approach where I use a TreeView as interface. Each object handles its own popup menus, methods and so on. My problem is that I after certain operations want to update the TreeView to reflect the changes. The reloading of the tree involves freeing all objects and reloading them from the db by calling a refresh method in a parent object. This will always cause a runtime error as the object calling the reload is ultimately free'd itself before the method is ended and control returned to the calling object. My problem is, put otherwise, that I can call refresh methods in child objects but not in parent objects, and this makes it impossible to visually reflect certain changes made to the object itself (a typical change wld be the display order of this node among its same level nodes). Thanks in advance, /Martin Back to top Joanna Carter (TeamB) Guest Posted: Wed Jan 07, 2004 12:51 pm    Post subject: Re: Objects and TreeViews Martin wrote: Quote: Hi there, I have an app with an OO approach where I use a TreeView as interface. Each object handles its own popup menus, methods and so on. My problem is that I after certain operations want to update the TreeView to reflect the changes. The reloading of the tree involves freeing all objects and reloading them from the db by calling a refresh method in a parent object. This will always cause a runtime error as the object calling the reload is ultimately free'd itself before the method is ended and control returned to the calling object. My problem is, put otherwise, that I can call refresh methods in child objects but not in parent objects, and this makes it impossible to visually reflect certain changes made to the object itself (a typical change wld be the display order of this node among its same level nodes). If I were you I would make all the objects in the tree Subjects to the Observer Pattern. Then Have a 'TreeWatcher' class external to the TreeView that Observes the objects and refreshes the tree from outside. You just have to remember to Detach any Observers from each Subject in its destructor. Joanna -- Joanna Carter (TeamB) Consultant Software Engineer TeamBUG support for UK-BUG TeamMM support for ModelMaker Back to top Gerrit Beuze Guest Posted: Wed Jan 07, 2004 2:35 pm    Post subject: Re: Objects and TreeViews Hello Martin, Usually this stategy works for me: const WM_OBJECTCHANGE = WM_USER + 0; procedure TForm1.ObjectChanged(Sender: TObject); begin if This_would_cause_an_av then PostMessage(Handle, WM_OBJECTCHANGE + 0, 0, 0) else // Handle changes end; procedure TForm1.WMObjectChange(var Msg: TMessage); // is a WM_OBJECTCHANGE message handler begin // Decoupled Rebuild here. end; Gerrit Beuze ModelMaker Tools "Martin" <martin.agren (AT) goteborgslokaler (DOT) se> wrote Quote: Hi there, I have an app with an OO approach where I use a TreeView as interface. Each object handles its own popup menus, methods and so on. My problem is that I after certain operations want to update the TreeView to reflect the changes. The reloading of the tree involves freeing all objects and reloading them from the db by calling a refresh method in a parent object. This will always cause a runtime error as the object calling the reload is ultimately free'd itself before the method is ended and control returned to the calling object. My problem is, put otherwise, that I can call refresh methods in child objects but not in parent objects, and this makes it impossible to visually reflect certain changes made to the object itself (a typical change wld be the display order of this node among its same level nodes). Thanks in advance, /Martin Back to top martin Guest Posted: Wed Jan 07, 2004 6:26 pm    Post subject: Re: Objects and TreeViews "Joanna Carter (TeamB)" <joannac (AT) btinternetXX (DOT) com> wrote: Quote: Martin wrote: | Hi there, | I have an app with an OO approach where I use a TreeView as | interface. Each object handles its own popup menus, methods | and so on. | My problem is that I after certain operations want to update | the TreeView to reflect the changes. | The reloading of the tree involves freeing all objects and | reloading them from the db by calling a refresh method in a | parent object. | This will always cause a runtime error as the object calling | the reload is ultimately free'd itself before the method is | ended and control returned to the calling object. | My problem is, put otherwise, that I can call refresh methods | in child objects but not in parent objects, and this makes it | impossible to visually reflect certain changes made to the | object itself (a typical change wld be the display order of | this node among its same level nodes). If I were you I would make all the objects in the tree Subjects to the Observer Pattern. Then Have a 'TreeWatcher' class external to the TreeView that Observes the objects and refreshes the tree from outside. You just have to remember to Detach any Observers from each Subject in its destructor. Joanna -- Joanna Carter (TeamB) Consultant Software Engineer TeamBUG support for UK-BUG TeamMM support for ModelMaker Thanks Joanna, but could you develop this a little bit further. I looked up the observer mechanism and understand what you mean, but one of the reasons I don't use a refresh mechanism on existing objects, but rather reload the entire tree, is that it is general - it includes newly created objects as well as modifications done to existing and guarantees that objects are always on line with the database. But anyhow, please explain further.. /Martin Back to top Joanna Carter (TeamB) Guest Posted: Wed Jan 07, 2004 10:01 pm    Post subject: Re: Objects and TreeViews martin wrote: Quote: Thanks Joanna, but could you develop this a little bit further. I looked up the observer mechanism and understand what you mean, but one of the reasons I don't use a refresh mechanism on existing objects, but rather reload the entire tree, is that it is general - it includes newly created objects as well as modifications done to existing and guarantees that objects are always on line with the database. But anyhow, please explain further.. On second thoughts; follow Gerrit's advice. My solution would have caused the same problem. :-) Joanna -- Joanna Carter (TeamB) Consultant Software Engineer TeamBUG support for UK-BUG TeamMM support for ModelMaker Back to top Tony J Hopkinson Guest Posted: Wed Jan 07, 2004 10:18 pm    Post subject: Re: Objects and TreeViews On 7 Jan 2004 02:43:19 -0700, "Martin" <martin.agren (AT) goteborgslokaler (DOT) se> wrote: Quote: Hi there, I have an app with an OO approach where I use a TreeView as interface. Each object handles its own popup menus, methods and so on. My problem is that I after certain operations want to update the TreeView to reflect the changes. The reloading of the tree involves freeing all objects and reloading them from the db by calling a refresh method in a parent object. This will always cause a runtime error as the object calling the reload is ultimately free'd itself before the method is ended and control returned to the calling object. My problem is, put otherwise, that I can call refresh methods in child objects but not in parent objects, and this makes it impossible to visually reflect certain changes made to the object itself (a typical change wld be the display order of this node among its same level nodes). Thanks in advance, /Martin I did something like this once I maintained this the list of objects in a tlist descendant. This class owned the objects. the objects had a ttreenode property and on a change they update the tree and then set it's data property to point to the relevant member in the list. It was a while ago but basically a tree of customers -> Orders with a property. This property could be set at customer level so all orders would be set or for an individual order. It was a progress state, context menus came up allowing you to move to other valid states and parent nodes images were changed to indicate the state of their children. Still got it somewhere if you want it. The key thing was te object didn't rebuild the tree, the list class that owned it did and that always exists so the problem you are getting didn't occur. Back to top Peter Morris [Droopy Eyes Guest Posted: Wed Jan 07, 2004 10:43 pm    Post subject: Re: Objects and TreeViews Freeing an object from within one of its own events is only a problem if the method which invokes the event tries to access instance members afterwards, eg. //This is fine procedure TMyObject.DoSomething; begin if Assigned(OnSomething) then OnSomething(Self); end; //This is not good procedure TMyObject.DoSomething; begin if Assigned(OnSomething) then OnSomething(Self); if SomeMember = 32 then DoSomethingElse; end; As long as your code never touches an instance member it is safe to free it. -- Pete ============= http://www.DroopyEyes.com - Delphi source code Audio compression components, Fast Strings, DIB Controls Read or write article on just about anything http://www.HowToDoThings.com Back to top Bryan Crotaz Guest Posted: Thu Jan 08, 2004 2:44 am    Post subject: Re: Objects and TreeViews Quote: If I were you I would make all the objects in the tree Subjects to the Observer Pattern. Then Have a 'TreeWatcher' class external to the TreeView that Observes the objects and refreshes the tree from outside. You just have to remember to Detach any Observers from each Subject in its destructor. I'm using the freeware TVirtualTree to do exactly this. I have a TWrapperTreeNode that is pointed to (and owned) by the TVT treenode. This is responsible for creating and destroying child nodes, and observes the object it visualises. In my system if an object is destroyed it informs its parent via subject-observer, and the parent treenode then gets a ChildListChanged notification message, so it doesn't need to free itself, but instead its children. It works fine for me. Bryan Back to top Joanna Carter (TeamB) Guest Posted: Thu Jan 08, 2004 8:52 am    Post subject: Re: Objects and TreeViews Bryan Crotaz wrote: Quote: I have a TWrapperTreeNode that is pointed to (and owned) by the TVT treenode. This is responsible for creating and destroying child nodes, and observes the object it visualises. In my system if an object is destroyed it informs its parent via subject-observer, and the parent treenode then gets a ChildListChanged notification message, so it doesn't need to free itself, but instead its children. I think the problem is that Martin wants to update the whole tree and this means that however you use the objects attached to the tree, the one that caused the tree to become invalid will be freed by the external method before it has finished executing the method it is in that calls the external observer. Gerrit's idea of a windows message posted to the end of the queue should deal with this. Joanna -- Joanna Carter (TeamB) Consultant Software Engineer TeamBUG support for UK-BUG TeamMM support for ModelMaker Back to top martin Guest Posted: Thu Jan 08, 2004 12:38 pm    Post subject: Re: Objects and TreeViews OK, starting to get close to what I look for, I think. In my child object a method could look like this procedure TMyObject.Delete; begin DoSomethingWithMySelf; self.parent.refresh; //Calls parent objects refresh method which frees all its //children. Parent object then reloads it's children from db. //This causes an error. end; If I instead would notify the parent with an event it would work, you mean? /Martin "Peter Morris [Droopy Eyes Software]" <support (AT) _nospam_ (DOT) com> wrote: Quote: Freeing an object from within one of its own events is only a problem if the method which invokes the event tries to access instance members afterwards, eg. //This is fine procedure TMyObject.DoSomething; begin if Assigned(OnSomething) then OnSomething(Self); end; //This is not good procedure TMyObject.DoSomething; begin if Assigned(OnSomething) then OnSomething(Self); if SomeMember = 32 then DoSomethingElse; end; As long as your code never touches an instance member it is safe to free it. -- Pete ============= http://www.DroopyEyes.com - Delphi source code Audio compression components, Fast Strings, DIB Controls Read or write article on just about anything http://www.HowToDoThings.com Back to top martin Guest Posted: Thu Jan 08, 2004 2:16 pm    Post subject: Re: Objects and TreeViews 2 (continued) And could this event mechanism be set up so that an event triggered from a child object only reaches the parent object? (All parent objects must register interest in their child's event, I guess.. And the Windows message wld be the same for all objects.. Excuse the ignorance, this is new to me) /Martin "Peter Morris [Droopy Eyes Software]" <support (AT) _nospam_ (DOT) com> wrote: Quote: Freeing an object from within one of its own events is only a problem if the method which invokes the event tries to access instance members afterwards, eg. //This is fine procedure TMyObject.DoSomething; begin if Assigned(OnSomething) then OnSomething(Self); end; //This is not good procedure TMyObject.DoSomething; begin if Assigned(OnSomething) then OnSomething(Self); if SomeMember = 32 then DoSomethingElse; end; As long as your code never touches an instance member it is safe to free it. -- Pete ============= http://www.DroopyEyes.com - Delphi source code Audio compression components, Fast Strings, DIB Controls Read or write article on just about anything http://www.HowToDoThings.com Back to top Tony J Hopkinson Guest Posted: Thu Jan 08, 2004 4:27 pm    Post subject: Re: Objects and TreeViews 2 On 8 Jan 2004 07:16:59 -0700, "martin" <martin.agren (AT) goteborgslokaler (DOT) se> wrote: Quote: (continued) And could this event mechanism be set up so that an event triggered from a child object only reaches the parent object? (All parent objects must register interest in their child's event, I guess.. And the Windows message wld be the same for all objects.. Excuse the ignorance, this is new to me) snip Seeing as you are sending a user defined message, only those components where you put in a message handler and process it will do anything if I understood you right earlier you were clearing the entire tree, so the recipient of the message (the one with the handler) would be the tree itself. It could be an other component capable of receiving messages, even the form itself, receiving the message and then calling the routine to build the tree, though that would tie you to the form, a descendant of the tree component would be more re-usable. P.S. don't forget to set handled to true in the routines that does do it. Back to top martin Guest Posted: Thu Jan 08, 2004 6:47 pm    Post subject: Re: Objects and TreeViews "Bryan Crotaz" <bryan@%nospam%ivisionsystems.com> wrote: Quote: I think the problem is that Martin wants to update the whole tree and this Yes, that would cause a problem, and that's the way I did it initially. But it's much more efficient to only update part of the tree, and it also avoids this nasty completely. Bryan Actually I don't want to update the entire tree, but rather the part of the tree that starts with the parent of the object in question. But the "reload" method of this parent object works by freeing all children and then reloading them from the db. And thus causes an error as the reload method has to be called from the child object. /M Back to top Bryan Crotaz Guest Posted: Thu Jan 08, 2004 7:32 pm    Post subject: Re: Objects and TreeViews Quote: I think the problem is that Martin wants to update the whole tree and this Yes, that would cause a problem, and that's the way I did it initially. But it's much more efficient to only update part of the tree, and it also avoids this nasty completely. Bryan Back to top Bryan Crotaz Guest Posted: Fri Jan 09, 2004 1:01 am    Post subject: Re: Objects and TreeViews "martin" <martin.agren (AT) goteborgslokaler (DOT) se> wrote Quote: "Bryan Crotaz" <bryan@%nospam%ivisionsystems.com> wrote: I think the problem is that Martin wants to update the whole tree and this Yes, that would cause a problem, and that's the way I did it initially. But it's much more efficient to only update part of the tree, and it also avoids this nasty completely. Bryan Actually I don't want to update the entire tree, but rather the part of the tree that starts with the parent of the object in question. But the "reload" method of this parent object works by freeing all children and then reloading them from the db. And thus causes an error as the reload method has to be called from the child object. Hmmm. Either change your notification system so it's the parent list that notifies the tree, or possibly everyone could think about this... Why do we get an AV here? The code part of the mem allocation hasn't gone away, only the mem for the object instance data. Ergo my thinking is... if the call to Parent.RedoChildren is the last line of the child's method, this would mean that there were no attempts to access the child *data* after the object was freed by the parent.... Is this correct? Bryan Back to top Display posts from previous: All Posts1 Day7 Days2 Weeks1 Month3 Months6 Months1 Year Oldest FirstNewest First         BorlandTalk.com Forum Index -> Delphi OO design All times are GMT Goto page 1, 2  Next Page 1 of 2   Jump to: Select a forum C++ Builder Newsgroups----------------C++ BuilderC++ Builder (ActiveX)C++ Builder (Announcements)C++ Builder (Command Line Tools)C++ Builder DatabasesC++ Builder Databases (ADO)C++ Builder Databases (Desktop)C++ Builder Databases (InterBase Express)C++ Builder Databases (Multi-Tier)C++ Builder Databases (SQL Servers)C++ Builder (Graphics)C++ Builder (IDE)C++ Builder (Internet)C++ Builder (Internet Socket)C++ Builder (Internet Web)C++ Builder (Jobs)C++ Builder (Language)C++ Builder (Language C++)C++ Builder (Compatibility with MFC)C++ Builder (Native API)C++ Builder (Non-Technical)C++ Builder (Students)C++ Builder (Third Party Tools)C++ Builder (Upgrade)C++ Builder (VCL)C++ Builder (VCL Components Usage)C++ Builder (VCL Components Development)C++ Builder (VCL Usage)C++ Builder (WinAPI)C++ Builder Installation Delphi Newsgroups----------------Delphi (General)Delphi ActiveX Controls UsageDelphi ActiveX Controls DevelopmentDelphi As400Delphi DatabasesDelphi Databases (ADO)Delphi Databases (dbExpress)Delphi Databases (Desktop)Delphi Databases (InterBase Express)Delphi Databases (Multi-Tier)Delphi Databases (SQL Servers)Delphi DeploymentDelphi GraphicsDelphi IDEDelphi InternationalizationDelphi InternetDelphi Internet Isapi-WebBrokerDelphi Internet WebSnapDelphi Internet WinsockDelphi JobsDelphi Language BASMDelphi Language ObjectPascalDelphi Model Driven Architecture (General)Delphi Model Driven Architecture (Third Party)Delphi MultimediaDelphi Native APIDelphi Non-TechnicalDelphi ObjectPascalDelphi OLE AutomationDelphi OO designDelphi OpenToolsAPIDelphi Reporting-ChartingDelphi RTLDelphi StudentsDelphi TeamSourceDelphi Thirdparty ToolsDelphi Thirdparty Tools (General)Delphi Thirdparty Tools (IntraWeb)Delphi Thirdparty Tools (RaveReports)Delphi UpgradeDelphi VCLDelphi VCL ComponentsDelphi VCL Components UsingDelphi VCL Components WritingDelphi WebServices SOAPDelphi WinAPIDelphi XMLDelphi Installationcomp.lang.pascal.delphi.components.misccomp.lang.pascal.delphi.components.usagecomp.lang.pascal.delphi.components.writingcomp.lang.pascal.delphi.databasescomp.lang.pascal.delphi.misccomp.sources.delphi JBuilder Newsgroups----------------JBuilderJBuilder AnnouncementsJBuilder Applet IssuesJBuilder As400JBuilder CompilerJBuilder CORBA/RMIJBuilder DatabasesJBuilder DB SwingJBuilder DebuggerJBuilder DeploymentJBuilder DocumentationJBuilder EnterpriseJBuilder HandheldJBuilder IDEJBuilder JavaJBuilder JavaAPIJBuilder Java LanguageJBuilder Java SwingJBuilder Java BeansJBuilder Java Beans UsageJBuilder Java Beans DevelopmentJBuilder JBCLJBuilder JDataStoreJBuilder JobsJBuilder LinuxJBuilder MacintoshJBuilder & MobileSetJBuilder MultiLingual AppsJBuilder Non-TechnicalJBuilder OpenToolsJBuilder Servlets (JSP)JBuilder StudentsJBuilder Team DevelopmentJBuilder Thirdparty ToolsJBuilder UpgradeJBuilder Installation InterBase Newsgroups----------------InterBaseInterBase Bug DiscussionInterBase GeneralInterBase IBConsoleInterBase OpenSourceInterBase ReplicationInterBase SQLInterBase ThirdpartyInterBase Installation Miscellaneous Borland Newsgroups----------------AppCenterAppServerEnteraVisiBroker  You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum Powered by phpBB © 2001, 2006 phpBB Group SEO toolkit © 2004-2006 webmedic.