Updated April 2011

CTLOP_DEL (opcode 3) is used to delete a control, either by its ctlid or by its location. Using the example above, we could delete the “Delete” button (instead of disabling, or even hiding it) as follows:

xcall AUI, AUI_CONTROL, CTLOP_DEL, BTNID(2)

Note that unless you want to check the returned cstatus to confirm that there was not an error, you only need the above parameters.

As a special convenience, you can delete the current dialog (and everything in it), without knowing its ID, by setting ctlid = 0 and specifying MBF_DIALOG in the ctype field:

xcall AUI, AUI_CONTROL, CTLOP_DEL, 0, "", 0, MBF_DIALOG

Deleting a control will automatically delete any child controls of that control. If you want to delete just the children but leave the target control along, see opcode 4.

The other way to delete controls is by setting ctext to “*” and using the srow, scol, erow, and ecol parameters to specify a region. We can use this technique, for example, to delete the four controls in the middle of our sample dialog (Product ID, Description, and the two data fields). However, in this case, we would also have to specify the control ID of the dialog (in the parentid parameter), which we will assume was stored in DLGID. (Without this, the delete operation would only look at controls that were placed directly on the main window.)

srow = 3 : scol = 1 : erow = 4 : ecol = 40  ! coordinates of area to delete

xcall AUI, AUI_CONTROL, CTLOP_DEL, 0, "*", cstate, ctype, cmd, func, cstatus, srow, scol, erow, ecol, fgc, bgc, fontattr, fontscale, fontface, tooltip, DLGID

(The parameters shown above in lower case are ignored for this call; we only specified them because we need to have valid placeholders for the parameters up to the parentid parameter (specified as DLGID above). We could have used zeroes and “”, but this makes it more clear.) The result is:

Note that when deleting controls by their coordinates, if the controls are part of a dialog or other group, then you need to specify the parent control ID in the parentid parameter, and use coordinates relative to the parent control. In the example above, we used coordinates relative to the dialog, which was the parent of the controls we wanted to delete. If, for example, we wanted to delete the buttons from the dialog, we would need to know whether they were part of a group. Often, buttons arranged as shown above are part of a group that may no be obvious visually, but can be determined by looking at the code or by dumping the controls by using Ctrl+Shift+Double-Right-Click somewhere on the dialog or main window. For the example above, the resulting spreadsheet looks like this:

The first column lists the control IDs, and the second column indicates the parent of the control. In this case, all the controls except the dialog itself have a parent. But the buttons are actually children of control #8, which shows as “BUTTON” in the spreadsheet but is actually an invisible MBF_GROUPBOX. (For reasons only known to Microsoft, group boxes share the BUTTON class with more traditional buttons and check boxes.) So if we had wanted to delete the buttons using their coordinates, we would have need to specify the correct parentid (8) and the correct coordinates relative to the parent (i.e. they are all on row 2).

An easy way to delete all controls is by clearing the screen with Tab(-1,0). This is equivalent to specifying opcode 3 with ctext = “*” and the coordinates set to the entire screen.

Also note that the coordinates do not have to be precise; they just have to specify an area that includes the controls to be deleted. You can set the erow and ecol parameters to 999,999 if you want to clear to the end of the screen or dialog without know its size.

A-Shell 5.1.1210 of April 2011

When CTLOP_DEL is used to delete controls within a specified area (rather than to delete a single control by its ID), it is now more selective about identifying GROUPBOX and FRAME controls that should be deleted. Previously, as long as underlying GROUPBOX or FRAME intersected one of the boundaries of the specified area, it would be deleted. Now, it must be entirely within the specified area in order to deleted. This fixes a problem with overlappying popup frames (such as those created by MSBOXX with the BOX_WIN flag) whereby removing the top frame would delete an overlapping/underlying frame but not all of the controls within it. When the the frame was then restored, the Z order was upside down, so that the frame was obscuring the controls supposed to appear on top of it.