Farata Systems      

This is what came to my e-mail: “We are researching ways to move from Swing GUI to browser GUI for some networked applications… As you know, the ContextMenu
hideBuiltInItems property doesn’t turn all of the Flash menu items off…The bottom line: if we can’t hide all of the menu items, we can’t use Flex as our solution. This would be a very sad decision, because Flex is an otherwise terrific tool.”

A very typical approach.

First of all, Adobe engineers have elaborated enough on the subject, the latest and very detailed answer being provide by Kevin Hoyt in this link http://weblogs.macromedia.com/khoyt/archives/2007/01/context_menus_r.cfm. Add items, remove items, globally or per object, but you won’t be able to get rid of the two – About and Settings… – in Flash Player Virtual Machine as you won’t be able to get rid of the brakes in your car. Buy it with the brakes or don’t drive until Apollo arrives. Period.

But let’s look at the bigger issue. There is a legacy client/server application that for a _business reasons_ needs to be ported to the net. Having spent almost 6 years in Client/Server to Ajax/J2EE conversion projects, I observed that setting the expectations right is the key here: move from Swing or any C/S to browser GUI – changing a technology platform – results in a redesign and re-architecture. I would certainly pose the following row of question:

During the re-design, which features of the original system, including, but not limited to UI should be retained? Which features should go? Which features should be added?

I am not even relating to the fact that if we were to disable Settings… we could forfeit ability to save application data to the local storage. In the intranet scenario we can, theoretically, assume that Flash Player settings are correct to begin with. It is obvious anyway, that Flex allows much friendlier and less-clicky UI then the one centered around context menus. No need to wait for the user to right-click and _discover_ the choices, we could have proactively display them as soon as the user moves over the object. Besides UI, lots of things change when you move from 2 tiers to 3. You can not map them one to one, so the ContextMenu might be the least of your worries.

Re-training costs? Sure. Not to mention that you’d have to justify the very cost of the port. But if the _business goal_ it to increasing the user base/revenue, you would not have to concentrate on the ContextMenu. Technology is not the problem here, it’s a business issue.

I am not saying that there is no way that  ContextMenu can be possibly hidden and overlapped with your own, especially in the Intranet. My point is that it might not be even worth it.

Victor