BorlandTalk.com Borland discussion newsgroups   Archives   FAQ   Search   Memberlist   Usergroups   Register   Profile   Log in to check your private messages   Log in  Is this a wrong approach?          BorlandTalk.com Forum Index -> comp.lang.pascal.delphi.misc View previous topic :: View next topic   Author Message Franco Jommi Guest Posted: Fri Jan 30, 2004 12:07 pm    Post subject: Is this a wrong approach? I have a routine which is identical to another routine, apart from the fact that the same components referenced by the two routines are laid on two different forms. If I wanted to share the same routine, I would have to prefix some statements with Form1 or Form2 alternatively. I can't find the way. Probably this is the wrong approach. What do you think ? Back to top J French Guest Posted: Fri Jan 30, 2004 12:47 pm    Post subject: Re: Is this a wrong approach? On Fri, 30 Jan 2004 12:07:16 GMT, "Franco Jommi" <franco.jommmi (AT) tin (DOT) it> wrote: Quote: I have a routine which is identical to another routine, apart from the fact that the same components referenced by the two routines are laid on two different forms. If I wanted to share the same routine, I would have to prefix some statements with Form1 or Form2 alternatively. I can't find the way. Probably this is the wrong approach. What do you think ? Do you want to share the code to avoid duplication ? - or is it because the code is pretty generic ? If it is simply to avoid duplication, then I suggest that you look at it very carefully and see where the generic bits lie There are several approaches :- - with generic stuff it can (and should) be put in another (3rd) Unit, and all required parameters sent in to that procedure Or you could turn that procedure into a Class that uses 'events' to fish out the data it needs from the two Forms - or have a Class within each Form that can be passed down to a procedure, and can collect the required data Alternatively you could have one 'Base Form' containing all the common stuff, and make your two forms descendants of that Base Form With later versions of Delphi than my D4, there are Frames - they could solve your problem One thing that is asking for trouble, is to have two Forms fishing around in each others code - or one Form fishing around in another Form's code IMO Parents should not grope inside the guts of other 'Parents' - and 'Children' should know as little about their parents as possible - especially their names Personally I would start by hacking all the code you want to share out into a third unit - sometimes a bit of Spring cleaning makes things clearer Back to top Maarten Wiltink Guest Posted: Fri Jan 30, 2004 7:28 pm    Post subject: Re: Is this a wrong approach? "Franco Jommi" <franco.jommmi (AT) tin (DOT) it> wrote Quote: I have a routine which is identical to another routine, apart from the fact that the same components referenced by the two routines are laid on two different forms. If I wanted to share the same routine, I would have to prefix some statements with Form1 or Form2 alternatively. I can't find the way. Probably this is the wrong approach. What do you think? The key question is, how many components? The normal answer to this situation is to make all affected components parameters to the function. Parameters don't care what form they're on; you just call the methods that the class says are available. But if you have to pass in ten or twelve components, this gets more than a little unwieldy. Putting them on a panel (or even a frame?) might solve that, under the assumption that when you're given the parent, you can find all the children you need to know about. That would probably also be a good time to start identifying them by other means than their names; for example, classtype plus tag might make the basis for a nice replacement scheme. Don't believe all the bad press Tag's been getting; it's there to _use_. Groetjes, Maarten Wiltink Back to top AlanGLLoyd Guest Posted: Fri Jan 30, 2004 10:15 pm    Post subject: Re: Is this a wrong approach? In article <401ab075$0$333$e4fe514c (AT) news (DOT) xs4all.nl>, "Maarten Wiltink" <maarten (AT) kittensandcats (DOT) net> writes: Quote: Don't believe all the bad press Tag's been getting; it's there to _use_. What bad press <g>. But set it's value in _code_ (not manually in the IDE). Then its value is apparent and you can comment it if necessary. Alan Lloyd [email]alanglloyd (AT) aol (DOT) com[/email] Back to top Maarten Wiltink Guest Posted: Sat Jan 31, 2004 11:44 am    Post subject: Re: Is this a wrong approach? "AlanGLLoyd" <alanglloyd (AT) aol (DOT) com> wrote Quote: In article <401ab075$0$333$e4fe514c (AT) news (DOT) xs4all.nl>, "Maarten Wiltink" [email]maarten (AT) kittensandcats (DOT) net[/email]> writes: Don't believe all the bad press Tag's been getting; it's there to _use_. What bad press <g>. But set it's value in _code_ (not manually in the IDE). Then its value is apparent and you can comment it if necessary. I'll blithely set it from the Object Inspector, too. Just yesterday, I've been building something like a grid of comboboxes, and I've used Tag to mark every box with its row number. In code. I have actually wondered why I did that; I might have inferred it from the Top property and the row spacing, which is stored in the... Tag of the Parent. The problem was that I would then have to make an assumption about the Top of the top row. But this is a somewhat atypical use of Tag in my code. More often, I use it to partition components into equivalence classes along different axes than their ClassType or Parent (one could argue that I've done so in the above example). And in the case of statically-designed components, I consider this best done from the designer. Groetjes, Maarten Wiltink Back to top AlanGLLoyd Guest Posted: Sat Jan 31, 2004 4:59 pm    Post subject: Re: Is this a wrong approach? In article <401b951e$0$326$e4fe514c (AT) news (DOT) xs4all.nl>, "Maarten Wiltink" <maarten (AT) kittensandcats (DOT) net> writes: Quote: Just yesterday, I've been building something like a grid of comboboxes, and I've used Tag to mark every box with its row number. In code. I have actually wondered why I did that; I might have inferred it from the Top property and the row spacing, which is stored in the... Tag of the Parent. If you construct the comboboxes in code on their parent, then the row number would have been readily obtained from their parent's Controls array indices. But all these aspects depend on the concept behind the design of the form, and there are usually many approaches with a few equally optimum for different reasons, depending on the particular emphases in the design. I must admit to finding assignments in code easier to assimilate at a later date than entries in the Object Inspector, especial when a number of controls have tags. Alan Lloyd [email]alanglloyd (AT) aol (DOT) com[/email] Back to top J French Guest Posted: Sat Jan 31, 2004 5:22 pm    Post subject: Re: Is this a wrong approach? On 31 Jan 2004 16:59:06 GMT, [email]alanglloyd (AT) aol (DOT) com[/email] (AlanGLLoyd) wrote: Quote: In article <401b951e$0$326$e4fe514c (AT) news (DOT) xs4all.nl>, "Maarten Wiltink" [email]maarten (AT) kittensandcats (DOT) net[/email]> writes: Just yesterday, I've been building something like a grid of comboboxes, and I've used Tag to mark every box with its row number. In code. I have actually wondered why I did that; I might have inferred it from the Top property and the row spacing, which is stored in the... Tag of the Parent. If you construct the comboboxes in code on their parent, then the row number would have been readily obtained from their parent's Controls array indices. But all these aspects depend on the concept behind the design of the form, and there are usually many approaches with a few equally optimum for different reasons, depending on the particular emphases in the design. I must admit to finding assignments in code easier to assimilate at a later date than entries in the Object Inspector, especial when a number of controls have tags. Yes - why use the Tag when you can make up your own construct - much more robust and unambivalent Back to top Maarten Wiltink Guest Posted: Sat Jan 31, 2004 8:21 pm    Post subject: Re: Is this a wrong approach? "AlanGLLoyd" <alanglloyd (AT) aol (DOT) com> wrote Quote: In article <401b951e$0$326$e4fe514c (AT) news (DOT) xs4all.nl>, "Maarten Wiltink" [email]maarten (AT) kittensandcats (DOT) net[/email]> writes: Just yesterday, I've been building something like a grid of comboboxes, and I've used Tag to mark every box with its row number. In code. I have actually wondered why I did that; I might have inferred it from the Top property and the row spacing, which is stored in the... Tag of the Parent. If you construct the comboboxes in code on their parent, then the row number would have been readily obtained from their parent's Controls array indices. It's a _grid_. There are several comboboxes in every row. I don't want to make assumptions about how many there are, either. Try to fault me, please, do. I'd love to end up with better code than I could have written unchallenged. The grid is built on a scrollbox in case too many rows are created for the available space, and although currently there aren't any and probably never will be, I'm also not assuming the absence of other controls on it. I have "template controls" where the top row is to come, and during initialisation they are disabled, hidden, and moved one row up. Adding a row is done by determining the number of rows present (highest Tag value) and making copies of all controls with a Tag of zero. Their Tag is set to their row number (one higher than previous maximum), they are enabled, shown, and moved down by Tag*Parent.Tag pixels. One thing is dubious in my current scheme: a zero Tag indicates a template control. This chimes nicely with the perception of it being "row zero", but it's at odds with my usual conviction that Tag zero should indicate no special treatment at all, and marking a control as a template should require a non-zero value (minus one, or probably just anything negative; anything positive is interpreted as a row number). Quote: But all these aspects depend on the concept behind the design of the form, and there are usually many approaches with a few equally optimum for different reasons, depending on the particular emphases in the design. But designs seem to entangle themselves in such a way as to, once you've made the first fatal choice, only allow one avenue out of every following one. Quote: I must admit to finding assignments in code easier to assimilate at a later date than entries in the Object Inspector, especial when a number of controls have tags. Definitely. Ideally, it should be obvious from code what any Tag value means, but this gets hard without an idea of what values actually go into it. People are just people, not very good at seeing the structure of a system encoded procedurally. We live by examples. The problem is that this would lead to setting nicely commented Tag values on components in some TDerivedForm.Loaded procedure, and I don't like that, either. Those values should be close to the components; also constant properties should be designed into them, not initialised. Other opinions sollicited. Groetjes, Maarten Wiltink Back to top Maarten Wiltink Guest Posted: Sat Jan 31, 2004 8:29 pm    Post subject: Re: Is this a wrong approach? "J French" <erewhon (AT) nowhere (DOT) com> wrote [...] Quote: Yes - why use the Tag when you can make up your own construct - much more robust and unambivalent Well, in this case (as in many others) it saved me from having to derive and install a better mousetrap than TComboBox _which already has a Tag for me to use_. (I find it curious that I'm the one arguably advocating ad-hockery here. But somehow, this kind of marking up objects with "user data" seems logical and right to me. As long as it fits in 32 bits.) Groetjes, Maarten Wiltink Back to top AlanGLLoyd Guest Posted: Sat Jan 31, 2004 10:08 pm    Post subject: Re: Is this a wrong approach? In article <401c0e3b$0$328$e4fe514c (AT) news (DOT) xs4all.nl>, "Maarten Wiltink" <maarten (AT) kittensandcats (DOT) net> writes: Quote: If you construct the comboboxes in code on their parent, then the row number would have been readily obtained from their parent's Controls array indices. It's a _grid_. There are several comboboxes in every row. I don't want to make assumptions about how many there are, either. I was thinking more on the lines of ... Get the index (I) of the combobox in the Controls array Row := I div ColCount; Col := I mod ColCount; // or vice versa if you fill columns first .... and expecting that you would create and place them consecutively at initiation time, positioning by multiples of spacing times the count. .... but then I realised that I'd have to have a small function to return the row & col and one might as well use HiWord and LoWord of the Tag. I think I am a little prejudiced against Tag because if one sets them in the OI then they are a bit opaque. This view overflows into using them at all, when if used in code they can be apparent. But this is obviously a personal view (and I must overcome it <g>) This sort of design discussion is difficult with paper and pencil, and a greater knowledge of the nuances of the design. Alan Lloyd [email]alanglloyd (AT) aol (DOT) com[/email] Back to top Maarten Wiltink Guest Posted: Sun Feb 01, 2004 5:44 pm    Post subject: Re: Is this a wrong approach? "AlanGLLoyd" <alanglloyd (AT) aol (DOT) com> wrote Quote: In article <401c0e3b$0$328$e4fe514c (AT) news (DOT) xs4all.nl>, "Maarten Wiltink" [email]maarten (AT) kittensandcats (DOT) net[/email]> writes: If you construct the comboboxes in code on their parent, then the row number would have been readily obtained from their parent's Controls array indices. It's a _grid_. There are several comboboxes in every row. I don't want to make assumptions about how many there are, either. I was thinking more on the lines of ... Get the index (I) of the combobox in the Controls array Row := I div ColCount; Col := I mod ColCount; // or vice versa if you fill columns first ... and expecting that you would create and place them consecutively at initiation time, positioning by multiples of spacing times the count. The user can add and delete lines at run-time, but that's not really the problem. The problem is that I don't know ColCount. Its value is not exactly hard to determine, but one does need certain degrees of freedom. I *think* the following list makes it impossible: * Create the grid from template controls on the grid parent * Be able to have unrelated controls on the grid parent * Be able to dynamically add and remove lines * Not use derived controls for keeping state * Not use Tag for keeping state * Not use the form for keeping state So I used Tag. Without thinking twice. Groetjes, Maarten Wiltink Back to top Franco Jommi Guest Posted: Sun Feb 01, 2004 11:41 pm    Post subject: Re: Is this a wrong approach? I had my system down for two days, so my question raised quite a useful discussion to which I couldn't participate. I think I will take the time to read and think to what everyone said, since I am not sure I quite understand... My first intent was to avoid duplication of code and then to make a more general routine. Among the approaches, I would prefer the I would tend to the "Classes" solution. The problem is that while I think I understand the concept, I don't know how to implement it, and I don't think this is a think that can be explained briefly or exemplified (is this the right word?). But let me read all of the messages... "J French" <erewhon (AT) nowhere (DOT) com> ha scritto nel messaggio news:401a4e4d.101522343 (AT) news (DOT) btclick.com... Quote: On Fri, 30 Jan 2004 12:07:16 GMT, "Franco Jommi" [email]franco.jommmi (AT) tin (DOT) it[/email]> wrote: I have a routine which is identical to another routine, apart from the fact that the same components referenced by the two routines are laid on two different forms. If I wanted to share the same routine, I would have to prefix some statements with Form1 or Form2 alternatively. I can't find the way. Probably this is the wrong approach. What do you think ? Do you want to share the code to avoid duplication ? - or is it because the code is pretty generic ? If it is simply to avoid duplication, then I suggest that you look at it very carefully and see where the generic bits lie There are several approaches :- - with generic stuff it can (and should) be put in another (3rd) Unit, and all required parameters sent in to that procedure Or you could turn that procedure into a Class that uses 'events' to fish out the data it needs from the two Forms - or have a Class within each Form that can be passed down to a procedure, and can collect the required data Alternatively you could have one 'Base Form' containing all the common stuff, and make your two forms descendants of that Base Form With later versions of Delphi than my D4, there are Frames - they could solve your problem One thing that is asking for trouble, is to have two Forms fishing around in each others code - or one Form fishing around in another Form's code IMO Parents should not grope inside the guts of other 'Parents' - and 'Children' should know as little about their parents as possible - especially their names Personally I would start by hacking all the code you want to share out into a third unit - sometimes a bit of Spring cleaning makes things clearer Back to top Display posts from previous: All Posts1 Day7 Days2 Weeks1 Month3 Months6 Months1 Year Oldest FirstNewest First         BorlandTalk.com Forum Index -> comp.lang.pascal.delphi.misc 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.