VTML Tips and Techniques: Editorlayout

On this page:

Minimum width
More about width
Tabbing order
Scope
What anchor?
Left and Up
List or Combo?
Two Lists
Textarea New
Hiding a control
Contributions!

This is a really simple one: just a single number.

Many people have complained that when they have set up Windows to use large fonts, in some of the visual editors the text "Output on single line" somehow overlays the Apply button. Actually, it's not the text that hides the button or part of it, but a lot of needless white space after it.

Well, I've determined the absolute minimum width for a visual editor to prevent this from happening. It's 466. Not 465, not 467, but 466. Use that as a minimum WIDTH attribute in your EDITORLAYOUT tags, and you'll have one problem with large fonts solved.

In my own tag editors I use multiples of 5 for most sizing, so all my tag editors have a minimum width of 470, for example (from Attrib.vtm):

<EDITORLAYOUT WIDTH=470 HEIGHT=85>
	

Here's what that much too wide editor looks like - with small fonts:

- and with large fonts at a width of 465 (just one pixel too narrow) and the Cancel button selected so you can see that somehow the space for the checkbox label overlays the Apply button:

Curiously, if you leave out the WIDTH attribute altogether you get a default width that is different for small fonts and large fonts: with small fonts the default width of an editor is 473 while with large fonts the default width is 582 (much larger than necessary to get that checkbox text space off the Apply button).

Also noteworthy is that the actual width of a window is always 16 pixels more than the pixel width given in the EDITORLAYOUT; this must be for window borders added to your working area on the window.

Here's another simple one.

The order in which input controls appear in the EDITORLAYOUT section determines the tabbing order: the order in which the fields are chosen consecutively when using the TAB key to navigate between them. The tabbing order, and the order in which the controls are specified, is completely independent from how the controls are "tied" to each other by means of the ANCHOR attribute.

That means that if your window layout needs fields laid out in columns, you can simply specify all the fields in the first column first, the next column next, etc. The user will then be able to tab through the fields column by column.

The NAME attribute of a CONTROL and a CONTAINER is not required. But you need it if you want to refer to it, for instance to "tie" controls to each other by means of the ANCHOR attribute so their positioning is relative, or to make sure all labels have the same width by specifying the width of only the first, and use the name of that control as the width for all the others; it simplifies maintenance and consistent layout enormously.

There are two things here to watch out for:

• Names have scope: the scope is the container a control is contained in. Outside that container, its name is unknown; a reference to a control for an ANCHOR or WIDTH will not work if that control is in a different container. Sensible defaults apply:
  • when a control is anchored to another that is outside of the scope, the container it's in is used as anchor instead;
  • when a control is given a width (or height) of another control that is outside of scope, a default applies as well; for labels for instance it's the width of the label actually takes up on the screen (so it will probably run together with the field next to it)
  So when you've made some change to a tag editor and you see controls appearing in unexpected places or labels with the wrong widths, consider typos first, and scope next!
• There is only backward referencing: you can only refer to the name of a control that has been defined before but not to one further down in the EDITORLAYOUT. This is another possible reason why after a change to a tag editor controls can start appearing in odd places.

If a control (or container) is not given an ANCHOR to tie itself to, the (default) anchor becomes the container it's contained in. And then it doesn't matter what corner is defined either: the corner of the default anchor is always the "NW" corner of that container. (Which indicates that the CORNER attribute will only work in conjunction with the ANCHOR attribute!)

It's easy enough to see what the RIGHT and DOWN attributes are for: they position a control relative to an anchor. And we've already seen what happens when the anchor is not defined.

But why are there no LEFT and UP attributes? Because both RIGHT and DOWN accept negative values. It's quite simple, really, but it took a bit of poking around before I realized this...

While VTML does not provide a listbox as a control (I could give you a good reason for that, but that's outside the scope of this document), there is a DropDown control which can behave either as a dropdown listbox or as a dropdown combobox, depending on the value of the attribute EDITABLE: When EDITABLE is present just by itself (as a toggle) or has the value "Yes" it becomes a dropdown combobox, and allows the user to type in a value that's not in the list given; when EDITABLE is absent or "No", the control behaves as an ordinary dropdown list box.

So when to use what? Here are a few rules of thumb:

• When you need the user to choose one from fixed set of possible values and the attribute is a required attribute, just provide the list of the possible values and have the DropDown not editable.
• If there are only a few values to choose from and one of them is the default, you can attach the SELECTED attribute to that item, and not write it out in the TAGLAYOUT section.
• When there is a fixed set of values to choose from but the attribute is not required, do not make the DropDown editable to enable the user to erase it (it would also enable the user to enter a different, non-legal value!); instead, add an empty choice at the top of the list.
• When you give a list of values but there are potentially more possible ones than you can sum up, do make the DropDown editable so the user can type in a value that does not occur in the list; in this case an empty choice is not needed. Good examples are lists of MIME types or the FontPicker (so you can allow the user to type in a font name that does exist and is meaningful but doesn't happen to be installed on her system).

So what if HTML defines a fixed set of possible values for an attribute but a particular browser allows a superset of that? The answer is to use two DropDown controls, both not editable (and both with an empty entry at the top if the attribute is not required.

The technique used for this is explained on the VTML Tips and Techniques: General page since it involves not only the EDITORLAYOUT section but the ATTRIBUTES and TAGLAYOUT sections as well.

The TEXTAREA control, used mainly to allow the user to type in "free-format" text, has a few peculiarities that should be taken into account when using one:

• A Textarea can optionally have scrollbars: a horizontal one, a vertical one, both, or none at all; the default is a vertical scrollbar. You can also set it to wrap text automatically. Both options are quite useful but if you don't think it through, they will get in each other's way: when the text is wrapping, you don't need a horizontal scrollbar - and when you do have a horizontal scroll bar, the text isn't wrapped, is it? In fact, when you specify a setting for the SCROLLBAR attribute that includes a horizontal scrollbar ("horizontal" or "both") the setting for the WRAP attribute is ignored.
  Actually, I found this behavior rather annoying; so in the Control.vtm that's part of the updated package of VTML Tag Definitions the logic is reversed: if you specify WRAP, the editor assumes you do indeed mean the Textarea to wrap text automatically, and it will "remove" any horizontal scrollbar from the SCROLLBAR setting. But of course you can still type in a TEXTAREA tag manually so it's good to be aware of its real behavior.
• Text that was wrapped automatically will be written out in a single line when the control's content are output, and a hard return will result in a new line in the output. However, while reading the content of an attribute into a textarea when editing a tag, the new lines are ignored: not even a space is put in their place! Whether the Textarea is set to wrap or not doesn't make any difference. If the text that was there was not all that free-format but in fact formatted, the formatting will be lost unless manually restored by putting the line breaks back to where they were. Or you may want to type a space at the end of each line.
• Putting Textareas on a set of TabPages can also be tricky. The logical thing to do seems to give the Textarea a "MAXIMUM" height. However, when the TabDialog is set to MULTILINE="Yes" and more than one row of tabs does indeed appear, the Textareas on the tabs on the first row seem to be cut off and run off the bottom of the tab. This doesn't happen on the tabs of the other rows, only on the first row. (This could actually a buglet, but I'm not sure.) The solution is to use a fixed height defined in pixels.

Did you ever feel the need to hide a control? There's no HIDE attribute for controls in VTML but it is still possible with a little smoke and mirrors. The item Was that value changed? on the General page explains how it's done and what it can be used for (which is why it's there and not here).

Do you have any VTML Tips or Techniques to share? If it's for the Editorlayout section, use the following email link, otherwise go to the page corresponding to the section it's about and use the Contributions! mail link from there, so your mail will have the correct subject.

Please explain why it's such a good tip, and illustrate with example code where appropriate. Also let me know whether you want you email address mentioned here, or only your name.

Send your contribution to: VTML Tips and Techniques Contributions

The VTML Tips and Techniques sections are:

• General
• Editorlayout section
• Attributes section
• Taglayout section
• Tagdescription section
• Tag Chooser