Understanding Borders and Margins in Flowed Layouts

Flowed Layouts

At Avoka, we’re big fans of flowed layouts in Designer. There are a number of reasons for this, some fairly obvious, others less so:

• If you’re going to use features such as repeatable sections, expanding tables, or hide/show logic, you have to use flowed layouts – as the expanding sections grow, the sections below flow down the page. If you don’t use flowed layouts, the expanded sections will just flow over the top of the ones already there.
• In many ways, using a flowed layout is a much more maintainable way to build a form. If you use positioned layouts, and need to insert a new field somewhere in the form, you need to re-adjust all the fields below to accomodate the new field. However, if you’re using flowed layouts, all the fields below will simply shift down, and there’s nothing extra to do.
• Flowed layouts take away a lot of the pain of lining fields up. In a positioned layout, you need to use snap-to grids, rulers, explicit x/y coordinates, in order to get fields lined up. In flowed layouts, you just drop the fields into a flowed sub-form, and they will all automatically line up.

Unfortunately, flowed layouts can be a little difficult to get your head around. With a positioned layout, you can simply drop a field on a form, resize it, and drag it to wherever you want. With a flowed layout, Reader takes care of a lot of the positioning for you, so you sometimes have to use some tricks to get the layout that you want.

This article talks about some of the difficulties with flowed layouts, as well as showing some of the tricks we use to get things looking the way you want them.

A heading with a thick underline

Here is a basic heading as we might insert it into a XFA form. It consists of a subform, and a heading text object within the subform. We’ve put two versions of the same heading into a vertically flowed layout.

The yellow background and the blue/red border are there just to show where the different subforms start and stop.

Let’s imagine we want to add a solid line below the heading, creating an underline effect. There are several ways to achieve this, including adding a line object, or adding a separate subform with a background color. In this case, we’re going to achieve the effect by adding a bottom border to the object. For the sake of illustration, we’re going to add an 4mm border, which is probably a bit larger than you would normally want – but it helps to show what’s going on.

Once we add the border, we get a form that looks like this:

This is really interesting. What we see is that the border doesn’t increase the size of the subform – the border actually overlays both the subform above and below. With a very thin border, this is usually unnoticable, but with a thick border like this, this causes the border to overlay the text both above and below.

There is actually a very good reason that Reader paints half the border above and half below – it means that if you have two text fields, for example, both with borders, immediately above and below each other – both borders will overlap, and you’ll only get a single width border, rather than an ugly double width border.For example, here are two rectangles with 1mm borders in a flowed layout:

As you can see, despite they fact that there are actually two borders at the boundary, because they each overlap half up and half down, the effect is a single width line.

But this isn’t quite what we want in this case.

Let’s add a background fill to the lower subform. This results in the following:

From this we can see that Reader “paints” the subforms in a particular order. First the top subform, then the border, then the lower sub-form. The painting of the lower subform overlays the border. This doesn’t solve our problem, because we only have a 2mm border.

In order to fix this, the first thing we need to do is add a bottom margin to the top subform. Adding a margin does increase the size of the subform. It also instructs Reader to not lay out any fields within the margin area, thus ensuring that the text object will not be overwritten. We need to make the height of the margin one half of the height of the border (or greater), since only half the border is painted in the upper subform. The margin settings are shown below:

This results in the following:

We’ve eliminated the overflow on the upper subform. Now we need to get rid of the overflow on the lower sub-form. One way to do this would be to add an upper margin on the lower subform. However, this puts a requirement on whatever element we put below the heading to implement the upper margin. It would be much better if we could solve the problem purely within the upper subform itself. The way to do this is to wrap the upper subform in another subform (right click in Designer and select “Wrap in Subform”), and then add another 2mm margin to that subform.

The nested subforms are shown here:

This finally gives us the result we want – a 4mm bottom border without any overlays.

.

Conclusion

While this has been a slightly contrived example, we hope that it illustrates some of the subtleties of borders and margins in LiveCycle Designer and Reader. This also serves as a useful technique for achieving thicker borders in flowed layouts.

A Quick Way to get to the Script Editor in Designer

When you first start up Designer, the script editor is only half visible just underneath the toolbar. Usually I make it a little bigger by moving the thumb down a bit, like this:

Then I double click on the thumb to move it all the way to the top, and double click again to re-expand.

But this is very inconvenient. The script editor is not really big enough to see bigger blocks of script, and if I increase its size, it takes up too much of the screen real-estate that I need for actually designing my form. So I end up continuously making it bigger and smaller depending on what I’m doing. Very irritating.

Here’s a simple way around this.

Firstly, set up a keyboard shortcut to toggle the Script Editor visibility. Use the Tools/Keyboard Shortcuts… menu, select Product Area = Window, find the Script Editor command. Then click in the “New Shortcut” field, press F4 (or your shortcut of choice), and click Assign.

Then re-arrange your Script Editor to suite your needs. My favourite is detached from the main window (or undocked), and fairly large, as shown below:

There is a bit of a trick to get this right, because as soon as you make the Script Editor a bit large, it will try to dock whenever you move it. So…

• To undock it, double click on the move bar of the Script Editor. (The move bar will appear either at the top or left of the Script Editor, depending where it’s docked.)
• Then reposition the Script Editor, NOT by moving it, but rather by resizing both the top left and bottom right corners. Resizing won’t cause the Editor to dock, whereas even the slightest movement can.

From this point on, a single F4 keypress will toggle the Script Editor on and off, and I always have the script editor just where I need it when I need it.

Many thanks to Stefan Cameron for this trick.