IronPython 2.7.1 Update

There are times where it’s hard for me to keep up with every software update out there, much as it’s hard for you. IronPython was a somewhat different product when I originally wrote Professional IronPython. One of the best changes has been the addition of support in Visual Studio for a variety of project types. You still can’t use designers to create your interface effectively, but things are moving in the right direction. I had downloaded the 2.7.1 version of IronPython nearly as soon as it became available, but a number of personal projects and other requirements got in the way of my testing it with the source code in Professional IronPython. The testing is finished and I haven’t encountered any major problems with the update. If someone does encounter a problem, let me know at

The update does include the usual bug fixes. You’ll want to peruse this list to see if the bug you reported has been fixed. As far as I was able to tell, none of these bugs directly affect the code in the book or any of the example code.

You do need to be aware of some important changes in this seemingly minor update. The biggest change is that you must have Silverlight 4 installed now to use IronPython Silverlight Web Page template (see the Python Tools for Visual Studio (PTVS) Released post for details). I decided to try everything with Silverlight 5 now that it’s available and didn’t encounter any problems. Consequently, you may simply want to update to Silverlight 5 to avoid potential problems later.

The older IronPython Tools for Visual Studio tool is completely deprecated at this point. You must use the newer Python Tools for Visual Studio (PTVS) with IronPython 2.7.1. Since this newer product offers a wealth of useful features, it’s an easy update to accommodate.

For me, the best news is that IronPython is able to work with more of the Python Standard Library. Chapter 6 of my book discusses how to perform this task. Table 6-1 (page 99) contains a list of standard library modules that are missing from IronPython. That list is getting progressively smaller. IronPython 2.7.1 now supports these additional Python Standard Library modules:


  • unicodedata
  • csv
  • ats

There is currently an IronPython 2.7.2 Alpha release available as well. This new release isn’t far enough along for me to test with the book’s code as of yet. However, if you do test it out and find that you have questions about the book code when using it, feel free to contact me. I’m always more than happy to help out with book-specific questions.


Examining the Calculator in Windows 7

Almost every book I write on programming has some element of application design in it. If you don’t create applications with a great design, users are less likely to use them. I examine general design issues in C# Design and Development. However, books like C++ All-In-One Desk Reference For Dummies, LINQ for Dummies, Professional IronPython, Start Here! Learn Microsoft Visual C# 2010 Programming, and Web Matrix Developer’s Guide all have design elements in them because I feel application design is extremely important. Even RibbonX for Dummies and VBA for Dummies have design discussions in them because they both talk about user interfaces. The most specialized book I’ve created about application design is Accessibility for Everybody: Understanding the Section 508 Accessibility Requirements, which discusses user interface requirements for those with special needs. All of these books have one thing in common, they all try to quantify what makes for good user design. They all ask the question, “How can you as a developer write an application that users will enjoy using and use efficiently?” Unfortunately, examples of poor design abound and seem to be more common as time goes on, which is the point of this post.

The Calculator application in Windows 7 is a perfect example of an application that has gone the wrong direction when it comes to the user interface. Sure, the Standard view is the same in both cases as shown here.

Calculator02 Calculator01

The Windows 95 version of Calculator is on the left and the Windows 7 version is on the right. As you can see, the buttons are the same, but someone at Microsoft felt obliged to rearrange them, just to make things difficult for anyone used to using the old version of Calculator. There isn’t a good reason for the change except to change for change’s sake. The Windows 7 version does have larger numbers, but at the expense of providing room for larger calculations. Personally, I’d prefer the Windows 95 version because sometimes I do need to perform really large calculations. Both versions of Calculator offer features such as digit grouping, so there isn’t any change here either. In short, Windows 7 offers less capability in a rearranged format that makes it hard for people who are used to the old version of Calculator to use it—breaking the rules of good design.

The problems get worse, unfortunately. I never used the Standard view of Calculator because I need to perform programmer math and scientific calculations relatively often. Switching to Scientific view in the Windows 95 version of Calculator, you see the perfect interface as shown here.


During the time I worked with Windows 95, I never switched out of this view. All I did was start Calculator whenever I needed it and did the math that I needed to do. Never once did the view I was in enter my mind. That’s great design! Users shouldn’t have to think about how your application works—the user’s only thought should be how to get work done.

The Windows 7 version of Calculator now has four modes: Standard, Scientific, Programmer, and Statistics. Every time I use Calculator now, I must first figure out what I want to do and change the view appropriately—wasting time and effort in the process. The views unnecessarily limit my options. For example, look at the Programmer view.


I do gain access to the RoL (rotate left) and RoR (rotate right) buttons, but I can’t think of when I’ll need them. The modern languages that most developers use don’t actually require these buttons. If I were using assembler, they could see some use, but I don’t remember ever using rotate left or rotate right with C#, Visual Basic (any version), Python, or even C++. So, these buttons are extraneous and only serve to complicate the interface. In addition, I do gain a bit display, which could prove helpful at some point, but I found that the Bin view on the old version of Calculator worked just fine and served my needs well. However, notice that the decimal point button is disabled. The loss of this button means that every time I have to perform any sort of math with a decimal point, I have to switch to another view. Programmers do use floating point numbers! So, a capable programmer calculator has been replaced with something less useful—something that makes me irritable and work harder.

Now let’s switch to Scientific view. Remember, I used to be able to do everything in one view. If I want to raise a value to a power now as part of checking application output, I have to switch to the Scientific view shown here.


As usual, someone felt that it was absolutely required to move the buttons around so that it takes a while to relearn how to use this view. For the most part, I don’t use any of the new features provided by this view. The few times I needed to use this feature with the old Calculator required a switch to Standard view, but the switches were seldom indeed. The Scientific view does include a number of additional features, all of which are likely helpful to someone, but the cost is one of having to switch views when you need to do something else.

Before someone writes to tell me that the new calculator has square root, cubed root, and root to any power buttons, the Windows 95 Calculator has these features as well. You just had to know how to use a calculator to understand them. Let’s say you want to find the cubed root of 27 using the Windows 95 Calculator. Simply type 27, check Inv, and click the x^3 button. You’ll see the cubed root answer of 3. Not convinced? OK, let’s try a quad root. Type 16, check Inv, and click the x^y button. Now, type 4 (the quad root) and press the = button. You’ll see the quad root of 16 is 2, which is the correct answer. The Windows 7 calculator adds nothing new in this regard—just more buttons to hunt and peck!

In short, the new Calculator is an example of a failed interface update. Most people will find that they have to constantly switch between views to get anything done. When you force people to think too much about the interface, they tend to get grumpy, less productive, and end up tossing out the application at some point. Personally, every since  I found the Windows 95 version of Calculator runs just fine on my Windows 7 system, I’ve been using it instead of the broken product Microsoft has offered. The Windows 95 version truly is the superior application. Let me know your thoughts on Calculator and on application design in general at


Python Tools for Visual Studio (PTVS) Released

As mentioned in my IronPython Finally Has Visual Studio Support post several months ago, there wasn’t much support for IronPython in Visual Studio when I wrote Professional IronPython. In the months since then, I’ve looked at the test version of this product in a number of posts that you can read in the Professional IronPython category. Microsoft has finally released PTVS to the public. You can now use this stable release for development projects without worry.

I downloaded and installed this latest version. The first thing I did was to try and load a few of the projects found in previous posts. For example, I loaded the example from the Using Generics with Classes post and it appears to work fine. I also tried out the debugging techniques found in the Debugging Using PTVS and Debugging Using PTVS (Part 2) posts and they appear to work as before.

As far as projects are concerned, you get the same projects as with the test version of the product. However, you’ll notice that there is now a separate entry in the list for Python-specific applications as shown here.


I tried creating a Windows Forms application and was disappointed to find that there is still no designer support. Of course, this means you still need to create your user interface using code and then test to see if it appear as you want it to. It would be nice if a future update (or perhaps a third party add-in) would make designer support available.

The one thing I noticed during my testing is that this version seems to work a bit faster. I didn’t perform any timed testing, but it seemed quicker and more responsive.

Future posts will look at the released version in more detail. If you’re already using the test version of PTVS, then you also know how to use the released version. It would be a good idea to update your copy, as needed, to ensure you have the latest bits. Be sure to write me about any questions or concerns about this release at


Using Generics with Classes

In the “Working with Generics” section of Professional IronPython (page 135), you find an example of using Generics with integer values. A reader recently tried to apply this example to working with a simple class and wasn’t able to get it to work (read the thread on for details). This post examines what you’d need to do to expand the original example to work with a simple class. I’m using a modified version of the reader’s code for explanation purposes. The example begins with this simple class.

# Define a simple class named Employee that contains a
# first name, last name, and age.
class Employee:
    FirstName = ''
    LastName = ''
    Age = 0

The class is contained in a separate file, As you can see, there is nothing special about this class. However, you could easily expand it as needed to accommodate your own code. Except for the comment, this code is precisely the same as that provided by the reader. (By the way, I encourage anyone sending me an example to add comments so I can understand your example with greater ease.)

Let’s look at the application. It essentially follows the same flow as the code in Listing 7-5 that starts on page 135. I’ve used the reader’s modification of that code for the most part, but added comments again for ease of understanding.

# Add the .NET Framework 4.0 to the path.
import sys
# Make CLR accessible.
import clr
# Import the required assemblies.
import System
import System.Collections.Generic
# Import the class you want to work with.
from FirstClass import Employee
# Create a list based on the class. Notice that
# you must create the list using an instance, not the
# class itself.
list = System.Collections.Generic.List[type(Employee())]()
# Define an instance of Employee and fill it with data.
# Add the instance to the list.
g1 = Employee()
g1.FirstName = 'A'
g1.LastName = 'B'
g1.Age = 35
# Define a second instance and add it to the list as well.
g2 = Employee()
g2.FirstName = 'C'
g2.LastName = 'D'
g2.Age = 5
# Enumerate the items in the list and display the individual
# members on screen.
for s in list:
    print s.FirstName, s.LastName, s.Age
# Pause after the debug session.
raw_input('\nPress any key to continue...')

As with the example in the book, you begin by adding the required path information for the version of the .NET Framework you want to use. The book example uses the .NET Framework 2.0, while this example uses the .NET Framework 4.0. The process is the same in both cases.

Because the example class appears in a separate file, you must import it into the application using the code that appears next. If the file had contained multiple classes, only the Employee class would be imported. You can also import the entire file if desired.

Now, here’s the important part. Notice that the example creates a generic List object, list, based on an instance of Employee. You must use an instance of the class so that you obtain the type of that instance using the type() method. Otherwise, what you’re really obtaining is a List object that’s meant to store classes, not instances of Employee.

So, now list is expecting instances of Employee. The example shows how to add two instances of Employee to list and provides each of them with different information. You could use the techniques in the original example to remove items as well. The point is that list now contains two items. The final bit of code enumerates these items and you see the output shown here:


Generic lists are extremely flexible, but you have to remember how IronPython works with data when using them. Always work with an instance of classes when creating a generic list. Let me know if you have any questions at


Debugging Using PTVS (Part 2)

I received a comment on yesterday’s post, Debugging Using PTVS, that I thought I should explore in a bit more detail than a simple answer to the comment would allow. I want to extend my thanks to Dino Viehland for making me aware of this particular issue.

The first thing you need to know is that the version of PTVS that comes with IronPython 2.7 is outdated. So, when you’re asked whether to install PTVS with IronPython 2.7, you want to clear the selection. Simply set the Tools for Visual Studio option shown below not to be available.


After you install IronPython 2.7, download and install PTVS from the CodePlex site instead. If you already have IronPython 2.7 installed with PTVS, I’ve found that the only way to truly get rid of the PTVS support is to uninstall it and start from scratch.

OK, on to the debugging part of this post. It turns out that you can change the debugging mode of PTVS by modifying the project properties. To perform this task, you choose Project > ProjectName Properties. If your Project Properties window looks like the one shown here, then you truly do have the old PTVS installed.


However, if you see this version:


you’re ready to go. Notice that the Debug tab has a Launch Mode field. This field controls how PTVS debugs your application. My initial post, Debugging Using PTVS, shows the IronPython (.NET) Launcher side of things. It turns out that you can change this setting to Standard Python Launcher, which significantly changes the behavior of the debugger.

The down side firstyou lose the ability to debug other .NET code. All you see when using this launcher is the Python world.

Now for the good part. My previous post showed how the call stack looks. It’s barely readable, but only if you squint a bit and think about it for a second or two. When working with the Standard Python Launcher, the call stack is significantly easier to read. Check it out:


In addition, you’ll find that the Immediate window is a bit more cooperative too. Remember that it wasn’t possible to type ? args[0] without generating an error in yesterday’s post. When working with the Standard Python Launcher you get the expected result as shown here:


In fact, you’ll find that debugging Python-specific code becomes easier when using the Standard Python Launcher. So, using the newer version of PTVS gives you some significant debugging flexibility that developers really need to create great IronPython applications. Let me know your thoughts on the updating debugging functionality at


Debugging Using PTVS

A reader recently wrote to ask about the debugging features provided by PTVS. In Chapter 12 of Professional IronPython you discover techniques for debugging your IronPython application. This chapter doesn’t include any information about PTVS because the product wasn’t available at the time of writing. However, the techniques described in the chapter work just fine in Visual Studio too. What PTVS does provide is some additional debugging functionality that isn’t available to IronPython developers normally and that’s the topic of this post.

This post begins with the example created in the Using the PTVS for a Windows Forms Project post so that you can easily follow along. Of course, the techniques I describe are useful for any application you might be working on at the moment.

One of the first things you should look at is the Output window. It shows you everything that IronPython is loading in order to run your application. This information can help you locate potential issues in running an application on a client system and help you create the appropriate installation support for your application as shown here.


As with any other Visual Studio application, you can set breakpoints for your IronPython application to stop execution at a particular point. To set a breakpoint you can click in the left margin. It’s also possible to right click a particular line, select the Breakpoint menu entry, and choose from the options on the menu. PTVS even provides full support for the usual assortment of conditional breakpoint offerings as shown here. (For the purposes of this post, I set a breakpoint on the MessageBox.Show(‘Hello!’) line of code.


When your application stops at a breakpoint, you have access to many, but not all of the Visual Studio features. So far I haven’t been able to get the Autos window to work. (If anyone has a trick to make it work, let me know.) The Locals window does work though and provides the full range of information you’d expect. Here’s an example of the information you’ll typically see.


Notice that you can drill down into the arguments as needed. It’s also possible to change values using the Locals window, just as you can with Visual Studio normally. Changes to many properties and variables work fine. However, you might not be able to count on this behavior for all value types. Visualizer support is there as well. At least, the Text, XML, and HTML visualizers seem to work. There may not be any support for custom visualizers.

The Call Stack window works much like it does for any Visual Studio application. Of course, the information is IronPython-specific as shown here.


One bothersome aspect is that the window doesn’t tell you the correct language. Instead, you see that the language is marked as Unknown. The debugger does get the line numbers correct and it’s easy enough to decipher the remaining information in this window. You’ll find that the Call Stack window correctly marks any arguments to methods for you.

The Immediate window only partially works. At least, I found it worked only partially for me. For example, if you type ? args and press Enter, you’ll find that the Immediate window correctly tells you that it’s a tuple containing two items. However, it appears to be impossible to access the elements within tuple. For example, if you type ? args[0] and press Enter, you’ll find that the Immediate window responds with an error message as shown here.


Making things a bit more difficult is the fact that you can type ? $function and press Enter to obtain the function-specific information and type ? $function.__name__ and press Enter to obtain the function name. In this case, everything works as expected. The debugging support provided by the Immediate window seems spotty. You may find yourself limited to performing certain tasks using it and then relying on the Locals window to perform other tasks.

There are other windows supported by the debugger that appear to work as you think they should. For example, you can set watches and view them using the Watch window, just like any other language that Visual Studio supports. The Breakpoints window also seems to work as it should.

This has been a whirlwind overview of the debugging features provided by PTVS to IronPython developers. Let me know if you have any specific questions at and I’ll do my best to research them.


Inheriting Someone Else’s Code

In my book, “C# Design and Development,” I propose a lot of management techniques that could apply to any language. In fact, I’ve used the techniques in this book successfully for years with Visual Basic, C#, IronPython, C++, and PHP, among many others. The idea behind the concepts in this book is to create code that performs well from the outset and is easy to maintain when changes are required. In today’s environment, you can count on changes at some point. There are many reasons to expect changes:


  • The business is bought by someone else and the code must be integrated into a new system.
  • A change in some other component necessitates a change in the application (such as the changes in Vista and Windows 7 security).
  • The business has grown and now needs new features to support its customers.
  • Modifications in the law mean changes to the way the application interacts with data.
  • Technology changes in such a way that the application no longer works properly.

In fact, the reasons for change are endless. I could probably continue writing reasons for change for hours and not cover even a small number of them. The point is that applications will change at some pointit’s simply a matter of time.

If you’ve written code for any time at all, you know that feeling in the pit of your stomach when you discover the perfectly lucid comments you wrote at the time you created the application are no long lucid now. Worse still, the documentation you put together doesn’t tell you what you did and why. Still, after a few hours of looking at your comments and documentation, you can usually begin to fit the pieces together of an application you created because you can recreate the thought patterns you had when you designed and wrote it in the first place.

However, what happens when you’re part of a team or you’re working on an application that someone else designed? Now there isn’t any way to “get back into the groove” of what you did in the past. The thought processes are foreign, so the comments and documentation have to be as comprehensive as possible. Even with great comments and documentation, it’s going to take a while to get up and running with the code.

The longer it takes you to recreate the ideas that went into creating the code, the longer the project update languishes and the more extreme management’s position becomes. The only thing that management knows is that your application (the one you inherited from someone else) is costing the business money. Not only is there a cost associated with the update, but the delay costs the organization money too. Users who have to fight with an outdated application are always unhappy and aren’t productive. So, what techniques can you use to become productive as quickly as possible? That’s what I’d like to know as well. Obviously, reading the documentation and comments are two pieces to the puzzle, but what other techniques do you use?

I’m currently putting an article together that discusses this topic in detail and I’d like to hear about your techniques. If you’ve ever been frustrated by someone else’s code, write me at I’ll let you know when the article is published on Software Quality Connection


Using the PTVS for a WPF Project

As with Silverlight, there is no mention of theWindows Presentation Foundation (WPF) in my book, “Professional IronPython.” The WPF is supposed to help solve some display problems for application developers and allow better use of modern graphics processors. Microsoft has provided a significant amount of information about the WPF that I won’t be discussing in this post. Whether you find WPF helpful or not depends on the kind of applications you create. I’m sure that WPF will find use in game applications, widgets of various sorts, mini-applications, and a host of other uses, but I’m not sure just what it adds to the common business application, such as a data entry application. Still, WPF is an exciting new technology that you should investigate.

As with the Silverlight project in my previous post, you need to have the PTVS installed on your system to work through this example. To begin this example,
you start Visual Studio as normal and choose File | New to create a new
project. The New Project dialog box should contain an entry for a Wpf Application template as shown here. If you don’t see
this template, then you probably don’t have IronPython 2.7 installed on
your system and can use the instructions found in the IronPython 2.7 and PTVS blog entry to install it.


The example will accept the default name for the project. Of course, you can use any name that you’d like. Click OK. You’ll see a new WPF application. However, for some odd reason, the eXtensible Application Markup Language (XAML) (pronounced zammel) file doesn’t always open, so you’ll have to open it manually. At this point, you’ll see a project similar to the one shown here.


The top half of the designer shows what the page will look like, while the bottom half shows the associated XML. As you add controls to the form and configure them, you’ll see the changes in the XML, making it easy to code changes to the controls when necessary. Of course, you can choose to display just the Design window or just the XAML window if desired. Depending on the amount of screen real estate at your disposal, collapsing one of the panes by clicking Collapse Pane at the right side of the window, may be a good idea.

One of the advantages of using WPF is that you have immediate access to the Ribbon without having to employ any odd programming techniques. You just drag and drop the Ribbon controls from the Toolbox as you would any other control. Here’s a subset of the default set of WPF controls you can access from IronPython.

As you can see, the set of controls is rich and you do have access to others, so WPF may be the way to go for IronPython developers who need maximum control access.

The example isn’t going to do anything fancy. I’ve added two Button controls to the form. Here is how I set the various properties using XAML:

   Title="WpfApplication1" Height="300" Width="300">
      <Button Content="Click Me"
              Click="btnMessage_Click" />
      <Button Content="Cancel"
              Click="btnCancel_Click" />

The first button displays a simple message box, while the second ends the application. Each Button control is assigned basic visual properties, a name, and an event handler for its Click() event. One thing I dislike about working with WPF is that the Properties window doesn’t display any quick help for the various properties. You need to know what each property does or look it up, which is really inconvenient.

The code behind for this example relatively simple. As previously mentioned, the first control displays a message, while the second closes the application as shown here:

import wpf
from System.Windows import Application, Window, MessageBox
class MyWindow(Window):
    def __init__(self):
        wpf.LoadComponent(self, 'WpfApplication1.xaml')
    def btnCancel_Click(self, sender, e):
        # End the application.
    def btnMessage_Click(self, sender, e):
        # Display the message on screen.
if __name__ == '__main__':

Much of this code is automatically generated for you. In order to use the MessageBox class, you must add it to the import statement as shown in the code. The code begins with the initialization, which simply loads the components from WpfApplication1.xaml.

The btnCancel_Click() event handler relies on the MyWindow object’s Close() method. Make sure you pass a copy of self as part of the call.

The btnMessage_Click() event handler makes a call to the MessageBox.Show() method with a simple text message. You’ll see the dialog box appear as expected.

From what I can see, the WPF support for IronPython in PTVS is on par with WPF support for any other .NET language. It has the same limitations and benefits as any WPF application will have. So, what do you think of the new WPF project support provided by PTVS? Let me know at


Using the PTVS for a Silverlight Project

My book, “Professional IronPython” doesn’t discuss how to work with technologies such as Silverlight, so I thought I’d see how hard it would be given that PTVS comes with support for a Silverlight project. This post adds to my previous post about PTVS. Of course, you’ll need to have PTVS installed on your system before you begin working with this example.

To begin this example, you start Visual Studio as normal and choose File | New to create a new project. The New Project dialog box should contain an entry for an IronPython Silverlight Web Page template as shown here. If you don’t see this template, then you probably don’t have IronPython 2.7 installed on your system and can use the instructions found in the IronPython 2.7 and PTVS blog entry to install it.


Give your application a name (the example uses the default of SilverlightPage1) and click OK. You’ll see a new project appear like the one shown here:


What I find interesting is that there is a designer provided for this template, but none provided for the Windows Forms application. I tried the Designer out and it works well. There isn’t any difference in creating a Silverlight application using this template than any other language I’ve tried. However, the list of controls you can access is limited. Here’s what the default Toolbox entries look like:


I tried adding a control to the list, just to see what would happen. When you open the Choose Toolbox Items dialog box, you’ll see that all of the normal controls are already selectedthey simply don’t appear in the Toolbox. I even tried checking a few controls on the Silverlight-specific tab without any result. So, my thought is that you’re limited to the controls show. If you know otherwise, please contact me at Even so, you can create a business application without any problem using the controls provided.

The Silverlight front end for your project uses HTML-like statements, as you might expect. You create linkage between the Web page and your IronPython code behind just as you would any other language. Here’s what the default sample code looks like:

<script type="text/python" src=""></script>

The code behind looks just like any other IronPython code you might have created in the past. Here’s the default example code:

def SayHello(s,e):
    window.Alert("Hello, World!") += SayHello

In short, you don’t have to worry about any odd programming techniques to make this example work. I was frankly surprised at just how nicely things do work with this template. There are a few oddities you’ll encounter. The first is that when you press F5 to start debugging your application, the IDE starts the Chiron development server, rather than the default. That’s not too odd, but it’s something you should know about.

The second is that the application doesn’t automatically appear in your browser. So, you’re waiting for something to happen and nothing does. Instead, you must right click the server entry in the Notification Area and choose Open in Web Browser from the context menu. At this point, I received a directory listing like the one shown here, rather than the application I expected.


Clicking SilverlightPage1.html did display the application. In fact, it displayed a lot more. I also received an IronPython Console I could use for debugging tasks, as shown here:


As shown in the figure, you can minimize the IronPython Console when not needed, so you can see your application better. Overall, I was very impressed with the Silverlight template offering and think it’s a great addition to the IronPython developer’s toolbox. Be sure to look for additional PTVS entries in my blog as time permits and to let me know your thoughts about it!

Using the PTVS for a Windows Forms Project

Chapter 8 of Professional IronPython demonstrates how to create a Windows Forms application using IronPython 2.6. As mentioned in my previous post about IronPython, IronPython 2.7 provides something new in the way of integration, PTVS. You’ve already discovered the means to create a console application using PTVS in my second post on this topic. This post goes a step further and demonstrates how to create a Windows Forms application using the same approach you’d normally use with any other .NET language, such as Visual Basic .NET or C#. I assume you already have PTVS installed on your system.

Of course, you begin by opening Visual Studio 2010 as normal. The New Project dialog box should contain a WinForms Application template in the IronPython folder. If you don’t see the correct template, then you probably don’t have IronPython 2.7 installed with Visual Studio 2010 (see my previous post for details). Call this project PythonApplication2 as shown here:


Click OK and Visual Studio creates the solution for you. The next step is to recreate the display shown in Listing 8-1 of the book. I had truly hoped that PTVS would provide Designer support, but it doesn’t. Here’s what you get as output from the template:


Now, it is disappointing that you don’t get a Designer, but the template does provide you with some helpful information and it’s better than what you started with in Chapter 8. The updated code is easier to read and requires that you perform less typing than shown in Figure 8-1. Here’s the new version of Listing 8-1.

import clr
from System.Windows.Forms import *
from System.Drawing import *
class MyForm(Form):
    def __init__(self):
        # Add a tooltip control.
        Tips = ToolTip()
        # Configure btnOK
        btnOK = Button()
        btnOK.Text = "&OK"
        btnOK.Location = Point(263, 13)
        Tips.SetToolTip(btnOK, 'Displays an interesting message.')
        # Configure btnCancel
        btnCancel = Button()
        btnCancel.Text = "&Cancel"
        btnCancel.Location = Point(263, 43)
        Tips.SetToolTip(btnCancel, 'Cancels the application.')
        # Configure lblMessage
        lblMessage = Label()
        lblMessage.Text = 'This is a sample label.'
        lblMessage.Location = Point(13, 13)
        lblMessage.Size = Size(120, 13)
        # Configure the form.
        self.ClientSize = Size(350, 200)
        self.Text = 'Simple Python Windows Forms Example'
        self.AcceptButton = btnOK
        self.CancelButton = btnCancel
        # Add the controls to the form.
form = MyForm()

This code works precisely the same as the code described in Listing 8-1. You still see the same dialog box as output as shown here:


It isn’t anything fancy, but the example does demonstrate that you can create a Windows Forms application using straightforward code and less typing than the example in Listing 8-1. Of course, this form requires event handlers, just like the ones used for the example in Chapter 8. Of course, you begin by creating the required linkage after you initialize the form as shown here:

# Add the event handler linkage.
btnOK.Click += btnOK_Click
btnCancel.Click += btnCancel_Click

After which, you add the event handler code shown here:

# Define the event handlers.
def btnOK_Click(*args):
    # Display a message showing we arrived.
def btnCancel_Click(*args):
    # Close the application.

At this point, you have the same first example shown in Chapter 8. Of course, Chapter 8 contains a number of other examples that demonstrate other techniques; all of which you can easily move to the new environment provided by PTVS. Here’s the source code for the entire example: So, what do you think of the new Windows Forms project support provided by PTVS? Let me know at