Foreword

Glad you made it!

Welcome to the wonderful world of Windows. If you are a former Clipper developer (like me) and you have made the decision to change your application development tool to Xbase++: "Congratulations!". Currently there is no other tool that allows such a smooth migration from Clipper as Xbase++. Your Clipper applications will be converted to real 32Bit-applications in no time and many of your current limitations as maximum string lengths, maximum array sizes and memory shortages will simply vanish.

After trimming your source code to make it fly through the Xbase++ compiler and maybe after adding some new features (e.g. mouse support) you will be faced with the ultimate challenge: Your application still looks DOSsy. I've heard lots of arguments about the perfect user interface and the self-proclaimed experts couldn't disagree more on what the "most effective" user interface should be like. But after you fail to sell your real 32Bit application because it looks like an old DOS application, you better start wondering what will your next step will be.

What's next?

I faced this decision at the end of 2002. Since Xbase++ comes with the Xbase Parts they appeared to be the logical choice for the task at hand. So I set myself the goal to create a production planning application showing orders to be produced in one panel on the screen and machines available in another panel. The assignment of the orders to the machines was supposed to happen using drag-and-drop. Of course, resizing and repositioning of all windows had to be possible. It didn't take me long to realize that my ultimate goal was unreachable using Xbase Parts. Apart from the fact that they don't provide the means to do this job (drag & drop) they behave oddly in the Windows environment: They flicker badly and their coordinate system is exactly the opposite of what you are used to from any other Windows application.

Some years before I had started to read Petzold's book "Programming Windows 95" because back then I thought about changing from Clipper to Visual Objects. Luckily I never made this transition and I aborted reading Petzold's book after Chapter 4. And although some years had passed I still had some of the Windows concepts and ideas in my mind when I started to analyze what the roots of my problems with Xbase Parts were. The first problem was nomenclature: Xbase++ uses its own names for standard Windows objects. A "Part" is essentially a "Window" and  a "Presentation Space" is (almost) a "Device Context". Then there are some additions like "Micro Presentation Spaces" (there's no Windows counterpart to that one) and there are "Callback Methods" in Xbase Parts that have absolutely nothing in common  with "Windows Callbacks".

And, to my astonishment, with pure Xbase++ you can't register window classes with the O/S which serve as blueprints for the window objects created from them by your application.

So I was lost. I had the Xbase Parts that wouldn't do the job I wanted them to do and I had no means to really create my own Xbase Parts from scratch or enhance the existing ones.

The Way to go

But Xbase++ had something else in stock for me: DllCalls. They were my gate to the other Windows world beyond the confinement of the Xbase Parts. They give you access to any O/S or 3rd. party Dll that doesn't require a special runtime system (as Dlls created with Xbase++ do). And all basic Windows O/S Dlls match this requirement. It was time for me to start over again with Petzold's book and check if his samples could be converted to Xbase++ and run in the Xbase++ environment. The source code of my first programs looked horrible and it took me quite some time to succeed in registering my first window class and callback function required to handle the O/S messages for my window. But after I had overcome this obstacle everything went smoothly: I could create dialog boxes from resources, I managed to convert Petzold's sample DDE server and client. These first attempts were 100% hand-crafted in every detail: Parameter conversions, structures, C functions that called back into Xbase++... I still wonder today, how I got some of the programs to work using this hop-in-and-try-to-fly approach.

Growing more and more accustomed with my new environment (and after buying the latest edition of Petzold's book) my view of the problems ahead of me changed: Calling the O/S functions wasn't the problem. But manually writing a wrapper for every O/S function available was absolutely out of question. And there were those other C and Windows beasts that needed taming: structures and callbacks. Hence I had to focus on:

And with such a foundation I would be able not only to import the functions in the Windows O/S Dlls but to do the same with all the functions in (almost) any other Dll.

Along the Way

I succeeded in completing all three tasks and "Cockpit" is the product resulting from my efforts. Its initial project name was "Winlib" and apart from the fact that this name is already in use for a similar product it also implies that it's a library based on and created for "Windows". This is correct at first glance but a closer look reveals that the core technologies are not bound to the O/S at all. So if Xbase++ will make it into the Linux world, Cockpit will easily come along.

Although my comments on the Xbase Parts may seem rather harsh sometimes, I can see their advantages and putting them into historic context even makes me understand their existence and design. They are well suited for basic programming requirements and help you develop simple programs easily. But they have some shortcomings I can't live with as I will show you in detail in the next chapters.

When I started developing Cockpit I decided I wouldn't spend any more time on Xbase Parts and their integration with the native windows provided by Cockpit. Later I saw it as a challenge and now Cockpit provides the means to merge both worlds. It even provides special functions to handle Xbase Parts like real windows.

A new Perspective

Having used Cockpit productively in real world and paid for projects and having read more books on Windows my view of things and the "programming world" I live in have broadened significantly. My feeling of being on the Xbase++ island has vanished and the Microsoft newsgroups have become regular daily stops for me just like the Alaska newsgroups: Cockpit hasn't just opened the door to more functions and techniques, it has widened my information horizon and has become an extensible foundation for all my future programming needs.

It's your Decision

It's up to you in which ways you'll employ the Cockpit system. You can import new O/S or 3rd. party functions to the Xbase++ world, you can use any non-UI function provided by Cockpit in your applications, you can completely switch to the native Windows GUI using Cockpit's wrapper classes for Windows' native and common controls. You can enhance the existing Xbase Parts and you can even create new Xbase Parts with a little help from Cockpit. However, you should be prepared for a different world when you embark on the non-Xbase-GUI adventure. There are lots of articles covering Win32 programming spread all over the Internet, but I have found nothing beating Petzold's book. It's a real whopper with almost 1500 pages but you will be set and ready for your own full blown Windows applications using dialog resources after the first section (with 12 chapters) spanning only about 500 pages. Give yourself a day or two per chapter and you will be through in two to three weeks. I've spent a lot of time converting his C samples to Xbase++, so you won't have to do that. After reading section 1 you'll see the Windows environment completely different and in a well organized manner. You'll know the terms, the Windows GUI architecture, the O/S objects, the subsystems and you will know how all that can be put to work for you. Then you'll be yearning for more: You're ready for the 1000 pages ahead of you. And Cockpit will be with you all the way.

My Vision of the Xbase++ Future with Cockpit

In my vision Cockpit is the foundation for a new generation of Xbase++ applications. Once you decide to not only use Cockpit as a collection of functions and objects to help you through your daily programming tasks but to actively extend the system, you'll see the complete picture: Cockpit is the platform for a new Xbase++ world. It supplies the means and techniques required to bring (almost) the complete Windows functionality to Xbase++ in a standardized manner. Using Cockpit's techniques you will be able to easily share your Xbase++ extensions with fellow developers. Unfortunately I've been given only one lifetime and the Windows world is far too huge to be brought to Xbase++ by one single being. But as a team we can do it. Hence we better get to work and really make Xbase++ fly.

So, once again, welcome to Cockpit. Buckle up and enjoy the trip. Only the sky's the limit.