Form display problem with layout block(s)

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?

Were these Layout Block and form issues settled?

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 have tried re-ordering the LOBs, which changes their location, opened with different browser (Firefox), restarted computer. All to no avail.


Perhaps a bug and will need to send project to Duncan but wanted to check here first.

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.

1 Like

Thanks @JBTexas for the detailed reply.

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 :tumbler_glass: 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 :face_with_symbols_over_mouth:. Of course, this meant EVERY device’s orderings required fixing :sweat:. 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.” :smiley:

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.

As @Duncan wrote and @Woodrow quoted him on another thread:

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.

1 Like

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. :man_shrugging: