Swap Select display cannot take other blank rows location

cishpix

Please see my first attach on the below first.

The swap select only take 1 row and cannot take free rows on the below so there are free space on the left column like this image.

How can I remove the free space?
Or can I merge some blank rows to be one row? (please see the first image)

Thank you

aware_support

This has been explained many times. If you use "tall" controls (swap select, grid, text area, HTML editor) in a multi-column forms all the adjacent controls will be pushed down because the form generation algorithm in version 7.0 is based on rows, not columns. You need to re-arrange your form appropriately. The best thing is not to use tall controls in multi-column layouts.

pureist

IF "tall" applies to the image upload component which starts 'tall' and gets 'taller', then this is not the case.
And, are you aware that there is an irregularity/inconsistency in the behavior of the Picture and Document upload components?
Run attached bsv to view this and more:

select 'NEW Requisitioner"
a tab will open with the new requisitioner form (two column)
BUG1: the paging bar does not appear on the 'Items' reference attribute grid. Why not?
BUG2: notice that the contents/height of the first tab pane of the form exceeds the fixed height (450px) of the form, BUT A SCROLL BAR DOES NOT APPEAR ON THE TAB PANE AS IT SHOULD, IT INSTEAD APPEARS ON THE CONTENT PANEL
- ie. to scroll the tab pane the user instead scrolls the content panel which means that the entire form scrolls up and down off screen
- therefore when the user switches tabs and the switched-to tab pane contents/height does not exceed the height of the form, the scroll bar disappears from the content panel and the form resizes every switch - NOT elegant
- it used to work correctly on forms (ie. the scroll bar would appear on the tab pane) up until you fixed (a few builds ago) the bug with the scroll bar appearing on the frame when the contents/height of a tab exceeded the height of the frame
- Now that is working correctly (ie. scroll bars appear on the tab pane not on the frame) but this new bug with scroll bars not appearing on tabs of forms has appeared
select section 2 ('sec2') of the form
notice how section 2 tab pane content/height does not exceed the height of the form?
BUG3: notice how the tab pane height contracts and the Create and Close buttons dart up the form?
this is wrong. the buttons should not dart up the screen and leave a blank no-mans land at the bottom of the form. what is the point in having a fixed height form if the buttons are going to dart up and down and leave blank area between them and the bottom of the form?
if a form does not have a fixed height, then it is to be expected that the Create and Close buttons will dart up and down the screen in sync with the height of the form/tab pane being expanded or contracted subject to the height of the contents, BUT the buttons will always remain a fixed CONSISTENT offset from the bottom of the form
BUT if a form has a fixed height it is because the configurer wants consistency in appearance/UI. ie. the buttons stay at the bottom of the form, a fixed/consistent offset from the bottom, irrespective of the height of the tab pane content
BUG4: then select section 1 ('Requisitioner') again. NOTE an active horizontal scroll bar appears on the 'items' reference attribute grid? WTF? why? how? ..there aren't any records
BUG5: the dimensions of the Picture and Document components are inconsistent/different - surely they should be the same by default for the purposes of consistency?
select an image for the 'Mugshot'
the component resizes height-wise WITHOUT expanding its row height and WITHOUT shifting rows beneath it down (ie. it just 'overlays' the rows beneath)?
- THIS IS GOOD, very smooth. It means you can leave sufficient space beneath the control as illustrated in the bsv so as to facilitate a smooth user experience
select a document for 'Biography'
BUG6: the component resizes height-wise by expanding its row which has the effect of shifting everything below it on the form down. NOT elegant.
conclusion: 16. should behave in the same way as 14.

aware_support wrote
This has been explained many times. If you use "tall" controls (swap select, grid, text area, HTML editor) in a multi-column forms all the adjacent controls will be pushed down because the form generation algorithm in version 7.0 is based on rows, not columns. You need to re-arrange your form appropriately. The best thing is not to use tall controls in multi-column layouts.

uploadcomponentdiffs.zip
37.03kB

uploadcomponentdiffs.zip
37.03kB