[A11204] No menu matched: errors on queuing large documents in 6.0 m010

[naglists]

Has anyone seen this? When I queue a large document, I might see the
following types of errors (this is just a subset). I think it is a Windows
memory related thing, or a timing thing, as it is not consistent and seems
to only happen on large documents. I think they are coming from menu
customizations I set with a load menu hook.

I tried reporting window_get(current_window(),"title")) to see if I could
isolate the Queued Transaction window but that window title never displays.
Only the title of the document open in the main window.

[A11204] No menu matched: $DeleteMarkupLabel

[A11204] No menu matched: .Edit.

[A11204] No menu matched: .Edit.Edit Profiles.

[A11204] No menu matched: .Edit.XUI.

[A11204] No menu matched: .Find.

[A11204] No menu matched: .Insert.

[A11204] No menu matched: Help

[A11204] No menu matched: Help.

[A11204] No menu matched: Insert.Link
[A11204] No menu matched: Insert.Rollup Link.

--
Paul Nagai

[JasonBuss]

I have seen this when I have more than one load menu hook firing when loading a doc. I had this happen when we had our CMS loading an ACL file to add their custom object menu. I had to take my load menu hook callback and combine it with the one from the CMS vendor, set it off separately, then I could get the redundant menu loads to stop. It's wonky, I know, but only one of each callback per session seems to be how editor loads, it doesn't override one with the next, or append. As long as one callback gets loaded with one func, these should go away.

Hope that helped...

-Jason

[naglists]

Interesting. I did have to do some funky magic tricks back in 5.3 in order
not to have the Documentum menu load fail (or was it my menu load) but it
was only a few of the menu items that conflicted so most of mine run from
editinit, but one or two are loaded via an APTsomethingorother environment
variable setting. Hmmm. Maybe that environment setting changed or works
differently now. Well, something to look at tomorrow.

Thanks, Jason.

[ClayHelberg]

Hi Paul--



This might be due to a menu load hook you've defined, where it doesn't
filter by window type. I've had this happen myself a few times, with log
windows and such trying to load custom menus intended for the edit
window.



If that's the case, you might need to add a test for the window type in
your menu hook function. Alternatively, you can add explicit tests for
each level of the menu before trying to check submenus, etc.



--Clay





Clay Helberg

Senior Consultant

TerraXML

[naglists]

Hi Clay,

Yes, I am pretty sure I do have individual menu and menu item tests, but
it's certainly possible I've missed a few. I don't think I've tested for
window type for this before, though. Maybe that's the ticket. FWIW, the
code works fine in 5.3.

[naglists]

I have resolved my problem. I now include two tests inside of my menu load
hook function.

I check the window class and return/exit if class != "edit".
I check the window title and return/exit if title == "Event Log".

I prossibly could have gotten fancier/more elegant, but those worked, so
I'm done.

The size of the document was a red herring. It contained references to
missing graphics which triggered the event log.

Not sure if the Event Log window type changed or whether the menu load hook
changed or some other factor changed (maybe our setting for show / don't
show warnings/errors/etc. changed) but whatever it was, I've adapted.

And for posterity's sake, Clay, you were right about something else: Some
(maybe even many) of my menu / menu item tests only test the full menu
tree. For example I might say, "if Tools.Mytool doesn't exist, menu add
Tools.Mytool" BUT I don't ask whether Tool is there. Into my "For another
day" file as the top level fix fixed.

Thanks, all, as always. Happy Friday!