Skip to main content
1-Visitor
November 16, 2012
Question

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

  • November 16, 2012
  • 5 replies
  • 1397 views
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

    5 replies

    November 16, 2012
    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
    naglists1-VisitorAuthor
    1-Visitor
    November 16, 2012
    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.


    18-Opal
    November 16, 2012
    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


    naglists1-VisitorAuthor
    1-Visitor
    November 16, 2012
    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.


    naglists1-VisitorAuthor
    1-Visitor
    November 17, 2012
    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!