VTML Tips and Techniques: Attributes

On this page:

A name is not an alias New
Comments
Ignoring attributes
Display-only controls
Focus Updated
Contributions!

The ATTRIB tag is used to tie a control to a tag attribute. But what exactly does the NAME attribute of an ATTRIB tag do? When you look at the ATTRIB tag, the attribute NAME may suggest that it (also) establishes an alternative way to refer to the value the user entered in a control, in other words: an alias for the control. So if your ATTRIB tag looks like this:

<ATTRIB NAME="Fudge" CONTROL="txtFudge">
	

it may seem natural to refer to the attribute value in your TAGLAYOUT section like this:

$${FUDGE}
	

But that won't work. What the NAME attribute really does is identify the tag attribute by name, and tie it to the control. You still have to use the control name to refer to its value:

$${txtFudge}
	

Thanks to Ric Dragon for this tip!

Although the "official" documentation from HomeSite indicates this section can only contain ATTRIB tags, actually the ATTRIBUTES section can contain ordinary (HTML) comment tags as well. This is quite useful for documenting different parts of a complicated tag editor if just blank lines (also possible for readability) don't suffice any more. Here's a fragment that illustrates this; the comments correspond to TabPages in the EDITORLAYOUT section (from Control.vtm):

<ATTRIBUTES>
    <!-- Common -->
    <ATTRIB NAME="NAME"      CONTROL="txtName">
    <ATTRIB NAME="WIDTH"     CONTROL="dropWidth">
    <ATTRIB NAME="HEIGHT"    CONTROL="dropHeight">
    ...
    <!-- Drop Down -->
    <ATTRIB NAME="EDITABLE"  CONTROL="checkDropDownEditable">
    <!-- Check Box -->
    <ATTRIB NAME="CAPTION"   CONTROL="txtCheckBoxCaption">
    <ATTRIB NAME="CHECKED"   CONTROL="checkCheckBoxChecked">
    <!-- Text Area -->
    <ATTRIB NAME="SCROLLBAR" CONTROL="dropTextAreaScrollbar">
    <ATTRIB NAME="WRAP"      CONTROL="checkTextAreaWrap">
</ATTRIBUTES>
	

Comments in the ATTRIBUTES section can also be used to temporarily disable something (Attrib.vtm):

<ATTRIBUTES>
    <ATTRIB NAME="NAME"     CONTROL="txtName">
    <ATTRIB NAME="CONTROL"  CONTROL="txtControl">
    <!-- ATTRIB NAME="DEFAULT" CONTROL="txtDefault" -->
</ATTRIBUTES>
	

... or for anything else you think needs commenting or commenting out.

Of course the main function of the ATTRIB tag in the ATTRIBUTES section is to read an attribute when editing (rather than creating) a tag and assign it to a control for display. Any attribute that is not picked up like that will automatically be assigned to the special variable TAGDATAUnknownAttributes so they can be re-written in the TAGLAYOUT section.

But what if there are attributes that you only want to generate, and you still want to write TAGDATAUnknownAttributes to be armed against future extensions of the language? That happened to me when I decided I wanted to have a mechanism for generating LFWIDTH and LFHEIGHT attributes instead of having input fields for them. I would either keep the old values (kept by TAGDATAUnknownAttributes) when I did not want to generate new values, or I would generate new values but get the old ones back as well.

As with many such problems, the technique to get around this is really simple - once found: just read the attributes with an ATTRIB tag, but assign them to a dummy variable instead of a real control. This effectively makes the attributes write-only, and if not re-generated they nicely disappear. Like this:

<ATTRIB NAME="LFWIDTH"  CONTROL="dummy">
<!-- Prevents attribute from being picked up by TAGDATAUnknownAttributes -->
<ATTRIB NAME="LFHEIGHT" CONTROL="dummy">
<!-- Prevents attribute from being picked up by TAGDATAUnknownAttributes -->
	

(Originally, the comments are written right after the statement they refer to, on a single line.)

For some tags there are attributes that take a list of things as their value rather than a single value. Lists of column widths, lists of font names, lists of MIME types... But the ATTRIBUTES section has no way of parsing such lists into their separate components to be able to display them into the separate controls that can be used to build such a list.

Usually such lists are built from separate DropDown controls and you can make the first one EDITABLE so the current value can be assigned to it (and remain unchanged if not touched). But if the user does want to change the current list, the current value disappears as soon as that first DropDown is used to change something. What is needed is some mechanism to only display the current value of the attribute so it can serve as a reminder while building a new one.

As is usually the case, once I hit on it, the solution actually proved to be quite simple: a Label control does not need to be given a CAPTION value in the EDITORLAYOUT section; it can be assigned a value from an ATTRIB tag in the ATTRIBUTES section.

This screen shot shows such a tag editor in action while editing an existing tag:

The following fragment from the ATTRIB section shows how the current attribute values are assigned both to the first corresponding DropDown as well as the label for display:

<ATTRIB NAME="HREF"     CONTROL="urlHref">
<ATTRIB NAME="TYPE"     CONTROL="dropType">
<ATTRIB NAME="REL"      CONTROL="listRel">
<ATTRIB NAME="REL"      CONTROL="dropRel1">
<ATTRIB NAME="REV"      CONTROL="listRev">
<ATTRIB NAME="REV"      CONTROL="dropRev1">
<ATTRIB NAME="MEDIA"    CONTROL="listMedia">
<ATTRIB NAME="MEDIA"    CONTROL="dropMedia1">
	

While you can use a Label control to display (write) an attribute value to the screen, it's not possible to query that value from the TAGLAYOUT section: a label is write-only. How I stumbled over this is related in Was that value changed?

Note: Link.vtm will be part of my next package of Tag editors to be published on this site.

I've already mentioned the following tip in the documentation for the attributes section, but it won't harm to repeat it in this context, since this is really important:

While in general it doesn't matter much in which order the ATTRIB tags occur, and the order can be quite different from the order in which the controls occur in the EDITORLAYOUT section, it is important which is the first ATTRIB: the control that corresponds to this is the one to receive focus when the tag editor is displayed.

While it is possible to use ATTRIB tags to read current attribute values and display them in a label control, and it is quite possible to have such a label occur as the first control in a tag editor, make sure this label control is not the first one listed in the ATTRIBUTES section: the result would be that no input control gets focus when the editor window is displayed. Simply list the first user input control first, and list the label control somewhere after it.

Even if the tag editor is a write-only editor this technique can be used - if you don't refer to at least one input field in the ATTRIBUTES section, no field will get focus. You can use a "dummy" attribute name and "assign" it to the first input control, as in the following example from my Mailto: tag editor:

<ATTRIB NAME="dummy" CONTROL="txtAddress">
	

Although the first attribute in the list of ATTRIB tags determines which control gets focus when the tag editor window is displayed, the order in which ATTRIB tags appear does not determine tabbing order in the editor: that is determined by the order in which the controls appear in the EDITORLAYOUT section.

There is however one circumstance where this doesn't work - not directly anyway: when the first input field is not on the first tab in a dialog where there are no input fields before the tab dialog either. (This is the case for my HTML tag editors for those tags that don't have any attributes defined in HTML 3.2 but have acquired them in HTML 4.0: the first tab then contains a comment about this, after that there are tabs for HTML 4.0 specific attributes.) So: for the first field on the second tab to get focus we need an input on the first tab to refer to from the ATTRIBUTES section - even if there isn't one. The workaround is to use a hidden field on the first tab, and refer to that from the ATTRIBUTES section. Add the hidden field to the first tab like this:

<CONTROL TYPE="TextBox" NAME="dummy" WIDTH=1 HEIGHT=1 RIGHT=-20 DOWN=-20>
	

Then refer to it from the ATTRIBUTES section:

<ATTRIB NAME="dummy" CONTROL="dummy"><!-- hidden field to create a focus -->
	

Now the first input field on the second  tab (or following tabs) will get focus when you activate that tab!

Do you have any VTML Tips or Techniques to share? If it's for the Attributes 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