oster@dewey.soe.berkeley.edu (David Phillip Oster) (08/23/89)
So, you are proud of your new Windows menu. Try working with a few
documents named with leading hyphens: "-Try this" for example. Lightspeed
C gets it right, even handling volumes named "-" correctly. Microsoft Word
botches it. Such files turn into illegible gray lines in the menu bar.
What happens if you have multiple files open, all with the same name?
My Windows1.1 desk accessory handles both of these gotchas.
--- David Phillip Oster --"Unix Version 7 was an improvement not
Arpa: oster@dewey.soe.berkeley.edu --only over its predeccessors, but also its
Uucp: {uwvax,decvax}!ucbvax!oster%dewey.soe.berkeley.edu --successors."earleh@eleazar.dartmouth.edu (Earle R. Horton) (08/24/89)
In article <30839@ucbvax.BERKELEY.EDU> oster@dewey.soe.berkeley.edu.UUCP (David Phillip Oster) writes: >So, you are proud of your new Windows menu. Try working with a few >documents named with leading hyphens: "-Try this" for example. Lightspeed >C gets it right, even handling volumes named "-" correctly. Microsoft Word >botches it. Such files turn into illegible gray lines in the menu bar. I think we had this discussion last year. For those of us who were not tuned in, one possible solution is to put such strings into menu items in the following fashion. Never use AppendMenu() to add an item directly when building a menu. First, append a dummy item using an innocuous string consisting of a single space or something of the like. Then, use SetItem() to set the text of the new item to the desired string. This prevents menu meta-characters from messing up your menu if the file name is something like "(-" for instance. Second, a leading minus (hyphen) will show up as a gray line, so one possible solution is to store the new item in a string consisting of the concatenation of two strings. The first substring contains an ASCII NUL (zero-valued character) and the second substring contains the actual string you want to appear in the menu, e.g. a file or path name. The appearance of the resulting menu item is the same as if the desired string only were used, except that strings with a leading "-" appear correctly. If you need to extract the string from the menu item and use it, remember that it will contain a leading NUL when you extract it with GetItem(). Add MPW Shell to the list of applications which botch this up, and the people who wrote it should know better. >What happens if you have multiple files open, all with the same name? This is a matter of taste, I think. One solution is to use pathnames, but a perverse or inept user can have identically-named volumes online, with the possibility of identical pathnames. (This is one of the main reasons not to use pathnames to access Macintosh files.) Another solution is to number those items in the windows menu whose titles are not unique. Perhaps the simplest solution is to just use the item position in the windows menu, rather than the title, to determine which window the user wishes to select. A problem with this is that you can get identical menu items, but at least the program can distinguish among them, if not the user. >My Windows1.1 desk accessory handles both of these gotchas. And what methods do you use? Earle R. Horton /* It's lean, it's mean, it's my .signature! */