1 Correct answer
Thank you all so much for your replies, and thank you Harbs for making it finally work!
Just to make sure this can serve as a resource for others in the future, below is a final (working) menu based on Harb's code. I also added 2 submenu items just to be complete.
Thanks again everyone. I'm so glad you could help get this working!
Dan
...#targetengine "HarbsTestMenu"
menuInstaller();
function menuInstaller() {
// SET THE FILES THAT ARE TRIGGERED BY MENU ITEMS
menuItem1Handler = function( /*onInvo
54
Replies
Dan Rodney wrote:
Marc. Is it possible to insert menu dividers in your example? And if so, how?
You mean menuSeparators, right?
I slightly expanded the code to support the following syntax:
FEATURES = [
{ caption: "My Menu Item 1", fileName: 'File-One.jsx', subName: "" },
{ separator: true, subName: "" },
{ caption: "My Menu Item 2", fileName: 'File-Two.jsx', subName: "My Sub Menu" },
{ separator: true, subName: "My Sub Menu" },
{ caption: "My Menu Item 3", fileName: 'File-Three.jsx', subName: "My Sub Menu" }
]
Also, I removed the #targetengine stuf and the HOST argument. As John said, this is uselessly complicated for such a project. Note that this startup script does not need to run in a persistent engine.
Here is a possible implementation:
// MenuLoader
// (#targetengine is not required)
(function()
// -------------------------------------
// Install and/or update the menu/submenu and connect
// the corresponding menu actions if script files are available
{
// Settings and constants
// ---
var MENU_NAME = "My Test Menu",
FEATURES = [
{ caption: "My Menu Item 1", fileName: "File-One.jsx", subName: "" },
{ separator: true, subName: "" },
{ caption: "My Menu Item 2", fileName: "File-Two.jsx", subName: "My Sub Menu" },
{ separator: true, subName: "My Sub Menu" },
{ caption: "My Menu Item 3", fileName: "File-Three.jsx", subName: "My Sub Menu" }
],
LO_END = LocationOptions.atEnd,
INDESIGN_ROOT_MENU = app.menus.item( '$ID/Main' ),
FEATURE_LOCATION_PATH = (function()
{
var f;
try{ f=app.activeScript; }
catch(_){ f=File(_.fileName); }
return f.parent.parent + '/';
})();
// (Re)set the actions
// Note: checks also whether script files are available
// ---
var t, f,
i = FEATURES.length;
while( i-- )
{
t = FEATURES;
if( t.separator ) continue;
if( (f=File(FEATURE_LOCATION_PATH + t.fileName)).exists )
{
// The script file exists => create the corresponding action
// and directly attach the event listener to the file
// (no need to use app.doScript(...) here)
// ---
(t.action = app.scriptMenuActions.add( t.caption )).
addEventListener('onInvoke', f);
}
else
{
// The script file does not exist => remove that feature
// ---
FEATURES.splice(i,1);
}
}
// ---
// Create/reset the custom menu container *if necessary*
// Note: menus/submenus are application-persistent
// ---
var mnu = INDESIGN_ROOT_MENU.submenus.itemByName( MENU_NAME );
if( !mnu.isValid )
{
// Our custom menu hasn't been created yet
// ---
if( !FEATURES.length ) return;
mnu = INDESIGN_ROOT_MENU.submenus.add(
MENU_NAME,
LocationOptions.after,
INDESIGN_ROOT_MENU.submenus.item( '$ID/&Window' )
);
}
else
{
// Our custom menu already exists, but we must clear
// any sub element in order to rebuild a fresh structure
// ---
mnu.menuElements.everyItem().remove();
// If FEATURES is empty, remove the menu itself
// ---
if( !FEATURES.length ){ mnu.remove(); return; }
}
// ---
// Now, let's fill mnu with respect to FEATURES' order
// (Possible submenus are specified in .subName and created on the fly)
// ---
var s,
n = FEATURES.length,
subs = {},
sub = null;
for( i=0 ; i < n ; ++i )
{
t = FEATURES;
// Target the desired submenu
// ---
sub = (s=t.subName) ?
( subs
|| (subs=mnu.submenus.add( s, LO_END )) ) :mnu;
// Connect the related action OR create a separator
// ---
if( t.separator )
sub.menuSeparators.add( LO_END);
else
sub.menuItems.add( t.action, LO_END );
}
})();
@+
Marc
John, as for the ==null tests, they work in CS3 and later. If I switch to isValid that only works in CS5 (from what I understand). What cross-version compatible code do you think is better?
Oh, I wasn't referring to .isValid! I didn't mean that at all. I meant what I said in post #1, after I mentioned it. Replace if (var==null) with if (!var). === is almost always better than ==, because truthiness of == causes confusion and problems. But in ifs, you might as well use the implicit truthiness and not test explicitly, and write for clarity. (Someone is going to say this argument is defective 
).
By the way, there's some sample Adobe script that creates menus. Maybe it's hidden in the Bridge SDK or something. I can't remember, something to do with some font. I haven't looked at the code though, so who knows. I suspect it is rather different than any of the examples so far...
Marc's absolutely right, your code should not be using global variables! What a nightmare those are. Remember anything in a function without an explicit 'var' on it somewhere is global. "Oops." That's what happens when you design a language in 10 days (Javascript).
(I love making grown men cry...)
John Hawkinson wrote:
Replace if (var==null) with if (!var). === is almost always better than ==, because truthiness of == causes confusion and problems. But in ifs, you might as well use the implicit truthiness and not test explicitly, and write for clarity. (Someone is going to say this argument is defective
In my opinion, discussions about == vs. === vs implicit resolutions is kind of silly. I have no issue using ==. Just make sure you understand what it means.
Personally, I only use === when I really need it. That way it's clear what I'm testing for... When I'm testing for bull or boolean values, I usually skip the "==" altogether.
I don't take everything Crawford says as if it's the bible. They're only his opinions after all... 
Harbs
In my opinion, discussions about == vs. === vs implicit resolutions is kind of silly. I have no issue using ==. Just make sure you understand what it means.
Personally, I only use === when I really need it. That way it's clear what I'm testing for... When I'm testing for bull or boolean values, I usually skip the "==" altogether.
The problem is that it is often fairly subtle "when you really need it," and you don't notice until you've been bitten by it.
Everyone is pretty much always better off with ===.
I don't take everything Crawford says as if it's the bible. They're only his opinions after all...
Crockford.
And yes, his opinions are actually increasingly problematic. I can't even use JSLint anymore, he's added so many inappropriate checks that really boil down to style. The jslint_com yahoo group is kind of unpleasant. Oh well.
John Hawkinson wrote:
The problem is that it is often fairly subtle "when you really need it," and you don't notice until you've been bitten by it.
Everyone is pretty much always better off with ===.
I actually came across a situation where === was problematic, but I don't remember the details. There's no replacement for properly learning a language you use. (Whether it's a spoken language or computer one...)
John Hawkinson wrote:
Crockford.
Oops. Never nice to bollix up someone's name... 
John Hawkinson wrote:
Anyhow, I feel like your exception proves the rule. Use '===' always, unless you learn the language well enough to require truthiness promotion, because if you don't, you are likely to make an assumption about whether something is false versus null versus undefined, and that assumption will come back and hurt you later.
This is a bit like philosophy. You can argue both sides until you're blue in the face. Just about anyone coming from a C background would probably disagree. There's quite a lot of people who look at 0 and false as synonymous...
Whatever; I have bigger fish to fry...
Harbs
AdChoices