Thursday, March 24, 2011

Attack of the Clones

For a long time now (perhaps since the very beginning) the Realbasic framework has allowed you to have a menu item appear in multiple locations. For example, you might have a menu that appears in your menubar but also appears in a contextual menu somewhere else in your project. In order for the Realbasic framework to allow this, the entire menubar is rebuilt every time you open it or type a keyboard shortcut.

This has led to problems in the past. For example, plug-ins cannot modify menus nor can declares. These limitations have been around for quite some time and we have all grown accustomed to them, even if we prefer they didn't exist. It also has a considerable runtime cost to continually rebuild the menubar during typing. In our transition to Cocoa we would like to take the opportunity to move to a system where the menubar is stable and does not have to be dynamically updated.

While the end result is much nicer, there is a downside: backwards compatibility. If you are using a menu item object in multiple locations once we make this change your code will break. Specifically, it will raise a MenuHasParentException.

Fortunately, updating your code will be pretty straightforward. Rather than having the menu item be in two or more places at once, you will instead clone the menu item using the newly added Clone() method.

To make this transition less painful, this behavior will be required only for the Cocoa framework starting with Real Studio 2011 R2. All desktop frameworks (Mac OS X Carbon, Windows and Linux) will support it but the others will initially continue to support the old behavior as well. Beginning with Real Studio 2011 R4 it will be required for all desktop frameworks so that there is a single, standard technique (cloning) for dealing with menu items that appears in multiple

We don't make changes that will break code without a lot of thought. But a little bit of pain now will save a lot of it down the road. It's really better that we allow the OS to handle as much as possible so that when OS changes occur, they have minimal impact on your projects. And in this case, you will even gain some functionality because plugins and declares will be able to modify menus.

If you are not using menu items in multiple locations, this will have no impact on you. If you are, I think you can see that the gain will be well worth the effort.


Beatrix Willius said...

You can break my code as often as you like if this speeds up Cocoa.

Thomas Tempelmann said...

Sounds good to me!

Eduo said...

Darn it! And just yesterday I implemented a ".clone" method to allow me to clone classes (used for sets of data) to avoid having multiple pointers to the same object instead of different objects.

24 hours the name of my function lasted. 24!


Unknown said...

I agree with Beatrix. Break what you need to get cocoa up and running

TJ said...

@Eduo - I don't think this is what they are changing here. I believe (from what I've seen so far) that this clone method only applies to the Menu items.