multicol form related bugs &upload component inconsistencies

pureist

Run attached bsv:

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.

uploadcomponentdiffs.zip
37.03kB

uploadcomponentdiffs.zip
37.03kB

aware_support

None of these are bugs. Most of them are caused by using "tall" controls in multi-column forms. This is the limitation of version 7.0 and it WILL NOT be fixed. You need to work around this and be careful when using tall controls (grids, text area, document upload, HTML editor, swap select etc) in multi-column forms.

Form generation algorithm is row-based, not column-based, so if you have these:

Field1 Field2
Field 3 Field 4

and Field 2 or Field1 is "tall" you will get this:

Field1 Field2

Field3 Field4

So move them to the end of the layout as a workaround. Or use a single column. Or move tall controls to a separate tab.

Do NOT use grids in multi-column layout - they won't look good.

ALL the forms can be re-arranged to avoid this. Moreover, the end result will look better than in version 6.0 which used column-based generation.

Save/Close buttons behaviour on forms with tabs - this is how it works now and it won't be changed in the foreseeable future.

pureist

okay, but if nothing else, surely the two file upload components could behave the same way in multi-column forms [and be the same initial dimensions]??
(ie. both behave like the image upload component which in multi column forms expands WITHOUT moving everything below it down)
.
..and, the following worked correctly before (on multi column forms) and has only appeared since about 4 builds ago:

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