This is a sequel to my previous post, on understanding itemlocations.  What follows are some of my favourite itemlocation tips:

Be a Minimalist

Get rid of excess baggage in the itemlocation list. So if you have itemlocation entries x, y, width, offsety, after and offsetx - in that order - you can get rid of the x, y, and offsety entries, since "after" will override them and they are ignored anyway.

While building a form, it makes sense to drag and reorganize your form at your heart's content, amassing lengthy itemlocation lists as you do. But before you deploy your form, scroll through the source and trim out the unnecessary entries in the itemlocation list. (Then test it to ensure you didn't get carried away!)

The itemprevious compute

This is one of those tools, like duct tape or a multi-tool, that is never exactly the right tool for the job, but is always convenient, expedient and effective.

This compute sets the item reference to the SID of the form item immediately before the current item. So if you have a long list of fields (FIELD1, FIELD2, ...., FIELDn), one right after the other in the source code, and you want these to be vertically aligned in a column with (say) a 10pt gap between them, then it's an easy cut'n'paste job - the item location entries for FIELD2 to FIELDn are simply:

XML:

Relative Positioning

I love relative positioning!

The ability of forms to layout a page with pixel-perfect absolute positioning is an important feature. However, for day-to-day forms that do not need that level of precision, I prefer relative positioning almost all the time. It's a little more work when you lay out your pages up front, but it avoids a world of pain later when you want to adjust the form to add a new field in the middle of the page.

Lay out the form so that fields, labels, etc., are relative to the items that are visually just to the left or just above them. Then adding a field or reordering a field to appear earlier is just a matter of adjusting one or two fields, and everything else will fall into place naturally.

Another advantage of relative positioning: When label text can vary in size (say for computed or pre-populated text), labels can "grow" horizontally or vertically (with wrapping) and the rest of the form will adjust naturally without any ugly overlaps.

Let Forms Do It For You

It's often better to let forms figure out the width and height of an item. Don't specify these values absolutely in the itemlocation list unless you have to. Often, its even a good idea to take them out if they are there.

However, there are some exceptions to this rule of thumb:

• Fields for text entry - set the width wide enough for the text, (or set the scrollhoriz setting to never and set a max length if the text could be much longer)
• Labels where the text may be so long that it needs to wrap. In that case, you have to tell forms where the width should be - set it to the longest line possible, and forms will wrap the text there - but in this case, you need to leave enough space in the height to allow for all the lines; or let forms figure it out and don't set a height.

It should be obvious, but just in case: This approach works best when you are using relative positioning on a page. If you let forms figure out the right height for a label with dynamic text, then items below that label ought to be relatively positioned relative to the bottom of the label. Otherwise, when the label text grows it can overwrite absolutely positioned items below it.

Document order matters

I've harped on this before, but it bears repeating.

You generally want the fields, labels and other controls in a form to be in the same order in the xml file as they are on screen. The most obvious reason is that this takes care of the tab order for you - the "default" tab order is the xml file order (not the order on screen - which is why you want them to in the same order!). However, there are other benefits.

For one thing, it makes it much easier to navigate the source file.

For another, "after itemprevious" is the default position for an item that has no itemlocation entries (or at least no entries that dictate x, y coordinates) - so you can keep your itemlocation lists very clean by sticking with the document order.

As well, there are a few handy context menu commands that come into play: On the Design panel, right click a label / field / control that is absolutely positioned, and you have "Relative Align -> Below Previous item" and "Relative Align -> After Previous item". These are quite handy! After using these context menu commands, you can drag the control to add a bit of extra space, and forms will add the appropriate relative positioning Offsetx and Offsety items to the itemlocation list.

Now, if the fields are not in document order, don't despair. It's easy to fix: From the advanced perspective, you can drag & drop xfdl items (fields, labels, controls, etc) in the outline navigator, which will reorder them in the source file! Just remember to do any reordering of your source file before you start adding in relative positioning.

Adding space to radio button / check box item lists

Add an offsetx (with a value of 5 to 15 or so) in the itemset/extension/itemlocation list of horizontal radio button groups or checkbox,groups, to add a bit of horizontal space between options. For radio groups / check groups that display vertically, I don't usually find the extra space is necessary, but you could use offsety the same way.