Subscribe for automatic updates: RSS icon RSS

Login icon Sign in for full access | Help icon Help
Advanced search

Pages: [1]
  Reply  |  Print  
Author Topic: Table Container Width (GDC)  (Read 12350 times)
Stephen T.
Posts: 114


« on: October 14, 2015, 07:07:23 pm »

Genero Desktop Client
Version 2.50.12 build-5028

FGL fglrun 2.50.08 build-2343.8

Is there a way to force the width of a defined table to stop after the last column? In the attached image the marked areas are beyond the last column. I would like to shrink the table so that table boundary moves left, allowing more space on the right for the other groups.

Is that possible? I can't see a style or attribute that seems to do it.


* Screenshot from 2015-10-14 17-52-15 Edited.png (107.4 KB, 1920x1080 - viewed 1505 times.)
Reuben B.
Four Js
Posts: 1049


« Reply #1 on: October 14, 2015, 09:56:48 pm »

Hi Stephen,

You would need to supply the .per so that we can see if you are using a pattern utilising a combination of VBOX/HBOX, or a single GRID with Layout Tags.

You will have more control with a GRID + Layout Tags, then you would if using a combination of VBOX/HBOX where stretchable containers/widgets may shrink/grow as the user resizes the window.  (for your window, note what resizes when you resize the window, or what happens if you change the default font size etc)

Reuben

Product Consultant (Asia Pacific)
Developer Relations Manager (Worldwide)
Author of https://4js.com/ask-reuben
Contributor to https://github.com/FourjsGenero
Bryce S.
Posts: 52


« Reply #2 on: October 14, 2015, 10:37:34 pm »

Hi Stephen,

Just thought I'd suggest a completely different approach - can you get your database to record the changes?
For tables where we want to know who changed what and when we just create triggers on the table for insert, delete and update actions that write the current row to a corresponding history table (we're using informix but I think most databases will do this). Then it doesn't matter what is happening on the client, you are just capturing the actual data change at the back end.

Regards,
  Bryce Stenberg.
Bryce S.
Posts: 52


« Reply #3 on: October 14, 2015, 11:46:54 pm »

(ouch - sorry previous was reply to wrong topic) - Bryce Stenberg.
Stephen T.
Posts: 114


« Reply #4 on: October 15, 2015, 10:35:26 am »

Hi Stephen,

You would need to supply the .per so that we can see if you are using a pattern utilising a combination of VBOX/HBOX, or a single GRID with Layout Tags.

You will have more control with a GRID + Layout Tags, then you would if using a combination of VBOX/HBOX where stretchable containers/widgets may shrink/grow as the user resizes the window.  (for your window, note what resizes when you resize the window, or what happens if you change the default font size etc)

Reuben

Morning Reuben,
The form is attached - I find getting HBOXs and VBOXs to work in conjunction a bit of a pain (I really should have spent the time and set up a couple of templates for that by now!), so the form is made up mainly of layout tags.

Steve

* psrceModify1.per (15.58 KB - downloaded 762 times.)
Reuben B.
Four Js
Posts: 1049


« Reply #5 on: October 26, 2015, 11:04:45 pm »

Stephen,

Sorry for not replying sooner, got distracted by other things and did not get back to this.

I said GRID+Layout Tags give you more control but in this case too much control.  The width of your tables is determined in conjunction with its indicated position relative to other widgets/container in the parent grid.  Easiest place to explain with your form is if you look around column 121, you have the edge of Group ghdr, Table tdet, and the fields aa,ac,ad,...,ag, as they are all in the same parent grid, and defined to start/end in same column they will. 

So for your issue, using VBOX so that the top/middle/bottom thirds of your form are independent of one another is probably the way too go, and similarly in middle/bottom third using HBOX.  Compare your form and the attached form, particular when you resize the form or display on different screens.  You should see tables changing size to fit available space rather than having their size dictated by other elements in the form.

Reuben

* psrceModify2.per (15.77 KB - downloaded 736 times.)

Product Consultant (Asia Pacific)
Developer Relations Manager (Worldwide)
Author of https://4js.com/ask-reuben
Contributor to https://github.com/FourjsGenero
Stephen T.
Posts: 114


« Reply #6 on: October 28, 2015, 02:39:42 pm »

Reuben,
No problem - thanks for taking the time to look at it.
Running the revised form here, shows little difference to my untrained eye (but my eyesight isn't what it was!).

But it's no great shakes as I saw similar rendering of tables in the earlier releases - I just thought that I might have missed a style or some attribute on the table widget that either forced the right side of the table to be restricted to the last column or even for each column to be expanded proportionally to fill the extra space, rather than having a 'non-column'.

I'll play around and see what I can get.

Thanks again.
Reuben B.
Four Js
Posts: 1049


« Reply #7 on: October 28, 2015, 11:22:28 pm »

The difference in rendering between your form and my form will be most noticeable when you resize the window.   With LayoutTags as you have, the TABLE will be sized relative to other elements in the GRID.  With VBOX/HBOX, each child is independent and hence size of other GRID's has less impact on table, it will stretch to fit remaining space.  A table will never not stretch.

It might not seem obvious but the bit of the documentation that perhaps explains it is this one https://4js.com/online_documentation/fjs-fgl-manual-html/#c_fgl_layout_012.html.  Notice how it says TABLE items will always grow horizontally.   There is no STRETCH=NONE, or WANTFIXEDPAGESIZE in the horizontal direction.  It is interesting that TABLE is the odd one out in that it is the only element we can't control.  So there isn't "a style or some attribute on the table widget that either forced the right side of the table to be restricted to the last column".

Your comment "even for each column to be expanded proportionally to fill the extra space, rather than having a 'non-column'.".  We do have a style (resizeFillsEmptySpace) that makes the last column take up the remaining space.  Hypothetically and it will be upto the developers to comment further, there could be something similar that makes each column proportionally wider rather than adding the increase all to one column.



Product Consultant (Asia Pacific)
Developer Relations Manager (Worldwide)
Author of https://4js.com/ask-reuben
Contributor to https://github.com/FourjsGenero
Pages: [1]
  Reply  |  Print  
 
Jump to:  

Powered by SMF 1.1.21 | SMF © 2015, Simple Machines