Archived Data Techniques Forums

Hi


The thread I started on this seems to have died ?????

I still have the same problem on various machines, you call faxprinter.exe with the file name you want to be viewed, and get a dumb messagebox that says "unable to open C:\proga"

Can I please get a proven resolution to this, as many systems do not have another suitable fax viewer....

Thanks


Ian Turner

I set up a plain Jane W98 box and installed FaxMan SDK v3.62.

I can:
Double click any FMF file in Explorer and FaxPrinter launches and displays the file.

Print a file from the command line (faxprinter -p c:\mydir\myfile.fmf)

Load and display a file from the command line (faxprinter c:\mydir\myfile.fmf)

Hi Rush

I believe have just identifed the cause of all the grief !!!

Is this (faxprint) a VB3 Application or similar ???

The reson I ask is that if you have any long path name (or part thereof) in it, it fails, hence the "Unable to open C:\program" messages

If you try to open a TIF of FMF in a standard 8.3 format (short filenames) path, as you did, it does work as expected.

But after all, long path names have been around in Windows since 19xx..............

I really do believe that any program out there today (the viewer in this case) should be capable of handling long file names in paths without us developers having to resort to th overhead of calling Getshortpathname() all over the code just to overcome this problem ??

Can't DTI overcome this trivial issue ??

Ian Turner

Ian -

The FaxPrinter DOES support LFNs. Th eproblme you are encountering is a problem with the file association you have setup. Its caused by the space in the directory name.

To fix it you need to add parens around the passed filename in the file association, this will cause the faxprinter to see the whole filename as 1 string instead of several different parts delimited by spaces.

You can test this manually by running for instance;l

faxprinter c:\program files\foobar\test.tif --- This will get the same error you are seeing becaus it appears to the faxprinter app that there are multiple filenames.

faxprinter "c:\program files\foobar\test.tif" --- This will work, notice the quotation marks around the filename.

Hi Sean,


We are back to adding in bunches of the "special Cases" code because Faxman cannot do what every other app cn do automatically today. handle LFN's correctly without our having to massage them in to the format used by older versions of windows.

Its the same as this ludicrous double slash stuff we have to do to get Fxcreate to accept a perfectly valid null terminiated C String, as it cannot handle the double slashing internally.

That alone raises all sort of horrors as the path are often passed down as perfectly sound C pointers on the stack, so the length of these cannot be expanded to include the doubling of the slashes in the functions below

It's becoming totally crazy.!

We have writen many libraries, for SMTP, POP, SNTP etc, and ALL use LFN's, but
NONE have to have all this rubbish added to allow them to use the LFN's - they just handle it by accepting standard null terminated C strings........

Ian Turner

Ian -

I feel compelled to respond here as you have made some accusations that are not true.

As far as requiring a doubling of slashes in a literal C string, this has nothing to do with FaxMan but everything to do with the C and C++ langauge. Look at any C/C++ book or the website I pointed to in the previous reply and you will see that. The doubling of the slashes is only required when you specify a literal string and not for instance if you call a function to get a path as a string.

If you still dont believe me or the C/C++ books you can easily verify the effect of the double slash in the MS debugger. Look at the memory occupied by the string with and without the double \ and you will see what happens.


So basically there is no need for 'Special Cases' for FaxMan, we require the same code as if you were calling a windows API function.

If you have questions please call me at 828-682-4111 x102 and I'll be glad to discuss these issues with you.

Hi Sean

As per the content of our phone call, I have now resolved this, but it was nothing to do with string constants, which I am more than well aware are different to pointers and how to handle such animals.

I don't believe I need to look at a book on "C" after 25 plus years writing many other applications in the language ;-)

Ian Turner