General XMetaL Discussion

XMetaL Community Forum General XMetaL Discussion Application.CancelOpenDocument not working

  • rolandH

    Application.CancelOpenDocument not working

    Participants 4
    Replies 5
    Last Activity 8 years, 11 months ago

    Hello,

    I was trying to override the opening process of a document, with the posibility to cancel the opening under certain circumstances.

    The problem is that setting Application.CancelOpenDocument = true in the “On_Application_Before_Document_Open” macro is not working.

    I tested this on version Version#: 8.0.1.041, but also Version#: 6.0.1.030 of the XMetaL Author Enterprise.

    Can you please tell me what is going on?

    Thank you,
    Roland

    Reply

    Derek Read

    Reply to: Application.CancelOpenDocument not working

    Two things use this property and the conflict is likely to be there:

    1) CMS integrations (possibly various uses depending on the integration).
    2) The DITA authoring solution. It uses this primarily to decide if a document is a DITA map and stop it from opening so that it can be opened instead in the Map Editor (if that is the user preference).

    Perhaps you could explain in more detail what your code needs to do so I can let development know and see if they can support your use case while allowing these other features to function. If you prefer to discuss this privately please go through XMetaL Support.

    Reply

    kschipan

    Reply to: Application.CancelOpenDocument not working

    I have faced the same problem and just contacted the XMetaL support.

    I implemented the macro “On_Application_Before_Document_Open” in order to check if the opening file is a ZIP archive: getPlugin.isZipFile(Application.OpenFileName)
    Within our “Plugin” the containing XML files are extracted and opened instead: getPlugin.openSozdokFilesFromZipArchive(Application.OpenFileName)
    This really works fantastic.
    Since an ZIP file cannot be edited itself with XMetaL, I want to stop the process of opening that file: Application.CancelOpenDocument = True
    Unfortunately XMetaL doesn’t  care about this changed property as expected.

    This is my macro code:


                    MsgBox “Sozdok:On_Application_Before_Document_Open:” & Application.OpenFileName & ” Cancel = ” & Application.CancelOpenDocument, , “SozDok Debug”
                   
                    If (getPlugin.isZipFile(Application.OpenFileName)) Then
                                  getPlugin.openSozdokFilesFromZipArchive(Application.OpenFileName)
                                  Application.CancelOpenDocument = True
                    End If                 MsgBox “Sozdok:On_Application_Before_Document_Open:” & Application.OpenFileName & ” Cancel = ” & Application.CancelOpenDocument, , “SozDok Debug”
    ]]>

    I also tried the simple thing: Just stopping each opening – it doesn’t seem to work.

                    MsgBox “Sozdok:On_Application_Before_Document_Open:” & Application.OpenFileName & ” Cancel = ” & Application.CancelOpenDocument, , “SozDok Debug”
                   
                    Application.CancelOpenDocument = True
                   
                    MsgBox “Sozdok:On_Application_Before_Document_Open:” & Application.OpenFileName & ” Cancel = ” & Application.CancelOpenDocument, , “SozDok Debug”
    ]]>

    How can I manage that task?

    Reply

    Derek Read

    Reply to: Application.CancelOpenDocument not working

    XMetaL Support replied asking for files that will reliably reproduce your issue and also asked that you let them know which product you are running (XMetaL Author Essential or XMetaL Author Enterprise) as well as the version. If you provide them with that information they should be able to figure out exactly what's going on.

    Reply

    Derek Read

    Reply to: Application.CancelOpenDocument not working

    We've had a discussion here and made some assumptions and we think we know what your issue is.

    If you are running a newer version of XMetaL Author Essential or XMetaL Author Enterprise it includes some common code libraries (internally called the XMDK and included starting around the 6.0 release). The XMDK (which is undocumented) takes over the On_Application_Before_Document_Open macro. You could disable the XMDK but it is used by the DITA authoring functionality and some other features so it best not to do that.

    We are looking into what it might take to make the XMDK cooperate nicely with your code as written, but in the meantime you can ignore what the documentation in the Programmers Guide says and implement something (also undocumented) called an XMOpenRedirector object, basically injecting your own code into the XMDK so that it will also run.

    For this to work your code will need to be rewritten in JScript. We've rewritten the code you posted here as an example. You'll need to make sure that your “getPlugin” object is defined and I'm not sure if this will work with it as we have not seen that code.

    [code]  SozDokOpenRedirector.prototype.constructor = SozDokOpenRedirector;      
     SozDokOpenRedirector.prototype.parent      = XMOpenRedirector.prototype;        function SozDokOpenRedirector ()
     {
     }
     SozDokOpenRedirector.prototype.isNeeded = function(xmlFileURI)
     {
       Application.Alert(“SozDokOpenRedirector::isNeeded:” + xmlFileURI);    // Check for zip file types that we handle…returning true
       // will cause our “doOpen()” method below to be called…
       if (getPlugin.isZipFile(xmlFileURI))
         return true;    // Leave this file for another redirector to handle
       return false;
     }
     SozDokOpenRedirector.prototype.doOpen = function(xmlFileURI, viewMode, CRLocator, isReadOnly, info)
     {
       // Cancel open of zip file and let our plugin handle it…
       Application.CancelOpenDocument = true;
       getPlugin.openSozdokFilesFromZipArchive(xmlFileURI);
     } ]]>

    [/code]

    Reply

    kschipan

    Reply to: Application.CancelOpenDocument not working

    That workaround even works with version 5.5 of XMetaL.
    I just had to put the given macros into a new file within the “StatUp” directory.

    “Please try moving your macros into a new MCR file inside the Startup folder. They should be inside an MCR file that loads after this file: __xmau_services.mcr These files are loaded in alphabetical order, so that file should be loading first (the underscore characters sort higher than “A”). As long as your filename starts with a letter it should load later.” – thank you for that hint, Derek.

    Note: My first try was to use the existing file “Macrosxmetal.mcr”, but I got a “Run-Time Error” message:
    Line 87, Column 4
    Description: The Object doesn't support that property or method.

    Reply

  • You must be logged in to reply to this topic.

Lost Your Password?

Products
Downloads
Support