Can't modify address record via custom menu item?
 

Am I missing something here? In 4.0 if you add a custom menu item to Address Book (via class ApplicationMenuItem) then when it is invoked, the 'context' argument is not a current copy of the record, if the user has modified it on the screen. Instead, you get the original copy of the record before the user modified it. This makes the custom menu item feature basically useless for interacting with the current record, such as for data validation or automated data entry. Is this correct?

You are correct.

The context of custom menu items when called from an edit screen is *not* what is on screen.

To edit what is on screen, you must manipulate the fields on the screen. Forget the context.

- Forget modifying the address, or anything for that matter, while the editor is running. RIM doesn't think anyone wants to do that. You can trap the message open with a listener and stick stuff in before the editor actually loads, though, if that will do what you want.
- The close listener is well nigh useless. Same with any flavor of listener that might trap a message being sent. I've been hitting these walls for years on a RIM.
- Nice that it's Java. Implementation "could be improved".
- Hope this helps...

Screenscrape it. Im sure you can grab the current fields, and do lots of voodoo magic to do it. You'd have to iterate through the PIMList to see who you're dealing with, but no biggie. You could delete the old entry, and make a new one and repopulate it. Not efficient, but it could work.

Depends on what you're talking about. With an email menu item, you will get the current email message on the screen, if you use 3.8+.

Thanks everybody, for confirming my findings. For now I'll investigate other design ideas (not involving extending the built-in PIM apps in this way) and hopefully won't have to actually resort to the screen-scrape "hack".