General XMetaL Discussion
XMetaL Community Forum › General XMetaL Discussion › Application.CancelOpenDocument not working
-
rolandH October 14, 2013 at 2:13 pm
Application.CancelOpenDocument not working
October 14, 2013 at 2:13 pmParticipants 4Replies 5Last Activity 9 years, 3 months agoHello,
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,
RolandDerek Read October 15, 2013 at 8:45 pm
Reply to: Application.CancelOpenDocument not working
October 15, 2013 at 8:45 pmTwo 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.
kschipan April 2, 2014 at 7:33 am
Reply to: Application.CancelOpenDocument not working
April 2, 2014 at 7:33 amI 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?
Derek Read April 2, 2014 at 9:02 pm
Reply to: Application.CancelOpenDocument not working
April 2, 2014 at 9:02 pmXMetaL 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.
Derek Read April 3, 2014 at 12:12 am
Reply to: Application.CancelOpenDocument not working
April 3, 2014 at 12:12 amWe'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] kschipan April 16, 2014 at 9:27 am
Reply to: Application.CancelOpenDocument not working
April 16, 2014 at 9:27 amThat 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. -
AuthorPosts
- You must be logged in to reply to this topic.