Brian Stevens wrote: > Brian Heibert wrote: >> I am using PG to create the menus. > > If not using the PG runtime (and this is what was indicated when you > said Window Clipper was used to translate the PG resource file), PG is > NOT building the menus for you when the program runs. Maybe there is > some confusion here by the loose use of words. > There are three stages for PG: > 1) Build the menus using the Program Generator and save them to the > yourproject.rsrc > 2) If using the PG runtime (which you aren't----see comment above), PG > builds the menus when your program runs. Since your program is not > using the PG runtime, the programmer has to load the menus from > resources, it does not happen automatically. After this step the > program has menus that can be chosen by the user. > 3) The user picks a menu and menu item. Both in PG and non-PG it is > the programmer's responsibility to respond to the menu/menuitem > selection. > > The source code supplied does not do item # 2. There are other things > to do but this is the major piece that is missing. > >> Here's my source code: I haven't heard anyone say "Don't use PG", but my understanding is that PG is somewhere between obsolescent and obsolete. It is surely a suboptimal choice for someone learning FB programming. Better to study some plain FB examples from the CD (ones that work with the Appearance runtime), find one that seems like a good starting point, save it as "MyWonderfulSourceCode", and then modify it. Well, that's what I do... Some list members are struggling to escape from PG; their views would be of interest. The original poster included a routine KillSpinningCursor. This routine has no place in elementary programming. Arguably it has no place at all. The OS X 'spinning pizza of death' cursor (SPOD) is displayed whenever your program has omitted to call HandleEvents for several seconds. The SPOD thus serves to indicate, usefully, that the application is unresponsive to mouse clicks, keystrokes and so on. Unresponsiveness could be a bug or a design flaw in the program. Calling KillSpinningCursor merely suppresses the indication. More defensible solutions would be to make the program responsive, provide a progress indicator, or just accept that the app is out to lunch for a while (perhaps doing a lengthy but finite calculation). Robert P.