Typically when we write our code, the event handlers get wired up for us using the handles clause.  So we never have to worry about wiring up our event handlers manually.

But what about the case where we want to dynamically add a control to our Windows Form or our ASP.NET page?  For example, add a button.  How would you respond to the button click event?

In CSharp, there is no handles clause, so figuring out how to manually wire up the event handler is simply a matter of inspecting the dotNet code and doing a copy/paste/modify operation in the editor.

The syntax for adding event handlers manually is not that difficult.

1

AddHandler m_button.Click, AddressOf buttonClickMethod

If you’ve written any threading code, you’ll notice that this looks similar to the code you might have written for that.

The AddHandler statement takes two parameters.  The first is the event we are going to handle–in this case, the click event from the object that m_button is pointing to.

The second parameter is a pointer to a function that will handle the event.  What is unique about this is that it can be a method that is part of the current class, which is what the code above is referencing, or it can be a method in another object, or even a method that is shared in another class.

To reference a method in another object

1
2

AddHandler m_button.Click, _
    AddressOf SomeOtherObject.buttonClickMethod

To reference a shared method

1
2

AddHandler m_button.Click, _
    AddressOf SomeClass.buttonClickMethod

Which gives us quite a bit of flexibility when we dynamically wire up our events.

Before we get into the nitty gritty of parsing the HTML so that we can create PDF code from it, it is important that we develop the concept of how text layout works in iTextSharp.  So today we will cover those basics.

The first type of element we want to deal with when we parse our HTML into a PDF is the Paragraph element.

When we get to actually parsing our HTML to PDF code we will use the Paragraph object for all of our block elements.  This allows us to add other Paragraphs and Chunks into it which we can format.

A Chunk is our second object that we will be using.  The Chunk is the main object that will allow us to format the font.  In fact, even if our block element specifies some sort of specific font, the font doesn’t actually get applied in the code until we add the text.

Typical code to place text into a PDF document would look something like this

1
2
3
4

p = new Paragraph(new Chunk("text that needs a font",
    FontFactory.GetFont("Arial", 10, Font.NORMAL, Color.BLACK)));
p.Alignment = (Element.ALIGN_CENTER);
ct.AddElement(p);

where “ct” is an object of type ColumnText that we discussed last week.

The only other two classes we need to discuss are the list classes.  We use the List to create an item that will handle both the OL and UL tags.  The ListItem class will handle the individual items within the list.  The List constructor handles which of the two types of list we are dealing with by specifying true or false in the first parameter, numbered.

I have not yet added the ability to handle tables to my HTML parser mainly because I have not had the need.  I think once I show you how to create tables and how to parse HTML you should be able to handle adding table parsing code yourself.

The next series of things I’m going to introduce about using iTextSharp are all going to lead toward taking HTML text and placing it on the PDF document.

There are several items we need to cover before we even get to the part about converting the text from HTML to PDF text.  The first is placing the text on the document where it is supposed to be.

Once again, we are building on previous articles about using iTextSharp.  So if you are just jumping in, you might want to go take a look at the other articles.  You can find a list at the bottom of this post.

To place a block of text on the screen that is going to have multiple formats in it (bold, underline, etc) I use the ColumnText class.  This allows me to specify the rectangle or, if I want, some irregular shape, to place the text in.  I handle determining where this rectangle is on the page in the same way that I determine where an image should go.  I have the designer place a form field on the screen and then I use that to get my coordinates.

1
2
3
4
5
6
7
8
9
10
11
12
13
14

float[] fieldPosition = null;
fieldPosition =
    fields.GetFieldPositions("fieldNameInThePDF");
left = fieldPosition[1];
right = fieldPosition[3];
top = fieldPosition[4];
bottom = fieldPosition[2];
if (rotation == 90)
{
    left = fieldPosition[2];
    right = fieldPosition[4];
    top = pageSize.Right - fieldPosition[1];
    bottom = pageSize.Right - fieldPosition[3];
}

Once I have the position, the next thing I need to do is to create my ColumnText object.  This requires the same ContentByte object that we used for the images.

1
2

PdfContentByte over = stamp.GetOverContent(1);
ColumnText ct = new ColumnText(over);

And now I can set the rectangle to print into.

1
2

ct.SetSimpleColumn(left, bottom, right, top,
    15, Element.ALIGN_LEFT);

The 15 represents the leading you want (space between characters vertically). You may need to adjust that number.

Once you have your rectangle, you can add paragraphs to it.  Paragraphs are composed of smaller units called chunks that can be formatted.  If you want a paragraph that is all formatted the same you can make a call that looks like this.

1
2
3
4

Paragraph p = new Paragraph(
    new Chunk("Some Text here",
        FontFactory.GetFont(
          "Arial", 14, Font.BOLD, Color.RED)));

and then add the paragraph to your rectangle

1

ct.AddElement(p);

Last week I showed how to use form fields to control placement of dynamic data.

But what if you want to dynamically place images in your PDF?  You can stuff them into a form field like you can with text.

Read More

Chances are, you’ll eventually want to use a dialog box in combination with some form elements, and when you do, you’ll probably want to implement some validation.

True, there are some great validation routines available in jQuery, but they only validate on the client side.  They are, after all, Javascript.

Read More

When I first started generating PDFs dynamically, I was overwhelmed by the complexity of the API.  Not just with iTextSharp, but it seemed that all of the APIs were complex. In looking through the API and comparing it to what I was actually trying to accomplish, I found there was a very small subset of classes and methods that I needed to use to accomplish the task at hand.  Now that I’ve learned more, I still use this same subset of commands for 90% of what I need to do in iTextSharp. The reason we produce PDFs programmatically at all is because we need to dynamically generate some information on the page.  Most of the time, this information comes out of a database and gets placed on the same location of the page each time the page is generated.  The rest of the information is static. So what I normally do is have my designer or project manager create a PDF for me with form fields located where he wants the information to go.  Using the form fields, he can define the font, size, color, and position he wants to display the text with.  All I have to worry about is getting the text into the field. This works out nicely because once I’ve filled in the forms, he can move them around until he’s happy with them without asking for my help. We’ve already covered setting the MIME type information in our first post, so the rest of this discussion will assume you’ve already done that. The next thing you’ll want to do is load the PDF document that has the form fields in it and create a stamper object.  The stamper is what we use to grab the form fields object which we will use to set the form field values.

Read More

There are several libraries on the market now that allow you to create PDF documents from your .NET applications.  The one I’ve chosen to use is extSharp, an open source library that is a port of the open source library for Java,  iText.

While there are several sites on the Internet that provide examples of how to use iText, I’ve found that the documentation for iTextSharp is a little harder to come by.  So I thought it might be helpful if I provided some posts on how I use iTextSharp along with some of the gotchas I’ve encountered along the way.

Read More

On Monday, I was corrected in my assertion that creating multiple empty strings would create multiple objects.  Turns out the compiler automatically puts all of the strings that are exactly the same in a “string pool” so that there is only ever one empty string in the entire application you’ve created.

Read More

I recently read an article that argued that “” is “Better than String.Empty”

The argument is that since string.Empty doesn’t work in all situations, we should not use it at all.  He further argues that since the compiler can’t optimize code using string.Empty, the performance gains we might lose due to our lack of this optimization further supports the argument that we should not use it at all.

But at what price?

Read More

  I just read a post by Casademora on “public abstract string[]  Blog()”

Just say No! to C# Regions « public abstract string[] Blog()

and

I still say Regions are not useful… but…

Arguing that not only should we NOT use code regions, but if we do, we are hiding “bad code.”  He uses words like “retarded,” “lame excuse for a preprocessor tag,” etc.

Read More