|
The purpose of the code is to convert an XPS file to PDF using the external GhostXPS converter program (gxps.exe).
It's a fairly simple process and works flawlessly with everything tested up to Windows 8. It has been tested on XP, various flavors of Windows 7 and Server 2008 R2. Even using the same instructions from cmd line in Windows 8 is successful.
for clarity:
"path" is the entire path where gxps.exe is installed.
"filename" is the complete path of the xps file to convert
"retStr" is the complete path of the pdf file as converted (same as filename only with a pdf extension).
The file paths of filename and retStr are C:\Users\"username"\AppData\Local\Temp directory so permission issues should not be a concern.
Code follows:
CString progName( path + _T("gxps.exe ") );
sParam.Format(_T("-sDEVICE=pdfwrite -sOutputFile=%s -dNOPAUSE %s"), retStr, filename );
SHELLEXECUTEINFO sei = {0};
sei.cbSize = sizeof(SHELLEXECUTEINFO);
sei.fMask = SEE_MASK_NOCLOSEPROCESS;
sei.hwnd = NULL;
sei.lpVerb = NULL;
sei.lpFile = progName;
sei.lpParameters = sParam;
sei.lpDirectory = NULL;
sei.nShow = SW_HIDE;
sei.hInstApp = NULL;
if ( ShellExecuteEx(&sei) )
{
::WaitForSingleObject(sei.hProcess, INFINITE);
}
CloseHandle(sei.hProcess);
Curiously, the gxps program executes without indicated error. The result of execution is "42" which according to the MSDN docs is a success code. However the result is always a blank 760 byte pdf with no content. Breakpoints indicate the XPS is completely valid before conversion.
I've never seen a command line program return a different result when executed from cmd or ShellExecuteEx and am completely baffled.
Does anyone have any ideas on what is happening here or has anyone else experienced a similar problem with ShellExecuteEx?
Thanks in advance for any assistance.
|
|
|
|
|
Have you tried running filemon to see if you get any errors on that input file?
I'm guessing - it may be an issue with the input file being locked or some other security issue ?
|
|
|
|
|
Thank you for responding.
I ran Process Monitor(current version of Filemon) per your suggestion. Indeed it produced some curious results.
I compared Win 7 processes with 8 and noticed the file IO is at least described differently between the two.
With 7 ReadFile and WriteFile operations are shown.
With 8 these operations are called FASTIO_READ and FASTIO_WRITE.
Intermixed with the FASTIO_WRITE operations with SUCCESS result there are a curious mix of FAST IO DISALLOWED results. I am unsure what this may indicate.
Apparently some write operations were permitted while other write operations were not. This would be consistent with the end result but there is no indication why some of the writes were disallowed. There was also no general failure to the gxps process when these were encountered.
Hopefully this sparks someone's interest with more knowledge of the win 8 architecture than mine and can help lead to a solution.
|
|
|
|
|
This is only a guess - but I have a feeling the input file (XPS) may be buffered/cached and not completely written to disk yet when you try to open it with GS.
Just before your shellexecute setup - why don't you try to open the xps file low level in non shared mode and then close it? You may notice what is going on with that xps file via errors. The idea here is to see if you can open it - and view all the contents (and then close it after of course).
Your output file is not the problem - it's your input that's the issue....
|
|
|
|
|
Rene Pilon wrote: The idea here is to see if you can open it - and view all the contents (and then close it after of course).
Your guess was right on. It is definitely a problems with the input file.
I added code to open and display the xps just prior to conversion. The default win 8 reader was unable to open the file: "There is a problem with the file format".
This indicates to me that the xps is not fully formed yet for whatever reason.
A great help, thank you.
I'll try to see what's holding up the xps process and let you know the resolution.
|
|
|
|
|
The file produced by MS XPS printer is inaccessible to even file copy.
Yet, the very same xps file can be attached and sent via email.
I attempted to have the program copy the original file after it was sent to email since it is obviously closed and ready for MAPI to use. The emailed version produced a perfectly usable attachment. But then, CopyFile results in ERROR_ACCESS_DENIED. Setting file attribute to "normal" results in the same inability to use the file.
I used:
if ( CopyFile(original.xps,new.xps,TRUE) )
The Email process is making a copy of the file, so why can't CopyFile? Any ideas? I'm at a loss why this xps is so resistant.
|
|
|
|
|
What happens when you run that directly in a command window?
Veni, vidi, abiit domum
|
|
|
|
|
Thanks for responding,
When run from the command line it executes perfectly.
|
|
|
|
|
I want to define a 3D array like this:
Type ary[3][6][7];
Is it possible in C++? I'm using Visual Studio 2010, Boost library is not allowed. If it's possible, please tell me how to initialize each dimension?
|
|
|
|
|
You cannot do that since an array must be typed at its declaration, and that defines the type of each element in the array. You could declare an array of unsigned int and then use casts to set different types in some cells, but it would still be somewhat confusing. Perhaps you should explain what problem you are trying to solve.
Veni, vidi, abiit domum
|
|
|
|
|
+5... when you need to support multiple types, use the largest (byte-wise) and cast... but yes, it may be a bit confusing to others reading the code
|
|
|
|
|
Thanks. Personally, I think it's a daft idea.
Veni, vidi, abiit domum
|
|
|
|
|
You seem to understand the question as storing elements of different types, but I think the request is about using alternate types of index values. See my response.
GOTOs are a bit like wire coat hangers: they tend to breed in the darkness, such that where there once were few, eventually there are many, and the program's architecture collapses beneath them. (Fran Poretto)
|
|
|
|
|
Stefan_Lang wrote: You seem to understand the question as storing elements of different types Well that's what the OP asked for.
Veni, vidi, abiit domum
|
|
|
|
|
(Wathever you want to do) it doesn't look possible.
Veni, vidi, vici.
|
|
|
|
|
If you mean that the type of the index value needs to be different, then the only way to achieve this is defining your own subscript operator overloads, and that means you need to define your own array class(es).
Here's an example of how to define and use such overloads to create a 3D array like you describe:
enum EMyColors {
C_RED,
C_GREEN,
C_YELLOW
};
template <class Base, int n_elements>
class CMyArray1 {
std::vector<Base> values;
public:
CMyArray1() : values(n_elements) {} Base& operator[](const wchar_t wc) {
size_t index = wc - L'a'; assert(index < values.size());
return values[index];
}
};
template <class Base, int n_vectors, int n_elements>
class CMyArray2 {
std::vector< CMyArray1<Base, n_elements> > vectors;
public:
CMyArray2() : vectors(n_vectors) {} CMyArray1<Base, n_elements>& operator[](int i) {
size_t index = i - 1; assert(index < vectors.size());
return vectors[index];
}
};
template <class Base, int n_arrays, int n_vectors, int n_elements>
class CMyArray3 {
std::vector< CMyArray2<Base, n_vectors, n_elements> > arrays;
public:
CMyArray3() : arrays(n_arrays) {} CMyArray2<Base, n_vectors, n_elements>& operator[](EMyColors c) {
size_t index;
switch (c) {
case C_RED:
index = 0;
break;
case C_GREEN:
index = 1;
break;
default:
index = 2;
break;
}
return arrays[index];
}
};
int foo() {
CMyArray3<int, 3, 5, 8> my_array;
my_array[C_GREEN][3][L'c'] = 17;
}
GOTOs are a bit like wire coat hangers: they tend to breed in the darkness, such that where there once were few, eventually there are many, and the program's architecture collapses beneath them. (Fran Poretto)
|
|
|
|
|
An excellent and creative solution!!
The difficult we do right away...
...the impossible takes slightly longer.
|
|
|
|
|
char *** array; and allocate it.
|
|
|
|
|
Simply define the needed datatypes as UNION and make your array of the union type:
enum MyEnum { X, Y, Z };
union MyUnion {
MyEnum _Enum;
int _Int;
const wchar *_Pwchar;
};
MyUnion ary[3][6][7];
|
|
|
|
|
Hi,
Created software for electric switch (one directional) with UPD protocol. At first I created both sides with c#. Worked well but slow, had to restrain my "Transmitter" for the receiver to collect all relevant data. Now for better performance I program a native receiver. All is going well except the "recv" and the "recvfrom" methods only receive 517 bytes of the package size transmitted: (Maximal UDP)65507. How can I receive maximal upd package with a blocking socket?
|
|
|
|
|
You need to keep receiving until there is no more data. TCP and UDP messages get broken up to send across the wire, so you will not always receive the complete message in one go.
Veni, vidi, abiit domum
|
|
|
|
|
UDP messages will not be broken up. But TCP will mostly (possibly except when Nagle is turned off).
Gisle V.
# rm -vf /bin/laden
/bin/rm: success
|
|
|
|
|
Thanks, you are right of course.
Veni, vidi, abiit domum
|
|
|
|
|
Hi,
This is incorrect if the packet is transmitted over IPv4. All packets are subject to fragmentation over IPv4 and governed by smallest MTU in the route. Note that if the DF bit is set the router will *not* fragment the packet and will instead send back an IMCP response containing the message "fragmentation needed and DF set".
It would be correct to say that routers on an ipv6 network do not fragment and instead the MTU is honored at both receiving end points due to PMTUD.
Best Wishes,
-David Delaune
|
|
|
|
|
This might have something to do that UDP Messages get broken up into different UDP Packets.
For example, the message
"Hi, I am a UDP message and I maybe get transmitted as multiple UDP packets"
might be transmitted as
"Hi, I am a UDP mes"
"sage and I maybe get transmitted as multiple U"
"DP packets"
Due to this you might need to read packets until you KNOW that the message has ended, e.g. by using a fixed message length or a defined control character marking the end of the message.
To answer your question: Your socket will remain blocked until the whole message (= every data packet) is received, but you can avoid a block of your whole program by using a separate thread for your socket.
Veni, vidi, caecus | Everything summarizes to Assembly code
|
|
|
|