Pages: 1
Print
Author Topic: Turn off: Automatic Validation befor Saving a Document  (Read 6080 times)
Sebastian
Member

Posts: 7


« on: February 18, 2010, 08:50:16 AM »

I would like to turn off the automatic validation of documents befor saving  them, because we would like to enalbe saving of invalid documents (using a DTD for validation). So far I tried to use the

Code:
ActiveDocument.RulesChecking = false;

flag, but I doesn't work out. I'm using the the

Code:
ActiveDocument.Save


method for saving documents.

Many thanks for your reply.
Logged
Derek Read
Program Manager (XMetaL)
Administrator
Member

Posts: 2484



WWW
« Reply #1 on: February 18, 2010, 04:29:43 PM »

Turning Rules Checking off (either using the rules_checking_always_off INI setting or the API) affects editing only. Validation is still performed as part of a save action in this case.

You may try this INI setting:
validate_before_export = boolean
The default value is yes.
Set the value to no to suppress validation during saves.

If this is not acceptable (this will affect all documents until you set the value to no and restart) you could override the File.Save and File.SaveAs events. Such a script would need to specifically not call the ActiveDocument.Save() nor ActiveDocument.SaveAs() methods but instead use something else to write the string obtained from the ActiveDocument.Xml property. You might use one of the standard Windows COM controls that provide write to disk functionality to do this, including MSXML, FileSystemObject, or ADODB.Stream, or another control if you know all your users will have it installed.

The alternative would be to provide another completely separate macro (ie: call it "Save without Validation") that would again use ActiveDocument.Xml and write that string out using one of the COM controls mentioned above or a similar method to write to disk. Then your users would have the option of using the standard Save function with validation and this other one that does not perform validation.

I'm not sure if this second one is really worth the effort or not, because you can still save an invalid document by selecting the Save button when prompted with the following dialog and users advanced enough to know they want to create invalid documents on purpose might be trained to understand what this means:

-------------------------------------------------------
XMetaL Author Enterprise

The document is not valid.
If you save the document will contain invalid markup.

[Save] [Cancel]
-------------------------------------------------------
Logged
Sebastian
Member

Posts: 7


« Reply #2 on: February 24, 2010, 03:17:06 AM »

Where is the flag
Code:
validate_before_export = boolean
located? We could not find a ini file or anything like that. We are using Xmax as ActiveX Plugin. Does it provide this options as well?
Logged
Derek Read
Program Manager (XMetaL)
Administrator
Member

Posts: 2484



WWW
« Reply #3 on: February 24, 2010, 12:53:43 PM »

XMetaL Author supports the INI file and settings. XMAX does not.

In a few cases, INI file settings in XMetaL Author have been turned into run-time properties for XMAX, which equate to <param> elements in an HTML page. All supported run-time properties are documented in the Programmers Guide.

However, as you are building the entire UI around XMAX anyway (ie: in theory you are starting with nothing and building your interface around XMAX to provide the user with a means to interact with it) you can just opt to not connect any of the built-in Save() methods if you don't want users to save that way. Instead of connecting Save() to your user interface you should be able to build something that saves the string returned by ActiveDocument.Xml instead.

If XMAX is embedded in a CSharp, VB, or similar application then use the methods they provide for writing text to a file. If you have embedded XMAX into a web application (HTML page) then you will need to look into using a control such as one of the ones listed below to save to disk, or perhaps submit the string to a web server or other (using MSXML / AJAX, or perhaps a standard HTML form GET or POST, or something else entirely) if it needs to be sent there.
Logged
Sebastian
Member

Posts: 7


« Reply #4 on: March 01, 2010, 02:28:49 AM »

I have implemented a custom save() function, it works out pretty well, but I still have a problem with the Dokument.Saved flag. How could I set it to true out of my custom function?

The problem with this flag is, that the "Would you like to safe..." dialog is still occurring, when the user is closing the XMAX editor, after saving with my custom save function.

Logged
Derek Read
Program Manager (XMetaL)
Administrator
Member

Posts: 2484



WWW
« Reply #5 on: March 01, 2010, 07:23:03 PM »

I don't think XMAX includes a dialog containing this text  -- specifically a dialog that includes the string "would you like to save". I think this is a behavior you would probably have to script into your application if you want it (or if someone supplied you with code you'd need to alter it to remove the behavior).

I would first do a search for that string inside your scripts to see if it is there and then try to alter the behavior of the code that is triggering the dialog. When you say "closing the XMAX editor" I assume you mean that the application hosting XMAX is being closed (as opposed to having XMAX close an open document). In this case the script is most likely to be with the host application (and not inside an XMAX MCR file for example).
Logged
Sebastian
Member

Posts: 7


« Reply #6 on: March 31, 2010, 07:24:32 AM »

I have implemented a custom Save-method as you recommended:

Code:
var fso  = new ActiveXObject("Scripting.FileSystemObject");
if (fso != null && absoluteFileName != null && absoluteFileName != "" && str != null) {
    var fh = fso.CreateTextFile(absoluteFileName, true, true);
    if (fh != null) {
        fh.WriteLine(str);
        fh.Close();
        ActiveDocument.Saved = true;   
    }
}

But I still have a problem with the encoding of the saved docs. The original doc is econded in UTF8 and should be UTF8 after saving with this method as well (like the standard Save of XMAX does). But the method above changes the encoding to unicode (because of the fso.CreateTextFile I think).

How do I have to modify the method, to safe the docs in UTF8 or even better, to save them in their original encoding (like XMAX behaves)?

Thank you for your quick response.
Logged
Derek Read
Program Manager (XMetaL)
Administrator
Member

Posts: 2484



WWW
« Reply #7 on: March 31, 2010, 03:57:11 PM »

XMAX does not have any methods that will let you easily detect the encoding, however, you could parse the Document.Xml as a string to look for the XML PI (declaration) at the start of the file and pull out the value for encoding="encodingtype".

Having said that, FSO supports the creation of two types of files: "Unicode" and "ASCII". There are no other options. Documentation at MSDN does not go into any detail about what they actually mean by "Unicode": http://msdn.microsoft.com/en-us/library/5t9b5c0c%28VS.85%29.aspx However, after examining the resulting file with a hex editor I see that this option creates files that are encoded in UTF-16.

Note: I would not recommend trusting Notepad on XP to properly identify the encoding of a file (many people do use it for this purpose). It may be correct most of the time but there are inherent bugs in the algorithm it uses: http://en.wikipedia.org/wiki/Bush_hid_the_facts

So, if UTF-8 is a specific requirement (ie: UTF-16 produced with FSO is not OK) you will need to find a control other than FSO. MSXML should, and perhaps ADODB.Stream would be another option. Both of these controls are fully documented somewhere on MSDN or Microsoft.com and should be available on most machines. Any computer that has IE6 (or later) installed should have version of MSXML and ADODB can also be considered fairly standard. The posting here ( specifically the one dated Thursday, January 01, 2009 8:21 AM) may help: http://www.eggheadcafe.com/software/aspnet/33785134/how-to-configure-msxml2.aspx

Down the road we are looking into implementing a feature that will allow more options to be set in XMAX that are currently only supported in XMetaL Author only by setting INI variables.
Logged
Markus
Member

Posts: 3


« Reply #8 on: September 26, 2016, 10:27:06 AM »

Hi Derek,

I have seen that in XMAX 11 the validate_before_export property is supported in the XMAX ini file. Is there an API method that allows to set this property during runtime on the XMAX object? We are using XMAX in a WPF project.

Thanks,
Markus
Logged
Derek Read
Program Manager (XMetaL)
Administrator
Member

Posts: 2484



WWW
« Reply #9 on: September 26, 2016, 02:31:02 PM »

XMAX does not have an INI file (as noted earlier in this thread).

The API you are hoping for (to turn off validation) does not exist (even in the current release, which is 11), so you would have to implement something similar to what Sebastian has done. Basically that amounts to grabbing the XML source and passing that into your application as a string variable (using the API ActiveDocument.Xml) and then writing that string to disk using code in your application.
Logged
Markus
Member

Posts: 3


« Reply #10 on: September 27, 2016, 02:26:26 AM »

On my machine there is the file:
C:\Users\USERNAME\AppData\Roaming\SoftQuad\XMetaL XMAX\11.0\(null).ini

Adding the entry
  validate_before_export=no
will disable the validation in XMAX.
Logged
Derek Read
Program Manager (XMetaL)
Administrator
Member

Posts: 2484



WWW
« Reply #11 on: September 27, 2016, 01:28:04 PM »

This must be a new feature in a later version of 11 (we have released a few dot releases of 11). I'll check with development so that we can update the documentation.
Logged
Derek Read
Program Manager (XMetaL)
Administrator
Member

Posts: 2484



WWW
« Reply #12 on: September 27, 2016, 05:01:22 PM »

This INI file is being written out due to some shared code with XMetaL Author that should actually be disabled in XMAX. I would not rely on it or build a solution that assumes it will exist in future releases. It might seem to support some INI settings that are shared with XMetaL Author, but most settings will not work as they don't apply to XMAX. Most INI settings have to do with the UI and features in XMetaL Author that do not exist in XMAX (features that, if needed, would be created as part of the containing application).

Our team has been adding runtime properties and APIs to XMAX when they are identified as being useful (including user requests). I've asked that they look at supporting an API equivalent to this particular INI setting for a future release.
Logged
Pages: 1
Print
Jump to:  

email us