NSResponder actions (MenuItems)

MacOSX predefines, and so does Xojo, EditMenuItems. The plugin enables/disables these menuItems, Undo, Cut, Copy, Paste (and even Redo when added to the EditMenu items) at the Cocoa level, but when it comes to Delete it is not responsive to getting it enabled. Even forcefully returning YES does not enable “Delete”. The code is

- (BOOL) validateUserInterfaceItem: (id <NSValidatedUserInterfaceItem>) anItem
{
  // return YES;
  SEL action = [anItem action];
  if (action==@selector(undo:)) {
    return [self canUndo];
  }
  else if (action==@selector(redo:)) {
    return [self canRedo];
  }
  else if (action==@selector(cut:) || action==@selector(copy:) || action==@selector(clear:)) {
    return mOwner.backend->HasSelection();
  }
  else if (action==@selector(paste:)) {
    return mOwner.backend->CanPaste();
  }
  return YES;
}

Seems like the Delete item is very special and the question is:
is there anything that can be done at this level, other than resorting to the EnableMenuItems callback of the REALcontrol, and accessing this MenuItem through dynamic access?

Alfred,

people told me on this forum that the OS X Delete key (value) is in fact the Back Delete Key (value).

This may be the reason you have troubles with it ?

Emile,

Yes, this menuItem is associated with DeleteBackward, and the plugin will perform this action if the menuItem is enabled. It appears that the Delete menuItem is not recognized by the OS and thus, it cannot enable/disable it, like how it handles the other editMenu items. The Delete menuItem appears to be private to the Xojo framework and therefore one can only manipulate it in EnableMenuItems callback and handling it in the MenuItem action callback of the control. It is how it is. I was hoping it could be done by the OS, thereby simplifying the plugin.