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.