Hi Ingo!

Yes, you are right. The Function RenderDocumentToFile works very well. I have used it till now. But what I want is, displaying the page in a form (kind of a viewer) and I think it's not necessary to save the picture as a file on the hard disk and load it again into the RAM for displaying it. I will do this, if I won't find a better way. I think the functions RenderPageToStream, RenderPageToString and RenderPageToVariant are just made for what I'm trying to.

RenderPageToStream is only available in the Delphi edition. RenderPageToVariant sounds to me like something for visual basic (I'm not sure). So my favorite candidate is RenderPageToString to use.

As a trial I have saved a page as a BMP-file and than I have rendered the same page to a string. When I opened the BMP-file I saw the content. The string with the return value from RenderPageToString had the same content in the beginning. This already looked promising to me. But the string only showed five characters. First I thought, no more characters are displayed because of a debugger issue. But than I read the property Length of the string and I saw that also the length only is 5.

So something must be wrong with what I'm trying to do or the function does not work. If it would work I still have no idea how to convert a string with the bitmap content to an Image from a PictureBox.

Best regards,
Pirmin

Thank you chicks,

Perhaps I can modify the code from VBViewPDF to use it in C#. Maybe I still will try it this week. But I'm quite sure, that this wouldn't help me.

I have observed (using a HEX-Editor) that the position of the first zero in the BMP-file is the position where the string ends.
Zero in many programming languages is the string terminator. But in C# I have learned, 0 is not a string terminator. Only the property Length tells us, where the string ends.

It seems to me that the bitmap stream produced by RenderPageToString, might have been written correctly to the memory where the string points to.
But the property Length has been set to the position of the first 0 in the string instead of have beeing set to the correct length.

By the way, is it possible to view the memory of a string variable in C#? I could not find out how. If I could do that, I would see if my theory is correct.

When I use the string function ToCharArray, the resulting char array also only gets the size of the string length (5 in my example).

I think, without getting a string with the correct property Length, there is no way to convert it to an Image. Only when I succeed in doing this, I can go further, looking for a way to convert it.

So the next thing I will do is open a ticket at http://www.isedquickpdf.com - www.isedquickpdf.com asking if there could be an error in the function RenderPageToString.

Best regards,
Pirmin

Hi Michel_K17

You are right, my ticket is still open.

Unexpectedly I have found a part of a solution for my first problem (getting the length of the returned string from RenderPageToString).

Till now I have worked, using the DLL version. I thought, there must be something wrong. A DLL made for C++ can not make strings with a lenght information. Only the position of the string terminator (zero) is used to show where it ends.

With this in mind, I wanted to do my trials with the ActiveX library.
Still not started, I saw the Readme-file in the zip-file of the DLL Edition. There I found a sentence which makes me feel bad of not having read it before and makes me feel better about the correctness of the iSEDQuickPDF library.
The sentence is: "Use the StringResultLength function to determine the length of the data returned by the most recent function with a PChar result."

When I tried the function StringResultLength after RenderPageToString, it got exactly the same number as the size of the BMP-file produced with RenderDocumentToFile.

I see, I have to say RTFM to myself.

My first attempts afterwards let me assume that, when I want to access the string part after the zero, the garbage collector already has killed it.

So next week in my spare time, I must find out, how to get the entire data of the string.

Best regards,
Pirmin

Hi Folks,

Finally I found the solutions to my problems. Last night I couldn't sleep until I got it.

As I thought, the reason for the first problem was the assignement of one string type to a different one.

In the file iSQP0511DLLSource\DLLiSED.pas I saw, that the Delphi return type of the function iSEDRenderPageToString was PChar, which is only a pointer to characters with no length info.
In the file iSQP0511DotNet.cs, which is the DLL wrapper for .NET, the function iSEDRenderPageToString is imported from iSEDQuickPDF.dll as a string returning function and the wrapper function RenderPageToString calls iSEDRenderPageToString with the same parameters and returns the resulting string. Obviously the length info will be lost when the assignement from the pointer to the string is executed. The in this case used C# string constructor casts the pointer from the return value to a string, which only goes to the first contained zero. The original string with the proper length (I think) will be destroyed by the garbage collection.
My task was, to find a way to avoid this mechanism. Instead of importing and using the function iSEDRenderPageToString as a string returning function, I imported and used it as a pointer returning function, which it actually is.
To achieve this in C#, the function must use the "unsafe" statement and the wrapper library must be compiled with the /unsafe option.
So the file iSQP0511DotNet.cs has been patched the following way:
old import:
[DllImport("iSEDQuickPDF.dll")] static extern string iSEDRenderPageToString(int iDPI, int iPage, int iOptions);

new import:
[DllImport("iSEDQuickPDF.dll")] static extern sbyte* iSEDRenderPageToString(int iDPI, int iPage, int iOptions);

old implementation of the wrapper function:
public string RenderPageToString(int DPI, int Page, int Options)
{
    return iSEDRenderPageToString(DPI, Page, Options);
}

new implementation of the wrapper function:
public string RenderPageToString(int DPI, int Page, int Options)
{
    unsafe
    {
        return new System.String( iSEDRenderPageToString(DPI, Page, Options), 0, StringResultLength() );
    }
}

Using this patch, the function RenderPageToString does, what it is expected to do. The only drawback of my patch is, the library has to be compiled slightly different as described by iSED (using the option /unsafe). Maybe later on, I will try to the job better. For now the result is satisfactory to me.

The second problem (assigning the string to an Image object) was just finding the proper functions. Hints I have found in the file of which chicks posted the URL. Thanks!

To show the effects of the original iSEDQuickPDF 5.11 DLL wrapper for .NET and the patched one, you can write a C# console program (call it Test.cs) and put it to somewhere what I will call the working directory.
Test.cs should have the following content:
using System;
using System.IO;
using System.Text;
using System.Drawing;
using iSED = SEDTech.iSED;
class Test
{
    public static void Main()
    {
        iSED.QuickPDF qp = new iSED.QuickPDF();
        Console.Write( "iSEDQuickPDF version: " );
        Console.WriteLine( qp.LibraryVersion() );
        qp.UnlockKey( "your unlock key goes here" );
        Console.WriteLine( "Loading PDF file..." );
        qp.LoadFromFile( "Test.pdf" );
        Console.WriteLine( "Rendering page 1 to file..." );
        qp.RenderDocumentToFile(72, 1, 1, 0, "Page_%p_of_Test_A.bmp" );
        Console.WriteLine( "Rendering page 1 to string..." );
        string bitMapStr = qp.RenderPageToString( 72, 1, 0 );
        Image img = Image.FromStream( new MemoryStream( Encoding.Default.GetBytes( bitMapStr ) ) );
        Console.WriteLine( "Saving image from string..." );
        img.Save( "Page_1_of_Test_B.bmp", System.Drawing.Imaging.ImageFormat.Bmp );
        Console.WriteLine( "Finished!" );
    }
}

Don't forget to replace the parameter string for the function UnlockKey with your unlock key.

From the file iSQP0511DLL.zip extract iSEDQuickPDF.dll and iSQP0511DotNet.cs to your working directory. Rename iSQP0511DotNet.cs to iSQP0511DotNet0.cs and make a copy of it, named iSQP0511DotNet1.cs. To iSQP0511DotNet1.cs apply the patches described before.

Then create a batch file (you may call it build.cmd) in the working directory with the following content:
csc /out:iSED0.dll /t:library         iSQP0511DotNet0.cs
csc /out:iSED1.dll /t:library /unsafe iSQP0511DotNet1.cs
csc /out:Test0.exe /t:exe     /reference:iSED0.dll Test.cs
csc /out:Test1.exe /t:exe     /reference:iSED1.dll Test.cs

Execute build.cmd, which should create the two files Test0.exe and Test1.exe in the working directory.

Copy a PDF file you like to the working directory (don't use the "iSEDQuickPDF 5.11 Reference Guide.pdf") and rename it to Test.pdf.
Open a command line window and execute Test0.exe, see the results and then execute Test1.exe to compare with.

Test0.exe only will produce Page_1_of_Test_A.bmp (and some temporary files) and trows an exeption while Test1.exe will output Page_1_of_Test_A.bmp and Page_1_of_Test_B.bmp. If you compare the two BMP-files you see, they differ in a few bytes. I don't know why. When you open the two BMP-files with a Graphic Viewer, you won't see any difference.

As I indicated before, the file "iSEDQuickPDF 5.11 Reference Guide.pdf" causes problems. Page_1_of_Test_A.bmp produced from it, in a Graphik Viewer shows only a blank page, while Page_1_of_Test_B.bmp appears to be a good bitmap.
So the work is not over yet. But now I will concentrate on what I wanted to do one week ago, hoping all goes well.

Best regards,
Pirmin

Thank you Pirmin for your analysis and work..I found myself headed down the exact same trail, and then decided to check here before I jumped off the cliff...

For me to compile the wrapper, I needed one more necessary change in the dll import section...

old import:
[DllImport("iSEDQuickPDF.dll")] static extern string iSEDRenderPageToString(int iDPI, int iPage, int iOptions);

new import:
[DllImport("iSEDQuickPDF.dll")] unsafe static extern sbyte* iSEDRenderPageToString(int iDPI, int iPage, int iOptions);

Forgive me if I am wrong, but that is what I had to do to get it to compile.

I took the liberty of using Emacs and a macro to modify each and every call the returned a string as Pirmin has told us to do.

The newly modified wrapper is as follows:

----- CUT HERE -----

//======================================================================================
//iSEDQuickPDF 5.11
//DLL wrapper for .NET
//1 April 2005
//http://www.isedquickpdf.com/
//======================================================================================

Hi Frank

A happy new year and thank you for your post. I haven't seen it before, sorry.
I don't know, why my code compiled correctly without the additional unsafe and your code did not. Maybe it's a matter of a different .NET version?

In the last days I have been trying other iSED functions in the C# environment.
Unfortunately I have found, that the ones I need, all have awful errors.
For instance I can not even render the iSED manual (iSEDQuickPDF 5.11 Reference Guide.pdf) to a file. All pages appear blank.
Another error is, I can not render one  file and - without closing and restarting my software - render a second file. When I apply the same function calls to a second PDF document, the rendering result will be two times from the first PDF file.
Tonight or tomorrow, when I have time to examine the effects more precisely, I will post my experience in new topics.
Perhaps with all the changes you applied to the wrapper file, the library would become more stable.

I'm wondering if all my problems with the library for C# do not exist in the Delphi environment. Maybe for the Delphi environment the code has been tested more thoroughly.
If this is the case, I'm thinking about starting my work from scratch in the Delphi environment.

Best regards,
Pirmin

Primin,

If you cut and paste the wrapper code I posted, and compile it with your app, does it not work?

Since implementing the change you pointed out (BSTR instead of C# strings 0 terminated etc), the library seems to work wonderfully for me.   All the issues I was having have disappeared.

Of course if you use the ActiveX version of the library, you should have no issues either because the activeX version uses BSTR.

-Frank

Hi Frank,

I have tried your wrapper code.
For my first tests, it did not resolve my problems.
I have posted a new topic (Blank bitmaps from RenderDocumentToFile) because I think, this problem is the result of a different fault of the iSED library.
I've had more problems that I will describe soon (in new topics also).

Best regards,
Pirmin

I'm glad things are working for you Pirmin.

Since you pointed out the BSTR issue, and I modified the wrapper code to implement your suggestion, the library has been working beautifully for me.

-Frank