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

[Edwin Yip 154]

10 hours ago, Uwe Raabe said:

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.

That's exactly what I do in such situations, except that I use border-less forms instead of frames, and attach them to each of the page at run-time.

[Sherlock 663]

20 minutes ago, edwinyzh said:

That's exactly what I do in such situations, except that I use border-less forms instead of frames, and attach them to each of the page at run-time.

Why the extra hassle? What is keeping you from using frames?

[Edwin Yip 154]

24 minutes ago, Sherlock said:

Why the extra hassle? What is keeping you from using frames?

Actually there is no extra hassles, all after all, even if I use frames, I still embed the frames at run-time, it's all about clearness and cleanness.

 

But there is one gaining  - it enabled the possibility of also shows the forms as modal forms, for example, for a 'Recent files list', some times I want it to be shown as part of another parent form, the other time I need to show it as modal forms. With frames you'll need another form to wrap it up.

 

I guess it's all about specific needs.

[Uwe Raabe 2057]

34 minutes ago, edwinyzh said:

even if I use frames, I still embed the frames at run-time

That was exactly what wanted to suggest, but missed to mention clearly. Thanks for jumping in.

 

36 minutes ago, edwinyzh said:

With frames you'll need another form to wrap it up.

Yep, that is exactly what I do here. And be it just for clearness.

[Guest]

11 hours ago, Attila Kovacs said:

devexpress has a grid

You mean their "LayoutControl"? Check it out. It's one of the coolest controls out there! (I'm not affiliated).

Edited May 17, 2019 by Guest
Added (I'm not affiliated).

[Guest]

Looking at those forms / dialogs.

 

That indicates that the user must choose WHAT to search in step 1. Then details in step 2.

For your users, would it not be better to have one dialog. User klicks "search" and can then choose WHAT to search on?

If user search data is persisted then they could refine the search from last search.

Also, maybe some users will want to search on TWO WHATs.

IMHO these are the important considerations that should result in a programming strategy.

 

HTH

[Guest]

Oh, and looking at the pictures, i'm all for one dynamically created form (like Davids first suggestion).

Why, because i do not see this as "dialogs" at all. I mean to say that the "form/dialog" way to think may be the least interesting thing about your problem..

My clients' users prefer the search controls to reside in the same form as the result. Like google. A dynamic approach will make it easier to cater for such thisng.

But i'm getting way to verbose and should stop. Now.

[Mike Torrettinni 198]

Interestingly enough, nobody is suggesting to reduce the number of forms/frames. Odd. It's almost like when you have 1 class per unit, no matter how small the class is. I'm not there, yet 🙂

I re-checked and I have 19 Search forms... they are all modal forms that hover over data view and the behavior is the same: - search form is opened on top center of data view (Virtual treeview) and locates searched line; - Next/Prev works - search logic is very similar in all of the search forms, but on different data.

I need even more search forms, so I had this idea of single search form. I guess you guys are advising against this approach.

 

 

[Sherlock 663]

Thank you for finally describing your issue 😉

19 forms should definitely be condensed into less. Just consider the probability of some design fetishist becoming the person in charge and demanding the design of the software to be changed radically. Being able to adapt no more than 3 forms vs. 19 should be considered a win. And that is just one reason, why 19 forms for basically the same operation is not a good idea.

[Mike Torrettinni 198]

I really thought I had 10 of them... so it was more general question about the approach. And most of them fit within design of those 3 examples above.

Edited May 17, 2019 by Mike Torrettinni

[Guest]

1 hour ago, Sherlock said:

design fetishist

Hahahahah! Thank you for that "proverb". I have put it in my every-day vocabulary! Brilliant!

[Mark Williams 14]

The forms in the screenshot seem to be pretty simple with a common search box and buttons. Why don't you use a single form (AutoSize=true) with a series of aligned panels. The controls common to all form types on a client aligned panel and the optional controls on top aligned panels. You can then make the optional panels visible/invisible as required in onShow event.

 

And after posting this suggestion I saw that you have lots of these forms. A host of panels would become rather cumbersome!

Edited May 17, 2019 by Mark Williams
Update

[Mike Torrettinni 198]

1 hour ago, Mark Williams said:

The forms in the screenshot seem to be pretty simple with a common search box and buttons. Why don't you use a single form (AutoSize=true) with a series of aligned panels. The controls common to all form types on a client aligned panel and the optional controls on top aligned panels. You can then make the optional panels visible/invisible as required in onShow event.

 

And after posting this suggestion I saw that you have lots of these forms. A host of panels would become rather cumbersome!

That's a good idea, I have something like his in another situation - information based on licensed/unlicensed/trial version (each panel has it's own information shown).

This would be similar to original idea, Page control, right?

 

 

 

[Guest]

23 hours ago, Mike Torrettinni said:

I need even more search forms, so I had this idea of single search form. I guess you guys are advising against this approach.

On the contrary.

[Mike Torrettinni 198]

On 5/17/2019 at 4:54 AM, Dany Marmur said:

But i'm getting way to verbose and should stop. Now

Not at all. I understand it's hard to give concrete opinion, feedback, suggestion when not all details are disclosed. So, thanks for the way you do your searches. I like the search forms, because you don't need to design search filed into main screen.

[Mark Williams 14]

Quote

17 hours ago, Mike Torrettinni said:

This would be similar to original idea, Page control, right?

 

I suppose so. I have used both approaches. If it were just three different forms I would be inclined to use panels. If more forms, a page control may make it visually simpler to manage at design time, with the common search box in a separate panel below the page control.

[Mike Torrettinni 198]

9 minutes ago, Mark Williams said:

I suppose so. I have used both approaches. If it were just three different forms I would be inclined to use panels. If more forms, a page control may make it visually simpler to manage at design time, with the common search box in a separate panel below the page control.

Thanks, still deciding what to do, but I need to do something.

[Mike Torrettinni 198]

On 5/17/2019 at 4:54 AM, Dany Marmur said:

Oh, and looking at the pictures, i'm all for one dynamically created form (like Davids first suggestion). 

I very rarely use code-generated controls, I guess I have my need for visual representation during development too strong.

[Guest]

2 hours ago, Mike Torrettinni said:

I very rarely use code-generated controls, I guess I have my need for visual representation during development too strong.

IMHO something you should do something about. Does not sound 100% "healty/smart".

Dynamically or statically (an oxymoron) i think is also something you have to consider.

Everything you put into DFMs will be read by the "subsystem" at form creation. It's simply a question of "who's in control".

Difficult to express in a third language. At form creation the DFMs are read by code from the VCL (FMX?) linked to your exe. No magic.

So the patterns/idioms are the same, just a question of exactly when/where and... hmm... lazy programmer (??).

[dummzeuch 1505]

When I decide to use code generated controls, I usually start with visually designed controls anyway and later on convert these controls to code with the GExperts Components to code expert.

 

But mostly I simply go with the visually designed forms, even if it mostly duplicates some form. Unless there is a lot of duplicated code I don't care.

[Mike Torrettinni 198]

1 hour ago, Dany Marmur said:

IMHO something you should do something about. Does not sound 100% "healty/smart".

Dynamically or statically (an oxymoron) i think is also something you have to consider.

Everything you put into DFMs will be read by the "subsystem" at form creation. It's simply a question of "who's in control".

Difficult to express in a third language. At form creation the DFMs are read by code from the VCL (FMX?) linked to your exe. No magic.

So the patterns/idioms are the same, just a question of exactly when/where and... hmm... lazy programmer (??).

Interesting view... where do you draw the line between code generated and visual? what's the threshold where you decide that form will be code generated?

At a level of experience where I am, I want to avoid it, but I would love to hear a good case for code generated forms.

[Guest]

19 hours ago, Mike Torrettinni said:

Interesting view... where do you draw the line between code generated and visual? what's the threshold where you decide that form will be code generated?

That is the million dollar question, so to to say! I think you got the gist there from my confused posts.

[Mike Torrettinni 198]

5 hours ago, Dany Marmur said:

That is the million dollar question, so to to say! I think you got the gist there from my confused posts.

Oh, I was hoping you would share your experience... not looking for solution, just when do you personally decide what will be code generated and what not, an example where it works good for you or maybe what you tried and then decide that code generated is not suitable. Seemed like you do use it and you might have some experience to share.

 

[Guest]

OK, i'll try to expand, but these things are opinions, no "hard facts", sorry.

 

When i studied educational theory at uni there was this professor that had an explanation of why 10 or 16 point lists was no good. We all learn differently and i do not know where you are. But for me; implement it!! Do not think too much. For example, your search logic in a DM and your 19 forms. Then you will notice small pesky things that works in one dialog but not the other. You will refactor, consolidate and maybe you will be more happy with the 2nd, 3rd of even 4th refactoring. You have other projects perhaps. I cannot give a series of steps. There are patterns out there, of course. Also managing dialogs/forms usually is not an area where you need to be vary of performance. You'll notice when you forms/dialogs get so complex they start to take annoying time to open. It's the search logic that should be optimized. So your OT problem is a rather good example for experimenting. There are so many ways to do any given thing and only the bad solutions are bad.

 

Simply create (if you have the time and budget). HTH, /D

[PeterBelow 238]

On 5/17/2019 at 1:04 PM, Mike Torrettinni said:

Interestingly enough, nobody is suggesting to reduce the number of forms/frames. Odd. It's almost like when you have 1 class per unit, no matter how small the class is. I'm not there, yet 🙂

I re-checked and I have 19 Search forms... they are all modal forms that hover over data view and the behavior is the same: - search form is opened on top center of data view (Virtual treeview) and locates searched line; - Next/Prev works - search logic is very similar in all of the search forms, but on different data.

I need even more search forms, so I had this idea of single search form. I guess you guys are advising against this approach.

 

 

It all depends on how your application is constructed. In the largest one I ever wrote I used data classes with an ORM on the back to interact with the database. The application had a number of views to shows list of different kinds of those data objects (which represented the entities in the data model), and each of these views had a search function. They all used a common search dialog, which was configured at run-time using a configuration interface, which had implementations for each of the searchable data classes.  The dialog contained frames for the user to specify the search critertia, each of which had a dropdown list with the available searchable properties, applicable operators, and input controls (dynamically adjusted according to property type) to specify the criteria. The dialog build the WHERE clause to use from the input, which the user could modify to change the default AND combination used if necessary. Worked quite well, the work required to build the configuration interface was not that large since the dialog could use the data classes' metadata to construct the property list, figure out the applicable operators and input controls needed. The interface just told it which data class to configure itself for, which properties to exclude from the dropdown, and which values to offer for selection for properties with a restricted list of possible values.