While converting an old carbon app to cocoa I noticed that there is no index parameter form the menu handler a menu item that was created as a control set, that is multiple menuitems contains the same name. The odd thing is, that even though there was no index parameter shown the I could use index in the menu handler. It appears when you type ind and press tab key to complete it. I dumped the project as an XML file and sure enough there is an index property for the menuitems and it had the proper values. I just can see it anywhere like you can for other control sets. I did some searching here in the forums and couldn’t find anything that covered that fact so I went to Feedback and did find 10565 and from it, it sounds like menuitem control sets are not meant to be usable in Cocoa.
Just want to verify that this is true. As some of the folks brought up in that feedback, 10565, having that feature is might nice and since it seems to work fine in a Cocoa app currently, although a little tricky to get going, I just want some verification since that feedback item was created in December of 2009. For my case I have two menus where the submenus index value is exactly what is needed within the program. Sure, I can go other routes but this was so darn straight forward, choose an item from a menu and in the menu handler assign the index to the appropriate property and you are done. For a guy who one wades around a little in all that OOPs stuff, this is so easy.
So, should I ditch the menuitem control sets in Cocoa? Even when index is actually there, just not visibly shown.
No, from my experience you can safely use the index parameter of the menu handler. In my apps I use a MenuItem ControlSet and the menu handler for it looks like that:
Function ArrayOfWindowMenuItems() As Boolean // the menu handler shown in the IDE, which is wrong, because ...
// Function ArrayOfWindowMenuItems(index As Integer) As Boolean // this should be shown by the IDE
Dim selectedMenuItem As MenuItem = ArrayOfWindowMenuItems(index)
Dim window As Window = selectedMenuItem.Tag
window.Show()
Return True
End Function
Thanks Eli. I guess, since it appears I am not the only one going this route, I will leave it as is for now as it just plain works so nice in this particular case. Unless, of course, someone from Xojo tells me not to.
You can
I’d not use them and would do “something else” but its not required
For instance our “recent items” in the IDE could be done using a menu item array
But its not
Its a menu item subclass that we create, stuff the folder item ref into and implement the action event in that subclass
Nicely self contained - and for that use case a menu item array is no better (I’d say it’s more work)
If I had anywhere near the grasp of OOPs that you do Norman I probably would have happily done something else because I would have know what I was doing. Just a few days ago I was converting another program of mine to Cocoa. The carbon version had used the SmoothResize feature to allow for expanding and collapsing the height of a window. I found a SmoothResize in MacOSLib and figured its so small I can just grab that little piece on put it in my project. Dang, it depended on something else. Found that something else and brought it over. Dang the second time, it depended on something else. After a couple more dang it depends on something else I thought, okay, throw those out and bring in the whole MacOSlib. Still couldn’t get the thing to work. Having the MBS plugins I checked and sure enough there was a SmoothResizeMBS. Threw out MacOSLib and put in no time had the SmoothResizeMBS working.
I have to laugh some times, or is it cry, when I look at the code that you experts write. To me, a lot of what I look at looks like it does absolutely nothing. It seems to be something that you forgot to delete. However, take that piece out and the rest comes tumbling down. On the other hand, if you guys were to look at my code you would probably gasp and have a hard time understanding it because it doesn’t have all of those goodies that you use.
I truly envy you guys that live and sleep OOPs. I don’t doubt that some of you even dream in OOPs. Sure wish it had existed when I started my programming career. Maybe by now IBM has added OOPs to PL/I but it wasn’t there when I retired back in 2001. For now I will stick with what I have. Once I have all my projects working in Cocoa I will go back and try doing what you suggest. For now I need to get them all working so I am not left hanging when Carbon support goes out the door. Fortunately Cocoa has caused me very little grief thus far.
