I'm transforming an XML document by using Xerces-C 2.5 and Xalan-C 1.8. The XSL contains a "document" function, that references a file on the network. Unfortunately I cannot access this file by HTTP. I've only got the UNC path.
Xerces refuses to parse the referenced document, because WinSockNetAccessor::makeNew is called in Xerces as the "file" protocol is only accepted for local files. WinSockNetAccessor::makeNew is implemented for HTTP only, an exception is thrown and the file is ignored.
Is there a way to fool Xerces in order to accept the unc path as local file or any other known workaround without writing my own parser or manipulating Xerces?
A simple workaround would be, I guess, to just create a mapping, so you can call the network drive O: or whatever. That often fools programs that can't work directly with a UNC path (such as cmd.exe itself).
Does the UNC as it appears in the XSL have a "file:" prefix?
BTW, Xerces C V2.5 is several years old. Have you tried the latest version - V3.0.1 at the moment?
Related
I would like to know how do I open a file with a specific extension
Inside the downloads folder. I try this:
set downloads to "~/Downloads"
set fileExtension to ("pkg")
open every file of downloads whose name extension is fileExtension
I know I could use:
do shell script "open ~/Downloads/blabla.pkg"
and this would work fine but with every update the file changes its name and this would not be interesting to me.
thanks advance!
While do shell script can use a string for a path, AppleScript itself has limited file handling abilities, so you need to tell it to use something that does, such as the Finder or System Events. A file specifier (such as alias, file, or application scripting terms such as folder or disk item) also needs to be used to differentiate a file item from a regular string (such as a POSIX path). Depending on the application used, there may be other differences from the shell, such as tilde expansion, so the StandardAdditions scripting addition provides paths to common locations:
set fileExtension to ("pkg")
tell application "System Events"
repeat with anItem in (get every file of (path to downloads folder) whose name extension is fileExtension)
open anItem
end repeat
end tell
Also note that using the filter reference form “whose” only works with application objects, and not regular lists or records. AppleScriptObjC also has access to Cocoa methods, so you can use the NSWorkSpace or NSFileManager classes, although going that route tends to get a bit more verbose.
I created application that store some data to XML file. The issues is with the path of the XML saving. Am using TinyXML to save the data in vc++.
When I deploy this application, it installs in "C:\Program files(x86)\applicationname " and when I run the application the XML file is saving in
"C:\Users\UserName\AppData\Local\VirtualStore\Program Files (x86)\ApplicationName ".
I have made this application to work on system startup. So when I restart this application,
the xml file is stored in different path "C:\Users\UserName\AppData\Local\VirtualStore\windows\sysWOW64"
I want my XML to be stored in the path where I installed or should be stored in appdata, application name
What should I do to store XML file in one places where application is installed?
doc.SaveFile( "test.xml" ); // xml saving code in tinyxml library
Firstly, this has nothing to do with C++, as the C++ code is probably working. Same with XML and tinyxml and even visual-c++.
It seems that windows redirects those write accesses to a user-specific "VirtualStore\Program Files", but I'll leave it to you to research the actual semantics of that. On startup, when there is no user, this path obviously differs, since the former user is not logged in.
Now, in order to get a fixed path, you can use the function GetModuleFileName() to find out the location of your executable and use that path to locate Smartmeter.xml. However, the problem you are facing now is that programs installed under "Program Files" don't magically gain write access rights to their install directory. This is to protect one user from messing with data of another user.
I think that what you are doing is writing a program that runs in the background, which would be called a "service" under MS Windows. What is still unclear is what you want to achieve with this file and also what you are planning to do overall, and these are things that decide the future steps. In any case, take a look at the possibilities that services provide, maybe there is something that fits your needs.
I understand the use of document() as follows.
<xsl:value-of select="document('path\to\docuemnt.xml')/RootElement/Element"/>
And this has to be a relative path to the parent XSL file. But what if I need to reference a file which is hosted on another server on the local network? I've tried such things as.
<xsl:value-of select="document('\\servername\path\to\document.xml')/RootElement/Element"/>
But this throws an error, because it looks in
C:\path\to\xsl\\servername\path\to\document.xml
Which of course doesn't exist.
This solution only relates to the Saxon-HE 9.4.0.3N XSLT processor, in the console application form, on Windows 7.
In my experimentation, I found that the document() function will accept file names or URIs. However I would avoid filenames because they need to be short-form. If you use long-form, the file-name will be rejected.
Suppose your document is ...
c:\path\to\document.xml
on server 'servername' which is mapped to drive 'j'.
To form a URI from this use as the document() parameter value...
file:///j:/path/to/document.xml
In relation to the URI, I was mistaken about Saxon not accepting long-form. This only applies to filenames. However, there are a number of gotchas...
Note the forward slashes. Backslashes will not work.
I have not found a way to build a workable file: URI with just UNC names. You need to make a drive mapping to a letter.
Any failure to open the document for any reason will be reported as the same error. With file system, there are so many things that can go wrong, that if you can't open the file, it is not safe to assume that the URI is wrong. There could be many mundane reasons why a file cannot be opened at a particular time.
Beware of firewall issues. These play a role.
Many text editors, such as NotePad++ assume, in the absence of a BOM and not encoded in one of the two UTF-16 encodings, that a text file is encoded in the system code-page. Saxon will make the default assumption that the file is encoded in UTF-8 so if you have a character that looks like this in NotePad++ (ä) with my code-page, Saxon will spit the dummy, and report that it is unable to open the file. (Aside: I'm not sure what my code-page is. My o/s is Win7 and the Current system locale is English (Australia). It is the system local that determines the system code-page). The reason why Saxon will not open the document is that the (ä) encoded in some code-page results in a sequence of bytes which is not a valid UTF-8 sequence.
URI paths which are not URL paths are not supported by the underlying operating system. Saxon may well truthfully say that it supports URIs in relation to the document() function, but that doesn't boil any cabbages, because in practice, you can't use them. - Well at least not on the windows family of o/s.
Please ignore the MSDN page on the file protocol. The form of URL suggested on that page (with the | character etc) is not accepted by the Saxon document() function. Use the form that I have suggested above. I have tested it and it works.
Your understanding of document() is incorrect. It expects a URI, not a filename.
I'm seeking C++ help in writing HTML code to a new tab in Firefox within an extension.
Our C++ code has been partially wrapped by an XPCOM wrapper and embedded within a Firefox extension thanks to the work of a consultant we have lost contact with, and still partially implemented by calling out to a standalone executable.
To get our output displayed from the standalone executable, the C++ code writes the output to a file and simply calls system(firefox file.html) which then comes up with a file:-based URI.
This no longer works in all situations, based on a report from a user running Vista. So it seems to be time to do it right, and navigate the DOM, likely integrating the rest of the C++ code into the XPCOM-wrapped part. Perhaps there's a right way to do it from the standalone executable using the DOM model?
The "current working directory" seems to no longer match the directory in which the extension installed the standalone executable, with a "VirtualStore" path element.
We also generate parallel output in a different MIME type, VRML to be specific.
Any suggestions or examples for how to properly generate output into a Firefox browser pane under C++ programmatic control would be very much appreciated.
You could call Firefox with a fully specified file:/// URL, not a relative URL (file.html).
Or you if you want to dump a separate executable, you could implement a protocol handler or a simpler about module (where ios.newChannel would be replaced by your own channel implementation that generates the data).
I'd say keeping the file-generation solution is OK and doesn't seem very bad, so I'd go with (1), perhaps changing the generated file location to a temporary folder and specifying it fully both for the executable that generates it and for Firefox.
I have an InnoSetup for my C# application. And I'd like the setup to check for updates before installing (to make sure the user always gets the latest version). To do this, I need a bit of C++ code to parse an xml file from a remote location (which contains a version string) and have a method return it.
From InnoSetup I can call the DLL and compare it to a local variable in the InnoSetup code.
Any clues on how to do this?
If you have access to the server side, it might be better to not use XML, just return version string. If you can't avoid XML, you should write your C++ code (if that's you question, I suggest using TinyXML), then create a dll export for a function returning the version string.