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

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

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

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

Thank you Pirmin for your analysis and work..I found myself headeddown the exact same trail, and then decided to check here before Ijumped 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 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

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