Please enable JavaScript to view this site.

A-Shell Development History

921.0.1

(Windows/ATE) XTREE now supports a primitive ability to edit cells. The concept is similar to the editable checkboxes, subject to the following notes and qualifications:

The column format code for an editable text cell is "E"
The source for the editable text cells comes from the source array, just like for regular text cells, and unlike editable checkboxes.
The editable column is output to the ARRAY parameter, which must be formatted accordingly. For example, if there are 3 editable checkboxes, plus two editable text columns, one 12 characters wide and one 18 characters wide, the mapping of ANSWER should be:

MAP2 ANSARY(1000)       ! up to 1000 rows

   MAP3 ANSCB1,S,1     ! First checkbox column

   MAP3 ANSCB2,S,1     ! Second checkbox column

   MAP3 ANSCB3,S,1     ! Third checkbox column

   MAP3 ANSTEXT1,S,12  ! First editable text column

   MAP3 ANSTEXT2,S,18  ! Second editable text column

 

Note that the editable text columns must follow and editable checkbox columns in ANSWER, regardless of their physical arrangement in the the source array.

For ATE, there can be no embedded nulls in any of the fields of the ANSWER array. This is mainly a consideration for the first call to XTREE in a program, since after that, the output will fill the arrays as needed with spaces. So at the start of a program, you should space-fill the entire ARRAY area.
Since the input for the editable text is separate from the output, you can compare the two to determine which have changed. (This is currently your only opportunity for validation logic.) If you plan to allow the tree control to be re-entered by the user, you must transfer the updated text data from the ANSWER array back to the source array.
You must set the flag XTF'EDITABLE whenever using either editable checkboxes or editable text. (This flag was previously known as XTF'CHKBOX, i.e. 33554432, but has been renamed to make it more clear.)
As with editable checkboxes, editable text is only supported in array mode.
While editing a cell, the navigation keys (TAB, Shift-TAB, arrows, HOME, END, etc.) are intercepted and applied towards moving to the next editable cell. In order to use any of these keys to trigger an exitcode, you must use the cursor to move to a non-editable cell.

The XTRA5 sample program has been updated to allow the description column to be edited. Don't forget to get the updated XTREE.MAP also.

WARNING: In its current state, the editing feature is rather limited and should probably be considered experimental (i.e. not suitable for integration into a production environment).

921.0.2

(Windows/ATE) XTREE now supports customizable context menus (i.e. right-click popup menus). Clicking on one of the choices of the popup menu is equivalent to clicking on a button that sends a command code. So as a practical matter, this just provides a way to define additional buttons (and corresponding exitcodes) that only appear when the control is right-clicked.

Only one popup menu can be defined for an instance of the control, and it applies to all parts of the control (i.e. all rows and columns.) To define the popup menu, create a dummy column using the advanced COLDEF syntax, as follows:

COLDEF = "0~0~X~S~PopupMenu=<text>,<cmd>;<text>,<cmd>;...<text><cmd>~~

Note that a column whose width is zero does not really define a column; it is just a way to use the flexible "advanced column definition" syntax to define parameters relating to the control as a whole. The title and type fields (X and S respectively in the example above) are ignored, but should not be null since ~~ should mark the end of the column definition.

The <text> fields are arbitrary strings to display for the choices in the popup menu (may contain any character except a comma). The <cmd> fields should be coded the same as for the cmd string on a button which has the MBF'KBD type, i.e. literal keyboard characters, or more likely, "virtual key commands", such as "%VK_xF501%" or "%VK_ESC%" or "%VK_F1%".

For example, in a list of transactions, you might define a popup menu like this:

COLDEF="0~0~x~S~PopupMenu=" &

+ "Delete,%VK_xF501%;"  &

+ "Open,%VK_xF502%;"    &

+ "Close,%VK_xF503%;"   &

+ "Refile,%VK_xF504%;"  &

+ "Edit,%VK_xF505%~~"

 

COLDEF=COLDEF+<additional real column definitions>

 

When the user right clicks on an item, the popup menu will appear with the Delete/Open/Close/Refile/Edit choices, and if the user clicks on one of them, the corresponding virtual key sequence will be triggered, resulting in an exitcode from -501 to -505. The selection information will also be returned, as if this item had been selected in the 'normal' way, and the XTR'COLUMNACTIVE field will also be set to indicate which column the user right-clicked on. The application can take this information and do whatever it wants with it, presumably popping up another dialog to perform the requested action, followed by a return to the XTREE control to allow for another item to be selected. (This will probably look best if the XTF'MODELESS option is used.)

The XTRA2 sample program has been updated to demonstrate the use of a context menu (although it just displays the exitcode and doesn't perform any other action with the information resulting from the popup menu choice).