Richard,

I don't want to spoil your satisfaction over having "solved" a problem, but I
suspect the problem is more insidious than you might think, since I use the
_checked method of checking items in "the Book"'s Menus without any problems
whatsoever.  Of course, I have a fully implemented Edit Menu, not just the FB
Default Edit Menu - with a few additional items.  I'd like to suggest that you
use a bunch of constants _FileMenu = 1, _EditMenu = 2, _InterestRateMenu = 3,
etc. (if there are more) Also, for the items as well.  This too will make your
code more legible and just may flush out your "real" problem.  Numbers have been
known to be/hide the source of many a mistake, particularly when you make
changes to your menus along the way.  Though it appears to take a little more
time to set up the constants, in the final analysis it is well worth it - even
on a very simple project.

Hope this helps someone,

Joe Wilkins

Richard Goodman wrote:

> Some time ago, I posted the following:
>
> For some reason I encounter bugs that seem to have no rational explanation.
> This one is a lulu.  I am working on a rather elementary program for
> calculating compound interest. It contains the following function to create
> a menu from which the user can select an interest rate:
>
> LOCAL FN buildmenus
> MENU 1,0,_enable ,"File"
> MENU 1,1,_enable,"Quit/Q"
> MENU 2,0,1, "Interest Rate"
> MENU 2,1,1, "2%"
> MENU 2,2,1, "2.5%"
> MENU 2,3,1, "3%"
> MENU 2,4,1, "3.5%"
> MENU 2,5,_checked, "4%"
> MENU 2,6,1, "4.5%"
> MENU 2,7,1, "5%"
> MENU 2,8,1, "5.5%"
> MENU 2,9,1, "6%"
> itemchecked = 5
> rate = .04
> end fn
>
> The function that processes a menu click looks like this:
>
> LOCAL
> DIM menuID
> DIM itemID
> DIM thisitem
> LOCAL FN menuprocess
>   menuID = MENU(_menuID)
>   itemID = MENU(_itemID)
> SELECT menuID
>    CASE 1                         'quit
>           FN Quit
>    CASE 2                         'interest rate
>      FOR thisitem = 1 to 9
>      if thisitem = itemchecked then menu 2,thisitem,1    'uncheck the
> previously checked item
>      NEXT
>
>      SELECT itemID
>      CASE 1
>      rate! = .02
>      MENU 2,1,_checked
>      CASE 2
>      rate! = .025
>      MENU 2,2,_checked
>      CASE 3
>      rate! = .03
>      MENU 2,3,_checked
>      CASE 4
>      rate! = .035
>      MENU 2,4,_checked
>      CASE 5
>      rate! = .04
>      MENU 2,5,_checked
>      CASE 6
>      BEEP
>      rate! = .045
>      MENU 2,6,_checked
>      CASE 7
>      rate! = .05
>      MENU 2,7,_checked
>      CASE 8
>      rate! = .055
>      MENU 2,8,_checked
>      case 9
>      rate! = .06
>      MENU 2,9,_checked
> END SELECT
> END SELECT
> itemchecked = itemID
>   MENU
> end fn
>
> Pretty straightforward stuff, right?
>
> However, I've found that when the user chooses any of the interest rates
> 3%, 3.5%, 4%, or 4.5%, the menu does not respond. In fact, using a BEEP, I
> find that the CASE for the given rate is not recognized at all. The other
> rates are recognized OK. By a lengthy process of trial and error, I've
> narrowed down the conflict to the following two statements (from a function
> that builds the single window in the program):
>
> EDIT FIELD #6,"1", (440, 310)-(500, 330),_FramedNoCR  ' for user to enter
> duration of investment
> EDIT FIELD #4,"100", (440, 230)-(500, 245), _FramedNoCR' for user to enter
> starting principal
>
> If I change the two edit fields to _Statnoframed, the problem disappears.
> But I want the edit fields "editable!"
>
> I haven't a clue as to what's going on here. Why would the nature of an
> edit field interfere with the ability to choose some menu items. Can anyone
> help me here?
>
> ==================================================================
>  Joe Lewis Wilkins  and "Michael" responded that they thought the problem
> might have to do with my using the percent sign in the menu. However, As
> Stu Cram replied, this was not the cause of the problem. One can use a
> percent sign or any other meta character in a menu name as long as the
> symbol is in the quotation marks.
>
> Stu Cram then said that he thought the problem was that I needed an Edit
> Menu because I was using edit fields. This sounded reasonable, so I added
> the statement:
>
> EDIT MENU 2
>
> to my menu building routine.  This did not make the problem go away, however.
>
> Finally, Stu Cram suggested that I streamline the code by using the statement
>
> DEF CheckOneItem(3, itemID)
>
> to check a user-chosen menu item and uncheck all the rest. He did not
> suggest this as a solution to my problem just a way to make the code more
> elegant. I followed his advice and, whaddayaknow, the problem of the user
> being unable to choose some of the menu items disappeared. In other words,
> DEF CheckOneItem is probably the _only_ way to process checking and
> unchecking menu items in response to user action.
>
> Thanks to the three of you who helped me get at the root of the problem.
>
> Richard
>
> --
> To unsubscribe, send ANY message to <futurebasic-unsubscribe@...>