BorlandTalk.com Borland discussion newsgroups   Archives   FAQ   Search   Memberlist   Usergroups   Register   Profile   Log in to check your private messages   Log in  renamed components moving          BorlandTalk.com Forum Index -> JBuilder IDE View previous topic :: View next topic   Author Message dingfelder Guest Posted: Wed Jul 13, 2005 11:48 pm    Post subject: renamed components moving I have noticed an annoying "feature", and am wondering if it affects others as well. 1. In the gui builder, I expand the "structure" tree, and go to a panel that contains some components (2 other panels in this example). 2. I click one of the panels in the structure tree 3. Then in the properties tab of the main IDE, I change the "name" property of the component from jPanel1 to something else (like jPanelMyPanel) 4. Then I click the other component in the structure tree (I want to rename it also) 5. It does rename the panel I just modified, but it then MOVES the component to the topmost level of the tree (parallel with the "this" object). The only way to rename the object without moving it is to change the name, then click a different property of the same object. Once it has refreshed (after a 20 second pause/hang in the IDE) it then seems to have "saved" the new setting. I assume it is doing a "refactoring/rename" in the background which causes the pause. At this point I can then click a different component without it getting moved to a diffferent location in the source tree. Quite annoying if you have a complicated gridbag layout and the component gets moved out of the gridbag because it then loses all it's constraints and you have to reset it's location & settings once you move it back into the right place. Back to top dingfelder Guest Posted: Thu Jul 14, 2005 2:44 am    Post subject: Re: renamed components moving one other thing to add: I fully realize that this may not occur for everyone, my app is GUI heavy and many lightweight apps will not stress the gui builder this much. I just counted the objects in the gui structure pane... I have 167 objects (most of which are panels, labels and textfields, and most of the panels use gridbag layout. My panels are set up in layers, like the following: top_panel center_panel bottom_panel the center panel is a card layout the card layout is made up of: start_panel tabnotebook_panel end_panel The tabnotebook then has 5 panels on it. Each panel on the tab notebook has 2 or 3 panels Therefore the bottommost panels can be as deep as 6 layers deep. I retried the scenerio listed in the parent post, using a simple hello world, and the longest I had to wait for the refactoring was about 2 seconds, so I suspect it is the quantity of stuff that bogs down the gui builder. Back to top Kevin Dean [TeamB] Guest Posted: Thu Jul 14, 2005 12:00 pm    Post subject: Re: renamed components moving dingfelder wrote: Quote: one other thing to add: I fully realize that this may not occur for everyone, my app is GUI heavy and many lightweight apps will not stress the gui builder this much. I just counted the objects in the gui structure pane... I have 167 objects (most of which are panels, labels and textfields, and most of the panels use gridbag layout. My panels are set up in layers, like the following: top_panel center_panel bottom_panel the center panel is a card layout the card layout is made up of: start_panel tabnotebook_panel end_panel The tabnotebook then has 5 panels on it. Each panel on the tab notebook has 2 or 3 panels Therefore the bottommost panels can be as deep as 6 layers deep. I retried the scenerio listed in the parent post, using a simple hello world, and the longest I had to wait for the refactoring was about 2 seconds, so I suspect it is the quantity of stuff that bogs down the gui builder. Is there anything you can do to simplify the design? Quite apart from the designer's ability to manage the components, it gets more difficult for the programmer to manage the more components you add. My personal approach to complex screens is to put individual panels into their own classes. I would start with breaking up the contents of tab notebook panel into five individual classes. That way, you can edit them individually and improve the abstraction of your program. -- Kevin Dean [TeamB] Dolphin Data Development Ltd. http://www.datadevelopment.com/ NEW WHITEPAPERS Team Development with JBuilder and Borland Enterprise Server Securing Borland Enterprise Server http://www.datadevelopment.com/papers/index.html Please see Borland's newsgroup guidelines at http://info.borland.com/newsgroups/guide.html Back to top dingfelder Guest Posted: Thu Jul 14, 2005 11:05 pm    Post subject: Re: renamed components moving I agree with what you suggested in principle however... Will having seperate classes for each panel make the GUI designer any faster or use less memory? (I assume not) For my app, I have around 40 input fields and about 10 radio buttons + various other components to collect data, spread among various tabs. Once they hit "save", I have to gather the data and validate it, and then pass it to a DB clas for storage and then process the data. If there were 4 seperate classes each with their own data fields, I don't look forward to having each class have to validate their own data and save it. I guess I could have each class inherit from one main class that knows how to validate and save data I could do all that but, that is a lot of work. Yes, it will make the system "better" from an OO point of view, but if it doesn't make the system faster or help the GUI designer work better, I'm not sure I can afford the time for rework. Thoughts? "Kevin Dean [TeamB]" <NkOdSePaAnM (AT) datadevelopment (DOT) com> wrote: Quote: dingfelder wrote: one other thing to add: I fully realize that this may not occur for everyone, my app is GUI heavy and many lightweight apps will not stress the gui builder this much. I just counted the objects in the gui structure pane... I have 167 objects (most of which are panels, labels and textfields, and most of the panels use gridbag layout. My panels are set up in layers, like the following: top_panel center_panel bottom_panel the center panel is a card layout the card layout is made up of: start_panel tabnotebook_panel end_panel The tabnotebook then has 5 panels on it. Each panel on the tab notebook has 2 or 3 panels Therefore the bottommost panels can be as deep as 6 layers deep. I retried the scenerio listed in the parent post, using a simple hello world, and the longest I had to wait for the refactoring was about 2 seconds, so I suspect it is the quantity of stuff that bogs down the gui builder. Is there anything you can do to simplify the design? Quite apart from the designer's ability to manage the components, it gets more difficult for the programmer to manage the more components you add. My personal approach to complex screens is to put individual panels into their own classes. I would start with breaking up the contents of tab notebook panel into five individual classes. That way, you can edit them individually and improve the abstraction of your program. -- Kevin Dean [TeamB] Dolphin Data Development Ltd. http://www.datadevelopment.com/ NEW WHITEPAPERS Team Development with JBuilder and Borland Enterprise Server Securing Borland Enterprise Server http://www.datadevelopment.com/papers/index.html Please see Borland's newsgroup guidelines at http://info.borland.com/newsgroups/guide.html Back to top Tony Guest Posted: Fri Jul 15, 2005 3:16 am    Post subject: Re: renamed components moving Quote: Will having seperate classes for each panel make the GUI designer any faster or use less memory? (I assume not) It definitely will. I use this approach all the time. Never had any problems with the designer. Proper decomposition helps. I had screens with comparable number fields. Tony. Back to top Kevin Dean [TeamB] Guest Posted: Fri Jul 15, 2005 12:26 pm    Post subject: Re: renamed components moving dingfelder wrote: Quote: Will having seperate classes for each panel make the GUI designer any faster or use less memory? (I assume not) Definitely. JBuilder will only validate the current frame or panel, so if you break it up into five pieces the validation will run on average five times faster in the individual panels. Quote: For my app, I have around 40 input fields and about 10 radio buttons + various other components to collect data, spread among various tabs. Once they hit "save", I have to gather the data and validate it, and then pass it to a DB clas for storage and then process the data. If there were 4 seperate classes each with their own data fields, I don't look forward to having each class have to validate their own data and save it. I guess I could have each class inherit from one main class that knows how to validate and save data You wouldn't. You would have each panel refer to a central data object. The validation would be handled in the enclosing frame, so that it could then select the appropriate panel on the card layout for missing data. Quote: I could do all that but, that is a lot of work. Yes, it will make the system "better" from an OO point of view, but if it doesn't make the system faster or help the GUI designer work better, I'm not sure I can afford the time for rework. It's a lot of work right now because you have to change your design, but "better" from an OO point of view usually means more maintainable, easier to document, easier to debug, and so on; you'll make the time back and more in the long run. -- Kevin Dean [TeamB] Dolphin Data Development Ltd. http://www.datadevelopment.com/ NEW WHITEPAPERS Team Development with JBuilder and Borland Enterprise Server Securing Borland Enterprise Server http://www.datadevelopment.com/papers/index.html Please see Borland's newsgroup guidelines at http://info.borland.com/newsgroups/guide.html Back to top Ken Warner Guest Posted: Fri Jul 15, 2005 4:57 pm    Post subject: Re: renamed components moving Maybe... Sometimes "canonical" OO design leads one to unnecessarily implement a model of design that doesn't quite fit the real world problem you are faced with. Proceed with caution and judicious application of OO design principles. Sometimes you just have to get dirty... Quote: It's a lot of work right now because you have to change your design, but "better" from an OO point of view usually means more maintainable, easier to document, easier to debug, and so on; you'll make the time back and more in the long run. Back to top Rick Gretter Guest Posted: Fri Jul 15, 2005 10:43 pm    Post subject: Re: renamed components moving dingfelder wrote: Quote: I have noticed an annoying "feature", and am wondering if it affects others as well. 1. In the gui builder, I expand the "structure" tree, and go to a panel that contains some components (2 other panels in this example). 2. I click one of the panels in the structure tree 3. Then in the properties tab of the main IDE, I change the "name" property of the component from jPanel1 to something else (like jPanelMyPanel) 4. Then I click the other component in the structure tree (I want to rename it also) 5. It does rename the panel I just modified, but it then MOVES the component to the topmost level of the tree (parallel with the "this" object). The only way to rename the object without moving it is to change the name, then click a different property of the same object. Once it has refreshed (after a 20 second pause/hang in the IDE) it then seems to have "saved" the new setting. I assume it is doing a "refactoring/rename" in the background which causes the pause. At this point I can then click a different component without it getting moved to a diffferent location in the source tree. Quite annoying if you have a complicated gridbag layout and the component gets moved out of the gridbag because it then loses all it's constraints and you have to reset it's location & settings once you move it back into the right place. I don't see the problem with unwanted changes in the structure pane hierarchy. But I'm using JBuilder 2005 Enterprise. Let me know what version of JBuilder 2005 Developer you have (initial release, latest update -- Update 4 -- or something in between) and I will try again to duplicate it. By the way, you can hit Enter to commit entry of a text property value in the Inspector. That should prevent your next click in the structure pane from having any unwanted side effects. Back to top dingfelder Guest Posted: Mon Jul 18, 2005 2:16 am    Post subject: Re: renamed components moving Part of the design issue I have is that some components have tio access other components, and if I break panels up into seperate objects, it will get *really* messy. For example, I have radio buttons that enable and disable other sections of the gui. Suppose I make the panel that contains the radio buttons into a seperate class and then make another seperate class to hold some edit fields. I then add the 2 new classes to the main tab notebook. Now the trouble: I have an action listener on the radio button, and selecting the "off" button has to make the edit fields "read only". If the radio button and edit fields are in seperate classes, getting access to the edit field is going to be ugly. I guess I would have to make everything public and then access the edit field via panel2class.editfield.setEnabled(true); Not pretty. Quote: It's a lot of work right now because you have to change your design, but "better" from an OO point of view usually means more maintainable, easier to document, easier to debug, and so on; you'll make the time back and more in the long run. Back to top Display posts from previous: All Posts1 Day7 Days2 Weeks1 Month3 Months6 Months1 Year Oldest FirstNewest First         BorlandTalk.com Forum Index -> JBuilder IDE All times are GMT Page 1 of 1   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.