Please enable JavaScript to view this site.

Updated December 2013

If tooltip (String) is specified, and if the control is clickable, then the specified string will appear automatically just above or below the control when the mouse hovers over it for about one second. This is useful for additional explanation about what will happen when the control is clicked.

If you want to associate a tooltip with a static text control, it must have the MBF_KBD style flag and a click string defined in the ctype parameter. Otherwise the control is not really "clickable", or more precisely, the click action is ignored and so is the tooltip feature. If you want to have a tooltip even though there is no click action, the workaround is to use "VK_NULL" from the Virtual Key Symbolic Names table.

Update: Context and Hover Menus

With A-Shell 6.1.1335 of January 2013, the syntax of tooltip has been expanded for static image controls to allow for context and "hover" menus.

Tooltip only (original syntax):

tooltip

Menu only:

\menudef

Tooltip and menu:

>tooltip\menudef

This scheme, with > and \ leadins, follows the general syntax relating to tooltips and context menus supported by INFLD's hlpidx parameter.

The menudef syntax is:

\{@<attrib>\} <text>,<cmd>; ... <text>,<cmd>;

It must start with a leading backslash, followed by an optional list of attributes (which must begin with "@" and end with "\"), followed by one or more <text>,<cmd> pairs, each terminated with a semicolon. This also matches the syntax used for INFLD menu definitions, and XTREE PopupMenu definitions, except that the attribute list is new, and there are no special $cmds yet defined.

The only attribute currently supported is:

@Hover{=##}

Where the optional =## may be used to specify the millisecond hover time before the menu appears. 0 indicates that the menu should appear immediately with no hover delay; omit the =## clause for the system default  hover delay (typically 400ms). If the Hover attribute is not specified, then the context menu acts like a typical one, i.e. doesn't appear unless you right click on the control.

Each <text> field contains the text to display in the menu, with an optional image specification, enclosed in vertical bars, i.e.:

|imagespec{=##}|display text

This is identical to the format supported by the AUI_MENU mnutxt parameter.

The optional =## clause at the end of the image spec specifies the size of the displayed image in pixels. The width and height of the image will be the same, so only one size value is needed.

The imagespec may be a native or AMOS-style filespec, or a DLL library reference, e.g.: images:sunshine.ico, "exit::ashico1", c:\img\new.png. Under ATE, if the image is not found in the specified location or default path, it will also be looked for in the atecache and atepermcache directories.

Submenus

The context menus just described may also contain submenus, i.e. multi-level menus. To define a submenu, set the <cmd> string for the parent item to "[SUB]". Indicate the end of the submenu by defining a dummy item whose <text> is "[ENDSUB]" and whose command is empty. See examples below.

Examples

Standard right-click context menu with two options and a separator between them:

TIP$ = "\Option 1,VK_xF101;-------,;Option 2,VK_xF102;"

Same menu, but with instant display as soon as mouse enters control:

TIP$ = "\@Hover=0\Option 1,VK_xF101;-------,;Option 2,VK_xF102;"

Same menu, appearing after the standard hover time:

TIP$ = "\@Hover\Option 1,VK_xF101;-------,;Option 2,VK_xF102;"

Same menu, appearing after 100 ms, and with an icon (in its default size) from the ashico1 library next to the first option and the separator removed:

TIP$ = "\@Hover=100\|gear::ashico1|Option 1,VK_xF101;Option 2,VK_xF102;"

Same as above, but with a different icon image spec, including an explicit size of 24 pixels:

TIP$ = "\@Hover=100\|gear.ico=24|Option 1,VK_xF101;Option 2,VK_xF102;"

Standard context menu and tooltip together:

TIP$ = ">Right click for options\Option 1,VK_xF101;Option 2,VK_xF102;"

Note that combining a tooltip and a menu only makes sense for the standard right-click menus. Those with the Hover option (that appear automatically) will end up clobbering the tooltip display.

Two-level context menu: The following tooltip string will define a two-level menu with the following structure:

Item 1

Item 2 > Sub-Item 1a

Sub-Item 1b

Item 3

Item 4 > Sub-Item 2a

Sub-Item 2b

 

TIP$ = ">tooltip string\"                                    &

    + "Item 1,VK_xF101;Item 2,[SUB];"                        &

    + "Sub-Item 1a,VK_xF201;Sub-Item 1b,VK_xF202;[ENDSUB],;" &

    + "Item 3,VK_xF103;Item 4,[SUB];"                        &

    + "Sub-Item 2a,VK_xF301;Sub-Item 2b,VK_xF302;[ENDSUB],;"

 

Note that any or all of the above menu items can contain icons, just as in previous examples.

History

2014 March, A-Shell 6.1.1377:  Tooltips will now automatically wrap at 600 pixels, and you now have the option of manually breaking the lines by inserting chr(13) characters. The display time for a tooltip, normally about five seconds, is also now extended by four seconds for every 100 characters past the first 100. You may extend the display time to the maximum value of 32 seconds by inserting a "+" at the start of the tooltip string. Note that the maximum tooltip length remains 400 characters.Added support for submenus within context menus.

2013 October A-Shell 6.1.1363:  Added support for submenus within context menus, and also for adding an accelerator key definition within the tooltip for controls with no ctext. See Accelerator.

2013 February, A-Shell 6.1.1337:  The tooltip/context menu feature supports the ability to create disabled menu items by prefixing the item's definition with "!", e.g.

TIP$ = "!Disabled item,VK_xF101;"

TIP$ += "Enabled item,VK_xF102;"

TIP$ += "!|image.ico|Disabled item with image,VK_xF103;"

 

There is no way to individually enable/disable such menu items without redefining the entire menu, which may call into question, what ois the point—i.e., why not just recreate the menu without the disabled items? A possible rationale would be in order to preserve the layout of the menus so as to make it easier for users to memorize the menu layouts.

 

Created with Help+Manual 9 and styled with Premium Pack Version 5 © by EC Software