next »

[Michael L.]

I love using layout tags when creating my forms, I find it is a very intuitive way to build forms visually.  One thing I have run into is trying to keep using the layout tag method for form creation, while incorporating Folder tabs.  I don't see any Folder / Page layout tag that would allow me to do this (help file mentions Group, Table, Tree and Scrollgrid as possible types of layout tags)... are there any plans to add layout tags for Folder tabs in?

Thanks,

Michael Laporte

[Sebastien F.]

Hello Michael,

I believe your request can make sense, so I have filed a new bug/enhancement #17194 to track this and raise discussions with others.

I think however that the typical forms using folder pages define the folder pages as parents of grids, which define group/table/tree/scrollgrids with layout tags like this:

LAYOUT
FOLDER
PAGE p1
GRID
{
... layout tags ...
}
END
END
PAGE p2
GRID
{
... layout tags ...
}
END
END
END

The nice thing with layout tags is that you can place containers side by side (vertically or horizontally), but I believe this need is seldom met with folder pages, since they are usually parents at first level of forms... ok... it depends the complexity of the form.

Seb

[Michael L.]

Thank you Sebastien!

Indeed, my form is getting rather complex ... in a nutshell I have a Tree widget on the left and on the right I have a Group box that contains fields for the parent record and below these fields is where I want folder tabs, each showing a Table of related child records.  The tables can have many columns, therefore folder tabs are ideal to conserve space and keep the child records logically grouped together.

[Sebastien F.]

Michael,

I understand the need...

As a side note, we cannot prevent you to write complex forms but I would strongly suggest to avoid this...

Complex forms can take time to be loaded and require complex (?multiple?) dialogs behind...

You should rather display the most important information in the main form and then open (popup) sub-windows to show/edit the details, to be closed after usage.

Unfortunately, if users want to browse in the treeview to check a detail information for different tree items, they will have to open the sub-window after each move in the treeview... Maybe here an option could be do put some customizable fields in the main form, letting the end user choose what information he wants to see (maybe in a table, with two columns (info + value) )?

Seb

[.]

Actually, I'm not very comfortable with this suggestion - let me explain:

1. the idea with the layout tags is to come back to the old .per days, where you could simply look at the .per and see what your screen will be.

having

Code

<T             ><G                         >
 [a             ]   [b                        ]
 [a             ]   [c                        ]
 

Is more readable than:

Code

HBOX
TABLE
{
[a           ]
[a           ]
}
END
GROUP
GRID
{
[b            ]
[c            ]
}
END
END
END
 

I don't see how we can simply show folder pages with this concept - at one point you will have to set a place holder and define the content of the place holder somewhere else, something like:

Code

<T               ><F  F1                          >
 [a               ]
 [b               ]
<                 ><                                 >
 
...
 
FOLDER F1
PAGE p1
...
END
END
 

And this idea raises my next problem:

2. this may explode the form.
One of the main issue with GDC layout is that it's a mix of character (fixed font) grid and proportional/stretchable grid.
The usual trap everyone falls into is the following:

Code

[a]
[c]
...
EDIT a = FORMONLY.a;
CHECKBOX c = FORMONLY.c, TEXT="my checkbox";
 

Doing that, field A will be as wide as checkbox C. But the first impression is that there is a bug because you defined A to be 1 char wide, and it's much wider - because C is much wider.

Then, if in a grid you insert a folder, the folder will be as large as its biggest page. And if you have something like

Code

GRID
{
[edit          ] 
<Folder f1 >
}
 

Field "edit" will be super large, but it's definitely not obvious when you look at the .per.

As Seb's answered, the last drawback with folders is that it generates a very huge form. Beside the fact it's pretty heavy for the system (mostly for GDC as it needs to render all the pages to render the folder with its correct size immediately), it's a known GUI bloopers to have too much pages (see http://books.google.fr/books?id=-kcKpqzbBR0C&pg=PA106&lpg=PA106&dq=gui+bloopers+tab&source=bl&ots=rPbKmS3UYQ&sig=BVOCKsLbDV16abBSuzhDOaDHm6k&hl=fr&ei=VBMJTMPDCYaH4QbEvoiMAQ&sa=X&oi=book_result&ct=result&resnum=2&ved=0CBwQ6AEwAQ#v=onepage&q=gui%20bloopers%20tab&f=false )

One point which is missing in Genero would be to have the classic design patter: tree on the left side, on right side you display a page depending on the selected tree item. We already discussed on how this could be done "4GL style", but higher priority items have made us too busy to provide a solution today.

[Reuben B.]

I love using layout tags when creating my forms, I find it is a very intuitive way to build forms visually.  One thing I have run into is trying to keep using the layout tag method for form creation, while incorporating Folder tabs.  I don't see any Folder / Page layout tag that would allow me to do this (help file mentions Group, Table, Tree and Scrollgrid as possible types of layout tags)... are there any plans to add layout tags for Folder tabs in?

Thanks,

Michael Laporte

... to build forms visually/WYWISYG, you could always use Form Designer in Genero Studio.

Regarding the discussion on complex forms with multiple folder pages, one of my local sites raised an issue about how a window was initially slow to display.  What we discovered was that when a window is first rendered, all of the information for ALL the folder pages is sent from the server to the GDC.  (you can view this in the GDC console or log).   So we raised the question with the GDC team, why don't we send the information for just the visible folder page, and send the information for the other folder pages as they are clicked on and rendered.   The reason why this doesn't happen at the moment is that the folder is sized so that it can display the largest folder page.   We would have to come up with a way to specify what the largest folder page is and/or handle the situation where the contents of  a page don't fit in the folder (i.e scrollbars inside a folder page!)

Reuben

[Rene S.]

Hello,
unfortunately some kind of per files (often per files using folders) become very complex.
This may happen for example when using folders with many pages.
May I suggest this to simplify per files:

A new widget defines a place-holder for a named window. Example: A folder-page just contains one place-holder for a window.
Now programmers can split complex form in several simplified forms. Within the 4gl-program, the program uses the OPEN WINDOW newWindow WITH FORM. If in the current form a place-holder for the new window 'newWindow' exists, the new window will be rendered at the given position rather then creating a new visual window.

Rene

[Sebastien F.]

A new widget defines a place-holder for a named window. Example: A folder-page just contains one place-holder for a window.
Now programmers can split complex form in several simplified forms. Within the 4gl-program, the program uses the OPEN WINDOW newWindow WITH FORM. If in the current form a place-holder for the new window 'newWindow' exists, the new window will be rendered at the given position rather then creating a new visual window.

Yes nice idea, I would however naturally expect a new 4gl instruction, or extend an existing instruction such as:

  DISPLAY FORM <form-name> INTO <container-of-current-form>

Having OPEN WINDOW behave differently as opening a new window sounds confusing to me...

Seb

[Michael L.]

Wow, I'm very happy to see the great discussion this question has spawned!

Here's my take on some of the ideas and replies thus far:

- I agree that complex forms generate added load on the GDC resources, however, I do believe that complex forms are here to stay.  Users are getting more comfortable and more sophisticated; in same cases demanding more complex forms to see all information at once.  Navigating multiple windows is becoming less desirable to them.  I do understand the benefits of only loading the information as it is needed, and this is where the developers need to get both performance and design in balance to keep users happy.

-As far as making the window slow to load, in my case it is the first/main program window and it will be easy to live with an additional second or two to load (albeit, it is still pretty darn fast right now with two Tree array widgets and two Groups of fields on the form).  I certainly would not want this type of delay on subsequent windows being loaded, and would have to look at the balance question I mentioned above.

-I also agree with Pierre-Nicholas that the Folder layout tag doesn't quite jive with the layout tag paradigm of trying to make it exactly WYSIWYG.  However, I think that even now, with variable-width fonts and the way widgets lineup on the form, the layout approach is a visual approximation of the form, not the exact final output.  In that sense, I do think Folder layout tags fit in.  As for exploding the form, I can see where we could get into trouble with really diverse forms on each folder page.  In my case however, I want display arrays in each folder tab, so I think that each could easily be designed to be the same width.  I think my main concern when posting the question originally was that I had no way to put folder tabs into my form once it was designed with layout tags.  To put in tabs, I would have to redo the whole form using the "non-layout tag" approach, which was going to be a pain...

-I love the place holder idea and I agree with Seb that a new instruction should be used for this.  This would probably help me with the problem of redoing the form to get folder tabs in!  :D.

-Finally, thanks Reuben for the suggestion to use the Form Designer in Genero Studio, I had not thought of that, and this is the perfect project to try it out on!

-Mike