To correctly handle checkmarked menu items, from time to time the
application will need to read the checked bit of its checkit menuitems.
It is not adequate to infer which items are checked by tracking what their
state must have become.  There are several reasons for this (although it's
not important to understand the details; just the implication):

  * Using multi-selection of menus, the user can toggle the state of a
    menutoggle item several times, yet the application will receive only
    a single idcmp_menupick event, and that item will only appear once
    one the nextselect chain.

  * When the user selects a mutually exclusive menu item, the
    idcmp_menupick event refers to that item, but intuition doesn't
    notify your application of other items that may have been deselected
    through mutual exclusion.

  * Prior to V36, unusually complex multi-selection operations could
    orphan menu selections.  That is to say, some items that were
    selected may not even appear on the nextselect chain.  if such an
    item had a checkmark, the state of that checkmark could nevertheless
    have changed.

  * For complex multi-selection operations, the nextselect chain will not
    be in select-order (a side-effect of the fact that the same menuitem
    cannot appear twice in the same NextSelect chain combined with the
    fix to the orphaning problems mentioned above).  With certain mutual
    exclusion arrangements, it is impossible to predict the state of the
    checkmarks.

  * If the user begins multi-selection in the menus and hits several
    checkmarked items, but then presses the help key, the application
    will receive an idcmp_menuhelp message.  no idcmp_menupick message
    will have been sent.  Thus, some checkmark changes could have gone
    unnoticed by the application.

It is legal to examine the checked state of a menuitem while that menuitem
is still attached to a window.  It is unnecessary to first call
clearmenustrip().