Do you design each form for separate case, or use common forms for similar design?

[Mike Torrettinni 198]

I'm curious if it is common to have form/frame for each separate design or you combine into common forms, where design is not much different for each use case?

 

I have a lot of forms, like dialog boxes but they could have a question label and checkbox and maybe a button or two; then next example has 2 checkboxes and 1 button; or forms for exporting data, where some forms have just simple edit box for filename while others add additional checkbox or button. Now I have so many of these very similar forms, so I was thinking of having common forms that would be used for common goals and each different design would be on PageControl Tabs. And OnCreate/OnShow it would choose appropriate design and show form.

 

Anybody has any thoughts on this, any objections or experience that such common forms proved useful?

[haentschman 92]

Hi...

Definitely yes. The advantage of inheritance is that when you make changes in the base form, you have the same changes in the other forms.
Caution: With too many inheritance levels the overview is then again bad. I prefer max 3 levels.

Example (picture): Form.ChoiceFilesDialog -> Form.BaseDialog -> Form.Base

[David Heffernan 2345]

I wouldn't consider using the designer for such a thing. I would build the form dynamically in code. 

 

Your example of a dialog with a handful of checkboxes and buttons is just the Vista task dialog. 

[Guest]

I tend to use a combination of the two above approaches. A base, perhaps some specific 2'nd level. You can also of course "prep" you dialogs/forms dynamically, like the Vista task dialog, setting properties to reflect different cases. What properties/functionality is inherited, dynamically set by properties you expose in the base class is very much up to your needs, i.e application specific. Basically everything you put in the dfm (design-time) will have to be read at form creation and if there are a lot of dynamic changes to what was read from the dfm then the point of reading dfm becomes moot.

 

Personally i tend to avoid things like frames. I also tend to minimise the number of dynamically hidden stuff. Why create 8 frames or tabs with content just to go hide 7 of them after each creation of an instance? when using visual inheritance i often open the dfm's in Visual Code to "keep an eye" of what the IDE is doing, this has helped me understand visual inheritance better too. As mentioned above visual inheritance can get rather messy with a lot of levels.

Edited May 16, 2019 by Guest
Mention of "Vista approach"

[egroups 2]

4 hours ago, David Heffernan said:

I wouldn't consider using the designer for such a thing. I would build the form dynamically in code. 

 

Your example of a dialog with a handful of checkboxes and buttons is just the Vista task dialog. 

Do you have any framework for dynamically create forms?

[David Heffernan 2345]

2 hours ago, egroups said:

Do you have any framework for dynamically create forms?

No. I'm not even sure what such a framework would look like. Sounds like massive overkill. 

[Mike Torrettinni 198]

6 hours ago, David Heffernan said:

Your example of a dialog with a handful of checkboxes and buttons is just the Vista task dialog. 

I'm not too fond of Vista dialogs, they seem very rigid, not flexible enough to fit in the software design.

 

8 hours ago, haentschman said:

The advantage of inheritance is that when you make changes in the base form, you have the same changes in the other forms.
Caution: With too many inheritance levels the overview is then again bad. I prefer max 3 levels.

Example (picture): Form.ChoiceFilesDialog -> Form.BaseDialog -> Form.Base

 

Sounds good, but does it lower the number of individual Forms? All you do is inherit common design, but you still need to design each individual form, right?

For example I have 10 different searches for 10 different data types. And some searches are just on text, which can be combined into same Form, then some searches need 1-5 checkbox to indicate search areas/date ranges and such... and then some searches lookup combo boxes to select search areas. So, all very similar things, but slight difference.

 

Would I need to have 1 Base Search form and then 10 inherited forms for each search type? Seems like overkill... compared to 1 form with 10 Tabs (or less, is possible), for each search type. No?

[Guest]

1 hour ago, Mike Torrettinni said:

For example I have 10 different searches for 10 different data types. And some searches are just on text, which can be combined into same Form, then some searches need 1-5 checkbox to indicate search areas/date ranges and such... and then some searches lookup combo boxes to select search areas. So, all very similar things, but slight difference.

Sounds like the OOP pattern to me 🙂

 

Seriously, the topic is valid, interesting.

But i think that if you want more "concrete" tips, opinions, perhaps write more about what you are trying to do. Perhaps a mock-up?

If you are not afraid of information overload, check Marcos Delphi book. IMHO there is a lot of information there that pertains to the topic.

Edited May 16, 2019 by Guest

[David Heffernan 2345]

3 hours ago, Mike Torrettinni said:

I'm not too fond of Vista dialogs, they seem very rigid, not flexible enough to fit in the software design.

That's an odd comment. For dialogs with a message, and couple of checkboxes or buttons then they are perfectly flexible.

 

If you want to customise every individual form then what are you even asking? Just design each one in the designer. 

[Guest]

I must agree with @David Heffernan. This is one idiom/patter for similar stuff. Microsoft do not just do bad things, IMHO lots of times the get things right*.

Here' the link i had in mind: https://specials.rejbrand.se/TTaskDialog/

I use it and it can be used to "gauge" the complexity of the result for the path of not inheriting.

As i already said, combinations of the two approaches are almost endless in it's permutations.

 

* Visual Code being a good example. File systems under Windows Server (much better that Linux under a lot of circumstances, abundant socket APIs et cetera).

[Mike Torrettinni 198]

Here is example of 3 Search forms (I have 10 very similar), each searches (and locates lines) on different data (TArray) right on the main screen Virtual Treeview control.

 

 

 

 

 

So, this is 3 (10) different pas and dfm files. Even if I have BaseSearch with Title and Search, Close buttons, I still need to derive each of these 3 forms as 3 different pas and dfm files.

 

What if I have 1 Common Search form that has PageControl with Tabs for each search type, and OnShow I show Tab that is needed. My assumptions:

- 1 pas and 1 dfm file - easier to maintain

- OnCreate will take a bit longer, but opening a Search form doesn't need to be instnat, so 50ms vs 200ms should not be a big deal for first time opening a form

- design time is there - so no blindly creating controls with code 🙂

- I will need to setup some properties to control which Tab is opened, something like: CommonSearchForm.SetSearchType(stActions); before calling .Show (which will control how form appears and behaves)

 

I appreciate the suggestions, but TTaskDialog is not suitable for such cases.

 

What do you think of this CommonSearch form idea?

 

 

 

[David Heffernan 2345]

Task dialog is not suitable for that. However, the form you described, which led me to suggest task dialog, is a very different beast from these forms. The forms you described did not have an edit control or 7 check boxes!!!! 

 

Very hard to give advice when you don't describe the actual problem. 

 

[Mike Torrettinni 198]

Yes, I agree, it's hard to imagine without detailed description. I hope screenshots give more information. I actually have one search form with a few more controls.

I'm not looking for Yes/No suggestions, but more like advice (concrete or general) how to deal with this.

 

[Uwe Raabe 2057]

26 minutes ago, Mike Torrettinni said:

What if I have 1 Common Search form that has PageControl with Tabs for each search type, and OnShow I show Tab that is needed. My assumptions:

- 1 pas and 1 dfm file - easier to maintain

I have to disagree with that conclusion.

 

Whenever I encounter a form with a tab control I consider breaking it up into the form with only the tab control (and the common controls around it) and have the different tab sheets extracted to individual frames. IMHO that is much easier to maintain than 1 form alone. Just imagine a group of developers each one working on one tab content.

 

Given that breaking complex forms up into smaller parts reduces dependencies and is way better to maintain, I would never go and glue different forms together into one.

[Mike Torrettinni 198]

1 minute ago, Uwe Raabe said:

Just imagine a group of developers each one working on one tab content

You have a point there, but I'm a sole developer on this project, so I don't have this problem.

 

 

[Uwe Raabe 2057]

8 minutes ago, Mike Torrettinni said:

but I'm a sole developer on this project, so I don't have this problem.

That only changes the perception of the problem, not its existence.

[Mike Torrettinni 198]

4 minutes ago, Uwe Raabe said:

That only changes the perception of the problem, not its existence.

Maybe I'm struck with beginner's 'enthusiasm' on refactoring... and I look for something to refactor at every step. 🙂

[Bill Meyer 337]

16 minutes ago, Mike Torrettinni said:

You have a point there, but I'm a sole developer on this project, so I don't have this problem.

Coming into a project which has built for years on the philosophy that a "sole developer" could deal with things, and then success led to 10 or more developers, I have to say I think it is best to plan for success. Legacy code is too often very ugly.

[Mike Torrettinni 198]

1 minute ago, Bill Meyer said:

Coming into a project which has built for years on the philosophy that a "sole developer" could deal with things, and then success led to 10 or more developers, I have to say I think it is best to plan for success. Legacy code is too often very ugly.

I agree! And that is why I'm annoyed every time I need to maintain those Search forms... and I know I will be dealing with them for years to come. That's why idea of a single pas and dfm file is very intriguing, in this case.

[Attila Kovacs 629]

@Mike Torrettinni If you don't care about GUI, or you are drowning in those forms, devexpress has a grid where you can put controls into the rows (I believe dynamically (too)). It's ugly (for me) but who knows. Just telling. I'd never use it.

Edited May 16, 2019 by Attila Kovacs

[Mike Torrettinni 198]

2 minutes ago, Attila Kovacs said:

@Mike Torrettinni If you don't care about GUI, or you are drowning in those forms, devexpress has a grid where you can put components into the rows. It's ugly (for me) but who knows. Just telling. I'd never use it.

Thanks, but devexpress has long learning curve, not suitable for my patience. But, I assume this was a suggestion to go with single form. no matter how controls are organized, either with devexpress control or tab control, right? Finally someone in my corner 🙂

[Attila Kovacs 629]

@Mike Torrettinni There is a saying "it must be done only once".  So what.

[Attila Kovacs 629]

14 minutes ago, Mike Torrettinni said:

But, I assume this was a suggestion to go with single form. no matter how controls are organized, .....  tab control, right?

 No, the opposite. This is a big no-no.

 I also had such swiss-knife forms and dozens of frames, man was I lucky when I got rid of them.

 But, you know what, do you know templates in the IDE? You can make some form templates and use them when you create a new one.

 Then you have the half of the junk work behind you.

 

Edited May 16, 2019 by Attila Kovacs

[Mike Torrettinni 198]

50 minutes ago, Attila Kovacs said:

I also had such swiss-knife forms and dozens of frames, man was I lucky when I got rid of them.

Oh, interesting. Would you care to compare what was hard to deal with that situation compared to what you have now? What did you gain with changing the design? Can you compare number of forms/frames before and now?

[TigerLilly 16]

The idea of having kind of a framework for generating forms (and yes, there are so many so similar forms) is quite interesting. I remember a long ago Java project where we used STRUTS. Building forms was a matter of designing froms and wiring POJOs, validation and workflow. I liked it.