icm@eleazar.Dartmouth.EDU (Ioannis C. Mangos) (02/22/88)
Followup-To: I am writting a small application for the Mac with some friends of mine and we want to have a menu called "Windows" that will display all the windows that there are currently on the screen. One problem I have is that there does not seem to be a command "DeleteMItem" whereas there is one called "AppendMItem" The way I was thinking to do that was to have a linked list of all the window titles and append them. But in order to do that I have to delete first all the existing titles n that menu. Does anyone has an alternative on that that is willing to share with me? Thank you for your help in advance.
atchison@hpindda.HP.COM (Lee Atchison) (02/24/88)
If you want to get fancy, you can do the following optimization to the "delete all menu items, then add them back in" scenerio: If the number of new windows is equal to the number of old windows to be placed in the menu, then just use SetIText (I think this is the call, if you want more info, send me mail) to change the name of the text in the menu items. If the number of new windows is greater than the number of old windows, then simply "add" the necessary number of menu items, then use SetIText. If the number of new windows is less than the number of old windows, then you are out of luck and you have to do the "delete, then add them all back in" method. I recently faced the same problem, and decided it wasn't worth the effort, so I did the "delete/add them in" for all cases, the code isn't all that bad, and I don't think it is all that inefficient (if I'm wrong, please let me know). -lee ---- Lee Atchison Hewlett Packard, Information Networks Division atchison%hpindda@hplabs.hp.com
deragon@acf8.UUCP (John Paul Deragon) (02/24/88)
/* acf8:comp.sys.mac.programmer / icm@eleazar.Dartmouth.EDU (Ioannis C. Mangos) / 9:28 pm Feb 21, 1988 */ I am writting a small application for the Mac with some friends of mine and we want to have a menu called "Windows" that will display all the windows that there are currently on the screen. One problem I have is that there does not seem to be a command "DeleteMItem" whereas there is one called "AppendMItem" The way I was thinking to do that was to have a linked list of all the window titles and append them. But in order to do that I have to delete first all the existing titles n that menu. Does anyone has an alternative on that that is willing to share with me? Thank you for your help in advance. /* ---------- */ Excuse me if there is one before this that got thru, my editor choked.. Anyway according to my inside mac DA there is a specific function for exactly what you need. PROCEDURE DelMenuItem (theMenu: MenuHandle; item: INTEGER); DelMenuItem deletes the specified item from the given menu. Note: DelMenuItem is intended for maintaining dynamic menus (such as a list of open windows). It should not be used for disabling items; you should use DisableItem instead. Interface: Menu Manager Definitions. CONST noMark = 0; { mark symbol for MarkItem } TextMenuProc = 0; { menu defProc messages } mDrawMsg = 0; mChooseMsg = 1; mSizeMsg = 2; TYPE MenuPtr = ^MenuInfo; MenuHandle = ^MenuPtr; MenuInfo = RECORD menuId: INTEGER; menuWidth: INTEGER; menuHeight: INTEGER; menuProc: Handle; enableFlags: LongInt; menuData: STR255; END;
hpoppe@scdpyr.UUCP (Herb Poppe) (02/25/88)
In article <22780002@acf8.UUCP>, deragon@acf8.UUCP (John Paul Deragon) writes:
<< /* acf8:comp.sys.mac.programmer / icm@eleazar.Dartmouth.EDU (Ioannis C. Mangos) / 9:28 pm Feb 21, 1988 */
<<
<< I am writting a small application for the Mac with some friends of mine
<< and we want to have a menu called "Windows" that will display all the windows
<< that there are currently on the screen. One problem I have is that there does
<< not seem to be a command "DeleteMItem" whereas there is one called "AppendMItem"
<< ...
<Anyway according to my inside mac DA there is a specific function for
<exactly what you need.
<
<PROCEDURE DelMenuItem (theMenu: MenuHandle; item: INTEGER);
<...
Note that DelMenuItem is described in InsideMac Vol. 4.
--
Herb Poppe NCAR INTERNET: hpoppe@scdpyr.UCAR.EDU
(303) 497-1296 P.O. Box 3000 CSNET: hpoppe@ncar.CSNET
Boulder, CO 80307 UUCP: hpoppe@scdpyr.UUCP
rs4u+@andrew.cmu.edu (Richard Siegel) (02/25/88)
It's "SetItem" you're thinking of; "SetIText" is for setting dialog items. A further suggestion: there's no way to simply add space for another menu item, and then set the items to something arbitrary. What you can do, however, is an AppendMenu call, which adds the string specified to the menu. I need to write a Windows menu... The question is, when to maintain it? Every activate/deactivate event? That seems the best question; you can waste a LOT of time doing it every time through the main event loop. Anyway, the window list only changes on activate/deactivate events anyway.... --Rich =================================================================== Richard Siegel Confused Undergrad, Carnegie-Mellon University The opinions stated here do not represent the policies of Carnegie-Mellon University. Arpa: rs4u@andrew.cmu.edu UUCP: {decvax,ucbvax,sun}!andrew.cmu.edu!rs4u ==================================================================
gs1g+@andrew.cmu.edu (Gregory Jacob Stein) (02/25/88)
> not seem to be a command "DeleteMItem" whereas there is one called
"AppendMItem"
If I remember right, IM IV lists the routine called DeleteMItem, which does
what you want. I know that I've written a similar routine. When I get back
to my books, I'll check to make sure and repost if I messed this up :-)
Greg
atchison@hpindda.HP.COM (Lee Atchison) (02/26/88)
/ hpindda:comp.sys.mac.programmer / rs4u+@andrew.cmu.edu (Richard Siegel) / 9:45 am Feb 24, 1988 / > >It's "SetItem" you're thinking of; "SetIText" is for setting dialog items. Thanks for correcting me. My copy of IM is at home. >I need to write a Windows menu... > >The question is, when to maintain it? Every activate/deactivate event? That >seems the best question; you can waste a LOT of time doing it every time >through the main event loop. Anyway, the window list only changes on >activate/deactivate events anyway.... First, I'm assuming that you are only concerned about inserting windows that you use into your menu (ie. you don't care about DA windows, etc.). Now, the only time you need to update the window list is when you create and destroy a window. You don't have to update it everytime there is an activate/deactivate event. I have an application that I have a window list. I recreate the window list everytime I create/destroy a window. I also go one step further, however. I put a check mark by the active window. So, I use two routines, one which recreates the window menu list (which I call after window creation and destruction) and one which checks/unchecks the active window which is call during the activate/deactivate event. Actually, the code to maintain the window list is quite easy. If you, or anyone else, is interested in some source code segments, I'd be glad to send them.... > > --Rich > >=================================================================== >Richard Siegel >Confused Undergrad, Carnegie-Mellon University > >The opinions stated here do not represent the policies >of Carnegie-Mellon University. > >Arpa: rs4u@andrew.cmu.edu >UUCP: {decvax,ucbvax,sun}!andrew.cmu.edu!rs4u >================================================================== >---------- -lee ---- Lee Atchison Hewlett Packard, Information Networks Division atchison%hpindda@hplabs.hp.com
matthews@eleazar.Dartmouth.EDU (Jim Matthews) (02/26/88)
In article <gW8kyky00XoEEFs0jj@andrew.cmu.edu> rs4u+@andrew.cmu.edu (Richard Siegel) writes: > >I need to write a Windows menu... > >The question is, when to maintain it? Every activate/deactivate event? That >seems the best question; you can waste a LOT of time doing it every time >through the main event loop. Anyway, the window list only changes on >activate/deactivate events anyway.... > > --Rich Another approach, used in a program developed here and (I believe) MacApp, is to rebuild the windows menu whenever the user clicks on the menu bar. Since there are no cmd-key equivalents that's the only time it needs to be right, and it doesn't take enough time to slow the menu response significantly. Jim Matthews Jim.Matthews@dartmouth.edu
drc@dbase.UUCP (Dennis Cohen) (03/01/88)
You should be aware that any calls to DelMenuItem and InsMenuItem presuppose the presence of 128K ROMs or later. These traps from Volume IV were NOT back- patched into the System for support on older hardware. Dennis Cohen Ashton-Tate Macintosh Division dBASE Mac Development Team
lsr@Apple.COM (Larry Rosenstein) (03/02/88)
In article <8266@eleazar.Dartmouth.EDU> matthews@eleazar.Dartmouth.EDU (Jim Matthews) writes: > >Another approach, used in a program developed here and (I believe) MacApp, >is to rebuild the windows menu whenever the user clicks on the menu bar. >Since there are no cmd-key equivalents that's the only time it needs >to be right, and it doesn't take enough time to slow the menu response >significantly. Just to elaborate. In MacApp we wanted to centralize all the menu setup in one methods (which might be implemented in several objects). It is certainly more efficient to change the menu state at the pooint in the program where you notice the change. In the case of a Windows menu, you add a new item when you create a window, check the appropriate item when you activate, etc. In MacApp, all menu setup is put into a method called DoSetupMenus. Various objects in the system implement this method, and each of those objects get a chance to setup the items it cares about. As was mentioned above, you setup the menus when the user clicks in the menu bar. In order to handle command keys properly, you have to do this when the user types a command key as well. The other case you have to handle is disabling a menu title. It would not be reasonable for the user to click on a menu title and then have it become gray. If you need to support this in an application, then you have to setup the menus after each event. In MacApp we remember if the menus are already setup so that excess work is not done. For example, if the menus were setup because the application is idle, then they don't need to be setup when the user clicks in the menu bar. Also, the programmer can define menus that are not managed by MacApp, and these can be setup in any way s/he chooses. Another approach is one mentioned in Scott Knaster's first book. You define an application event that means "menu update". Then when a window is created/destroyed or an activate/deactivate event is seen, you post a menu update event. In your main event loop, you can update all the menus when this event is seen. (You will have to be careful about posting more than 1 menu update or clearing out other pending menu updates after the first.) -- Larry Rosenstein, Object Specialist Apple Computer, Inc. 20525 Mariani Ave, MS 32E Cupertino, CA 95014 AppleLink:Rosenstein1 domain:lsr@Apple.COM UUCP:{sun,voder,nsc,decwrl}!apple!lsr