Developing a form (questionnaire) with multiple parts - seemingly perfect for use of layout blocks. Each of the layout blocks contains various related text blocks, input texts, notations, titles, etc. All the items in each layout block are grouped, in the proper z-order. It all seems to work correctly, prompting input texts through the form - across layout block boundaries - to the end. Except 1 thing:
The borders of the text input items are missing when displayed in all of the layout blocks EXCEPT the first (top) one - if it contains 3 text inputs, all show borders! If I switch the top two layout blocks, the ânewâ top blocks displays its text inputsâ borders, and all others donât display borders. If I put the whole contents of the form in ONE layout block, all to the text inputs display a border (my only known fix so far).
Is it a requirement that all elements of a âformâ can only reside in one layout block? The other form features (identifying all text inputs, the âreply-toâ email item, tabbing z-order, etc.) seem to be correct across multiple layout blocks. Or is this a bug, perhaps an early exit from a loop through the layout blocks in a page while drawing some borders therein? Or the âlossâ of the border color between two blocks?
Hi @JBTexas, not aware of this issue, maybe thereâs a bug we need to look into. Could you send us the project file, or even just the form page, to check this out?
Iâm having some misbehaviour with Layout Blocks (LOB) using forms as well. Not exactly these, but seemingly similar.
My issue seems associated with duplicating a LOB. Changes to the second (and third) block(s) show on Sparkleâs canvas properly (image 1) but text and fields appear in LOB 1 only in Preview (image 2) and on publish site. Boxes however appear in the proper LOB.
I finally gave up trying to diagnose the use of layout blocks in a form. I ended up with the complete form in a single layout block, which works correctly.
It seems that you may still be able to have other layout blocks on the page (for example for a page header or footer), as long as they donât conflict with the real estate of your form. (I could imagine some issues with forms spanning layout blocks, like making the ordered list of data to be posted which have mixed display positions, z-order, groups, etc. so it wasnât a deal breaker for me.)
I DID discover another annoying feature of layout blocks - they âcaptureâ free text fields and other items that are dragged (intentionally or accidentally) over them - imbedding the item in the layout block. Easy enough to disengage them by dragging them out using the page structure list, but if you support more than one screen size or the layout block is set to appear on every page, havoc ensues behind the scenes in the other view or pages. I first encountered this trying to design a layout block for a site page header, with space reserved for an overlayed page title. You can build it that way (text block topmost), but as soon as you drag it for positioning, it is snatched by the layout block - and may suddenly appear on every page! If you do it the hard way, the same position adjustment in the Arrange panel, by setting or incrementing horizontal or vertical position(s), the adjusted item will NOT be embedded.
I too have stumbled upon LOB peccadillos and the gentle coaxing required to work with them, sometimes only after a smack on the desktop and a necessary break (maybe even a needed whisky to calm). The one most disturbing for me is the z-reorderings when a menu or higher-ordered page header gets eaten by a lower LOB thereby re-positioning all the LOBs . Of course, this meant EVERY deviceâs orderings required fixing . I now record the top/bottom px of each LOB to ease the irritant when this occurs, but also have become much more careful when dragging items over LOBsâgenerally, I donât but manually enter the vertical location instead. Yes, such âautocorrectionsâ piss me off same as Microsoft Officeâs default settings didââNo? you stupid machine. I donât want a single space after every #$%^# period! Yes, I know, Iâm old-school and demand two spaces at end of a sentence.â
Eventually, I learned to work with even Microsoftâs âall-knowingâ software when itâs âknowledgeâ clashed with my preferences. And similar to back then, I am learning how to coax LOBs because their benefits are great, especially on my newer projects.
With that written, I believe I solved this specific problem, or a workaround at least as it seems there is a small sequencing bug here.
By duplicating the entire page, the LOBs corrected themselves to appear exactly as expected. Thus, it seems copy/paste properly adds an LOB but fails to rewrite the pageâs z-order. When the whole page is rewritten (using Duplicate), the LOBs are fixed (see image). But as noted before, I am a web-coding pre-schooler and will leave the explanation to @duncan and the talented experts.
Disappointing Addendum: Sorry, I jumped the gun; the fix didnât fix. When the fields are ticked to be collected with the form, the duplicate page returns to looking like the first. So, no fix. It seems the collected fields must be in a single LOB.
to calm). The one most disturbing for me is the z-reorderings when a menu or higher-ordered page header gets eaten by a lower LOB thereby re-positioning all the LOBs 
. Of course, this meant EVERY deviceâs orderings required fixing 
. I now record the top/bottom px of each LOB to ease the irritant when this occurs, but also have become much more careful when dragging items over LOBsâgenerally, I donât but manually enter the vertical location instead. Yes, such âautocorrectionsâ piss me off same as Microsoft Officeâs default settings didââNo? you stupid machine. I donât want a single space after every #$%^# period! Yes, I know, Iâm old-school and demand two spaces at end of a sentence.â 
