Problem

While recently working on a project involving VC++, I needed to print from inside a Windows dialog box. However, MFC and its wizards don’t provide printing facilities unless there is a Document/View framework in place. Since dialog boxes don’t subscribe to that concept, I needed to provide a standalone way of printing.

Design Considerations

The challenge was to produce a simple and flexible solution. These are some of the other design goals that my solution required:

• It needed to be self-contained — I should be able to drop it in anywhere that I wanted printing.
• By default, it should produce reasonable text output.
• At a minimum, only two statements should be needed: a definition of the printing facility, and a way to print a line of text.
• Heading and Footings should be possible.
• Resources needed to be minimized.
• It should be extensible.

The following were not major issues:

• Efficiency.
• Rich Text Processing.
• Print Preview.

In Listing #1, we start with a simple class SAPrint that is meant to be a base class. We then extend it using inheritance to include headers and footers.

Things to note in Listing #1 include:

• Use of the #define envelop to ensure only one copy of SAPrint.h will be included in any single translation unit.
• Use of enums to avoid namespace pollution caused by #defines
• Use of defaults in header file, not in the implementation file.
• Since SAPrint was intended as a base class, its data has been declared protected. It could have been made private and access functions defined, but the extra work was not deemed appropriate.
• Since SAPrint is a base class, most member functions of SAPrint were declared virtual.
• The member functions GetPageNoNext() and GetLineNoNext() compute the page and line number of the next line to be printed.
• The function Test was only used for testing. Under Release conditions, it is omitted.
• To preclude instances of SAPrint being copied or assigned, both copy constructor and assignment operator have been declared private and no implementation provided.

Listing #2 shows the implementation of the SAPrint class.

The following simple code prints a three line report:

Comments on Implementation

In the constructor:

• Since the constructor can fail for a number of reasons, a boolean data member, m_bConstructed is kept to ensure that other code does not execute if the constructor failed. Exception handling could have been used if it was guaranteed to be available. Note the use of gotos to keep the logic simple and to ensure there are no resource leaks.
• Care has to be taken that an EndPage() and EndDoc() are called if the corresponding StartDoc() and StartPage() were invoked, else the print system will be corrupted.
• The Test() member function is meant to exercise the class.

This class works and meets my original criteria. However, I am not too happy about the level of detail and explicit bookkeeping I needed to do. A better design might solve this weakness. Any feedback would be appreciated.

Our web site contains a more advanced version of this program with a derived class that handles headers and footers.

All the code here is covered by the Free Software Foundation’s LPL. Enjoy.

Recommended Reading:

• Programming Windows 5th Edition by Charles Petzold, Microsoft Press, ISBN 1-57231-995-X
• Professional MFC with Visual C++ 6 by Mike Blaszczak, WROX Press, ISBN 1-861000-15-4
• The C++ Programming Language—Special Edition by Bjarne Stroustrop, Addison-Wesley, ISBN 0-201-70073-5
• Effective C++ 2nd Ed by Scott Meyers, Addison-Wesley, ISBN 0-201-92488-9
• More Effective C++ by Scott Meyers, Addison-Wesley, ISBN 0-201-63371-X
• Thinking in C++ Second Edition Biik 1 by Bruce Eckel, Prentice Hall; ISBN: 0-139-79809-9 (This book is available for download at http://www.bruceeckel.com/ThinkingInCPP2e.html).

As you may already have surmised, I have included some code in this month’s main technical article. It started out to be a snippet, but grew much more than I had intended. Apart from the size, it is my bet that you have similar favorite code snippets that you have written in a variety of different languages. Each does a useful little task. We would be delighted to publish them and let others benefit from your skill. So send them along – which brings us to …

We finally made it. We are now online. All our past issues of ACCent are now available, along with code snippets, including this month’s, books reviews and the whole plethora of goodies that you have come to expect ;-). Historically, the hang-up has been getting credit card processing for those wishing to join the ACCU or renew their membership. But, regardless, you can now find us at:

Recently a program that have been running for years died. I went through the normal debug phase and discovered not one, but three errors. We all know programs like this and that every program is buggy to some extent. Thus, I asked myself the question: “How could a buggy program last so long? What tortuous paths allowed it to work, operating around the bugs?” I am working on rules to describe this situation. If you have developed an approach that works for you, please write and let me know.

Symbian

Next time someone mentions accessing the internet on a cell phone ask what OS the phone will be running. Windows, even CE seems an unlikely, Palm has a nice interface but no clear strategy for a phone OS, so what are Nokia, Ericsson, Motorola and Matsushita going to do?

Actually, it’s a trick question, all four own about 20% of Symbian. The final 20% is owed by Psion who has been producing PDAs since 1984 - before Apple invented the term PDA.

In 1997 Psion wrote a new 32 bit OS called EPOC which was first seen in the Series 5 machine and together with the developers formed the core of Symbian.

I’m typing this on the third EPOC machine a Revo (8Mb RAM, 33Mhz ARM processor, rechargeable batteries, and an IR port which can talk to a cell-phone for SMS, WAP, email or just surfing) but you can also get it on the Ericsson MC218 and by year end the R380 phone.

EPOC SDKs are available for C++ and Java. These use an emulator on NT and the GNU compiler. Some hackers have the SDK running on Linux.

Symbian have established 3 reference designs to subdivide the communicator market: Quartz (phones with some PDA features), Crystal (with keyboards and communications) and Pearl (palm style with communications). Most devices currently use ARM processors but the emulator runs on Intel and plans are afoot for other chips. Meanwhile, Nokia are working with Palm to put their interface on top of EPOC and a WAP emulator has just entered beta.

Gates, himself, singled Symbian out as one of the greatest threats to Microsoft. This is hardly surprising when Symbian's owners want 60+ million phones running EPOC by 2003 (www.businessweek.com November 1999).

● Symbian: www.symbian.com and www.symbiandevnet.com (SDKs, etc.)
● Psion USA: www.psionusa.com, www.go32.com,  www.revoworld.com 
● Professional Symbian Programming by Martin Tasker, Wrox Press, ISBN: 1-8610-0303-X.

Since we last reported two months ago, the rate of job openings in Silicon Valley and the country is shrinking in every case, but one. While over the last 13 months, demand for the major languages has grown, the rates of demand in the last 3 months has turned negative. This indicates that the demand for language programmers is decelerating.

Chart #1

The most notable trend is that the demand for XML expertise has now surpassed the demand for Java skills. Its rise in importance has been very fast, especially given the fact that it does not have a single major sponsor such as Java has with Sun. My conclusion is that part of XML’s success is its open source and standards. The second major factor is the industry’s deep and abiding desire for interoperability between hardware and software platforms and devices. With the Internet enabling everything, the need to exchange data with everything will continue to drive this demand. I also expect to see XML servers in the near future in the same way as I see ASP servers now. Please let me know your views on this.

Chart #2

The real surprise on the Platform front is the growth in demand for Windows 2000 expertise. It’s not that this interest is a surprise, but that the demand over the last 13 months is so great and that in the tightening job market, it has continued to grow, even while the rate of demand for all other platform skills has shrunken. Segueing into Win2K, I was recently surprised to see it installed on notebooks. Since Win2K looks so much like Windows 98, I was caught by surprise when I played with a notebook at Fry’s to discover how sluggish it was. It was then that I was told by a salesman that it was running Win2K, but in only 64MB. The lesson I learned is that Win2K needs at least 128MB to run comfortably. I can’t speak to its other issues since I don’t use it currently—but that may change if Microsoft gives me a copy ;-).

Chart #3

The other notable event is that the demand for Linux has continued to grow over the last 13 months and now exceeds demand for all other platforms, except Win2K. Again, with no single big corporate sponsor, the benefits and business model that Linux and the Open Source movement present are compelling and viable. (For more on this subject, see Eric Raymond’s The Cathedral and Bazaar, O’Reilly, ISBN 1-56592-724-9).

Chart #4