Arbortext "map" command

[GarethOakes]

Hi guys,

We are just helping out with a 5.3 -> 6.0 upgrade and have come across one peculiarity. Previously, in 5.3, this command enabled remapping of the toolbar "Print" button:

map Toolbar_Print { some_function(); }

Trying this under 6.0, it fails "Unrecognized key name: Toolbar_Print"

Anyone come across this before? What is the simplest way to override one of the built-in toolbar buttons in 6.0?

[cid:image001.jpg@01CDFA28.73158B40]

Gareth Oakes
+61-439-743-740

[tbihlmeyer]

seems to me like we had to change code from Print to Compose. Give that a try.

[tbihlmeyer]

Sorry, I'll bet it was Publish, not print.

[jsillari]

Gareth:

Check the release notes for 6.0 F000. Some of the commands were deprecated, and others renamed. "Compose" and "composition" were renamed "Publish" and "publication."

John Sillari
Chief Technologist
Dayton T. Brown, Inc.

[naglists]

I've done it a lot with menu items. Much more rarely with buttons. It's
trickier with buttons but I don't remember the exact technique to identify
the button/function/alias. Do you search in ../dialogs in .xml files that
manage the buttons? Something like that. If you can find the right .xml you
can find the right command (or more likely alias) to change.

The trick I use for menu items is:

response(menu_cmd("Menu.MenuItem"))

Which should show you the command behind that menu pick.

Then I do a recursive directory search of the Editor install tree for the
command (usually an alias) in *.acl. Usually the useful hit is the alias
being set to a package::function somewhere. Then it depends on whether you
want to map the alias (which might be called from many locations) or *just*
that menu item. You can remap the alias to do everything or menu_delete,
menu_add, (or is there a menu_modify or menu_change don't recall at the
moment) to do just the menu item.

If you still have a 5.3 system, you could chase the command you know
through ../dialogs/*.xml (again, not 100% that directory or file type is
the right one) and then chase that file in 6.0 for the new command.

Hope the spread of that shotgun gets you somewhere!

[ebenton]

Not that this is the problem in your case, but we upgraded from 5.2 to 6.0 and noticed that some lines of bad ACL code were being ignored by Arbortext 5.2. These same lines of code would cause Arbortext 6.0 to throw an error and stop.
For instance, we had a couple of non-existent functions named with curly braces in some lines with "map" commands in them. Arbortext 5.2 blithely ignored the error and continued unabated, but not Arbortext 6.0. So make sure that your "some_function()" is an actual valid function name.

[ptc-4875135]

The XUI dialog that drives the Editor's toolbars is in the install tree
under lib\dialogs\editwindow.xml, and if you look you'll see this in there:



<button command="FilePrint" id="Toolbar_Print" image="imagePrint"&lt;br"/>
statustext="&EditWindow_StatusTextPrint;"

tiptext="&EditWindow_TooltipPrint;"></button>



The key here is command="FilePrint". Most of the commands in the toolbar and
default menu configurations are declared in packages\commands.acl, and if we
look in there, sure enough we see this:



alias FilePrint {

if (doc_formattable()) {

FilePrintComposed;

} else {

FilePrintEditor;

}

}



So to customize printing behavior, you might be able to put an alias for
FilePrint in a custom\init script to redefine this command



alias FilePrint my_print_fn()



What I don't remember is whether custom\init scripts are sourced before or
after commands.acl. I think it's after, so that will work.



Chris

[GarethOakes]

Thanks to everyone for the assistance, all the UI customisations are patched up now.

For the record I can confirm that after Arbortext 5.3 the ACL "map" command will no longer allow toolbar buttons to be remapped. Something to watch out for when migrating 5.3 customisations. Another thing to watch out for as others pointed out is that certain aliases have been renamed (FilePublish vs FileCompose etc.)

The methods suggested by others on this thread are correct - best to use the standard aliase names and then redirect the aliases appropriately.

Cheers,
Gareth