The hope is that XMLQuire will complement CoherentWeb in promoting the use of Virtual Formatting to a wider set of developers and XML authors in general. If more XML tools could only adopt this concept, then interoperability between tools would be greatly improved.
As things are, there are still comments coming in that show I'm not explaining very well what Virtual Formatting does, both for the XML editing user-experience, but more importantly, for the integrity of the XML itself. I think the problem lies in that we've grown so used to inserting characters for indentation that we find it difficult to consider the problems indentation characters cause and what the alternatives are.
Perhaps these two product can do their bit to spread the word - with the introduction of Virtual Formatting, it's no longer a question of 'tabs or spaces?' but 'indentation characters or ... nothing?'.
I got an error on startup, trying to run XMLQuire on a Windows Server 2008. The EventLog shows me this .NET exception [it's German, but you'll get it]:
ReplyDeleteAusnahmeinformationen: System.IO.FileNotFoundException
Stapel:
bei XmlTester.Form1.TestInkEdit(Boolean ByRef, System.String ByRef, System.String ByRef)
bei OnlyXml.FrmOnlyXml..ctor()
bei OnlyXml.Program.Main()
I activated the Ink and Handwriting feature and restartet the machine, just to be on the safe side. Can you help me out here?
Why is the Ink and Handwriting feature needed in the first place?
@Anonymous
ReplyDeleteTo date, I've only tested this on Windows Server 2008 R2 x64 - on my test build it works fine once Ink/Handwriting feature is enabled and after a reboot.
This feature is required for the performance and responsiveness of the XML Editor which uses the Inkedit control, a 'drop-in' upgrade to RichTextBox.
InkEdit gives more than 20 times the load performance on a 4MB XML file over RichTextBox, this control is packaged with Ink/Handwriting features which is enabled as standard on client machines, but not on the server. Without this, XMLQuire would be unusable on larger files.
If you send more details on your specific WS2008 environment (x86/x64 + release version) to support@qutoric.com, I can look into this further.
Phil
@Anonymous (belated reply)
ReplyDeleteThanks for the extra details (offline). The problem seems to have been that .NET 4 was installed on your server, but the XMLQuire version then available only supported up to .NET 3.5.1.
There's now also a .NET 4.0 build available from:
http://xmlquire.com
Phil, the product is great. I have downloaded XMLQuire and I love it. Thanks a lot for putting this together.
ReplyDeletePhil, do you think you could review the support for CLI arguments? Currently, it crashes (with a NullReferenceException) if I pass anything in the CLI (version 1.17). I'd love it if I could pass in a list of files to open in XMLQuire so I could automate it into workflow.
ReplyDeleteMy system in Windows 7 x64 with UAC disabled, and I've tried this with files in the same folder (XMLQuire.exe atom1.xsl) and with fully-qualified paths (XMLQuire.exe y:\www\atom0.xsl")
I can open it without arguments and darg/drop files into it for editing, so it runs and opens fine other than that.
@Anonymous I'll check out the CLI issue you're reporting. In the mean time, you could try modifying the recentfiles.txt file that's store in the application-data path, which will be something like: C:\Users\philip\AppData\Roaming\Qutoric\XMLQuire
ReplyDeleteThis won't affect the file that is opened when XMLQuire launches, but it at least provides easy access from the recent-files list. The recentfiles.txt file is continuously monitored, so the list is updated even if one or more instances of XMLQuire are already open.
Thanks, Phil. It's also a bit of an obstacle to associating files with XMLQuire and launching them from explorer. I'll deal with the recentfiles list for now.
ReplyDelete@Anonymous - Thanks for this feedback, I'll consider providing optional file association to give 'open-with' right-click functionality.
ReplyDelete