Resolved Using a winform to create a PDF using iText7

[LabProARW]

This is pushing me too close to the edge ":-( On FrmCreatePDF is a Btn_GeneratePDF. The code snippet below slightly modified from CodeGuru throws a "NULL REFERENCE Object reference not set to an instance of an object". The error is thrown on "document.Add(header);". So 'document' is a new object right? Also 'header' is a new Paragraph object right? So why does this code not work for me?

Thanks in advance.

        private void Btn_GeneratePDF_Click(object sender, EventArgs e)
        {
            String pdfDestination = "C:/users/rickw/source/repos/QC-Base/PDFs/example.pdf";
            PdfWriter myPDFwriter = new PdfWriter(pdfDestination);
            PdfDocument pdfDoc = new PdfDocument(myPDFwriter);
            Document document = new Document(pdfDoc);
            Paragraph header = new Paragraph("HEADER")
            .SetTextAlignment(TextAlignment.CENTER)
            .SetFontSize(20);
            document.Add(header);
            document.Close();
        }

 

[Skydiver]

The only true way to find out is to use your debugger. When the exception is thrown, use the debugger to see if document or if header is null.

 

[Skydiver]

Also 'header' is a new Paragraph object right?

Not necessarily. The full code for that line is:

Paragraph header = new Paragraph("HEADER").SetTextAlignment(TextAlignment.CENTER).SetFontSize(20);

By the fluent interfaces convention, SetFont() should return the this reference, but bugs and typos do happen. Someone could have goofed.

 

[LabProARW]

The only true way to find out is to use your debugger. When the exception is thrown, use the debugger to see if document or if header is null.

document is what is greyed indicating it was the document... but that doesn't stop the Null exception error.

 

[Skydiver]

I don't understand what you mean by "is what is grayed".

Please click on the exception details brought up by Visual Studio, and copy and paste the full callstack of the exception (as text, not a screenshot)

 

[LabProARW]

I don't understand what you mean by "is what is grayed".

Please click on the exception details brought up by Visual Studio, and copy and paste the full callstack of the exception (as text, not a screenshot)

The grey is the VS 2019 IDE chooses to highlight the word 'document'. Below is what a 'copy details' provides. I don't know how to paste the full callstack.. All I can do is take a screen shot of the details, which you do not want.

System.NullReferenceException
HResult=0x80004003
Message=Object reference not set to an instance of an object.
Source=itext.io
StackTrace:
at iText.IO.Font.FontCache..cctor()

Below is where the arrow was pointing on the Call Stack.
itext.io.dll!iText.IO.Font.FontCache.FontCache()

 

[JohnH]

VS Options > Debugging, General and check "Enable Just My Code" - and try running again.

 

[LabProARW]

VS Options > Debugging, General and check "Enable Just My Code" - and try running again.

I don't understand this but it does allow the code to run and looks to work. So what am I sacrificing to enable just my code, or why does this work to create the PDF?

 

[JohnH]

It is the default setting, see Debug user code with Just My Code - Visual Studio
In this case (when trying to debug non-user code) the line is highlighted green (explained in linked article), which means it is a first chance exception that is handled in the external library (which is common). The reason VS debugger stops here is because the CLR exception NullRefenceException is enabled to break when thrown in Exceptions settings.
It is in other words not a problem and you should use default setting to debug only your own user-code.

 

[Skydiver]

*sigh* So what was happening was that you had the setting in Visual Studio to stop on all exceptions -- even exceptions that maybe handled by the code that you are bringing in.

When you switched over to "Just My Code", the debugger will now ignore exceptions from other people's code, unless it is unhandled. Obviously, in the case above, the library you are bringing in can handle the exception.

In general, well written code will not use exceptions as a means of flow control, so this should be a non-issue. Exceptions should only be used for truly exceptional error conditions, not for errors that can handled.

Unfortunately, some code is not written with this philosophy. Instead they use exceptions to communicate errors. It looks like in the case above, and exception is being thrown to indicate that an internal data structure called "FontCache" don't could not be created.

 

[LabProARW]

*sigh* So what was happening was that you had the setting in Visual Studio to stop on all exceptions -- even exceptions that maybe handled by the code that you are bringing in.

When you switched over to "Just My Code", the debugger will now ignore exceptions from other people's code, unless it is unhandled. Obviously, in the case above, the library you are bringing in can handle the exception.

In general, well written code will not use exceptions as a means of flow control, so this should be a non-issue. Exceptions should only be used for truly exceptional error conditions, not for errors that can handled.

Unfortunately, some code is not written with this philosophy. Instead they use exceptions to communicate errors. It looks like in the case above, and exception is being thrown to indicate that an internal data structure called "FontCache" don't could not be created.

Thank you so much for a reasonable explanation! I will make a new post about positioning my elements on the PDF.

 

[Skydiver]

@Mo_Developer : It seems like you are just here to hawk your PDFFlow. Almost every post you have here has a spammy link to your product.

Anyway, please re-read the thread above. There was no exception to be fixed. The issue was that the user had his settings to catch all exceptions, not just uncaught exceptions. The other library that your product seems to be competing with uses exceptions to do some of its flow control and so it uses exceptions internally, but it handles the exception internally as well.