The Cockpit Difference

Top  Previous  Next

Now that we've had a closer look at the ideas and concepts behind the Cockpit System, what do you gain by using it? To put it simple: You can write real Windows applications.

Your application will look and feel like a real Windows application.

I'm not saying that an application using Xbase Parts is not a Windows application. But there are many restrictions you cannot overcome using Xbase Parts. And very often standard functionality available from Windows' built in controls cannot be made available or must be completely rewritten for Xbase Parts. (Example: Tooltips)

You can use all the prefabricated controls that come with Windows or which are supplied by third party vendors right away.

Windows comes with a big bunch of "native controls" and "common controls". Furthermore there are the common dialogs and the ActiveX controls which cannot be used with the Xbase Parts without being adapted to the Xbase GUI system first. Unfortunately Xbase++ does not provide you with the means to do these adaptions yourself. A universal wrapper for ActiveX controls has been announced for one of the next versions of Xbase++ but how good it will be still remains to be seen. Unfortunately the Xbase GUI has a lot of the restrictions which will still apply to the ActiveX controls. There's another aspect to this new universal ActiveX wrapper part you should consider: You will use a wrapper to a wrapper to a wrapper of a standard windows control. You don't believe me? OK, let's take a look at the newly announced progress bar. At the core there is the Progress Bar Common Control. That was wrapped by Microsoft to an in-process COM server with its specific interface. To make things simpler (for Visual Basic), the interface was wrapped again and the IDispatch interface was implemented. This interface, once again, will be wrapped in the Xbase++ universal ActiveX wrapper part. Sounds like peeling a banana and finding another one inside. Of course it will work but I think there are better ways to spend your CPU power.

You can use 3rd party dialog designers and resource compilers.

The Windows architecture supports the creation of dialogs from resources. The separation of visual presentation from program logic or detailed customization allows you to design your input dialog windows completely independent from your Xbase++ code.  You can use any windows screen designer to create the resource script which can be linked and used from within your Xbase++ application. Even ActiveX controls can be used using this technique thanks to ATL, Microsoft's active template library.

 

Menus can be created as resources and they can be used from your Xbase++ code.

Mixing Windows created with Xbase++/Cockpit and ones created with C is a breeze

Yes, it's possible. You can create Windows with a windows procedure written in C and Xbase++/Cockpit Windows in the same application.

The number of information sources available to you drastically increases

You can buy books on Windows programming or post in the MS newsgroups if you have any questions about how to accomplish a task. This works because you live in the same "semantic name space" as your fellow programmers which use the Win32 Api from other languages like Pascal, plain C, etc.

You can use the complete Microsoft documentation if you want to know how things work. (Which does not mean that this documentation is better than Alaska's.)

You can use sample programs written in other languages

Once you have understood the native Windows way of doing things you will understand how other Windows programs work and you can adapt sample programs that you can find all over the Internet and in Windows books to Xbase++ and use them easily. You can even reuse the dialog resource scripts used in those examples without modifying them!

Human resources are more readily available to you

You can hire programmers which are used to Windows programming. All they have to learn is a new syntax. The way things work remain the same for them.

The OOP difference provided by Cockpit and Xbase++

Programming Windows with Xbase++ is real fun, because all the handle stuff can be replaced with objects exporting methods. That makes your code more readable and still you stick with the O/S semantics!

Semantics match

You'll work with windows, not Xbase parts, you will create real callback functions, not callback methods that are never called from Windows at all. You will place your child windows in the client area and your drawing will take place in a device context and not in a presentation space. Your dialogs will be real Windows dialogs and not a frame with an MDI client window. All naming ambiguities just vanish.  (Just think about the "Parent/Owner/Child"-problem popping up frequently in the Alaska newsgroups.)

Windows' built in functionality is at your fingertips and ready for reuse or modification

You can use standard Windows techniques like subclassing and super classing. Yes, you can create your own window classes which are partially based on existing classes provided by the O/S. You can generally modify the behaviour of a particular window class to suit your needs in your applications or you can choose just a single window for modification. Cockpit even provides you with the means to intercept calls between Windows dlls which allows you to further customize the behaviour of more complex controls like TreeViews and ListViews.

Your application becomes an active part of the Windows environment

Once you have created a main window (that might be invisible) your application becomes an active ingredient in the Windows environment:

 

Windows will send notifications about important changes to you.
You can register for special notifications informing you about changes affecting your program.
Windows can query your program for information it requires.
Windows gains control of your application threads and can initiate special calls to callback functions you can specify when certain tasks must be accomplished, e.g. the processing of data when it becomes available from the network.
Your application will be able to receive messages sent to it from other applications and return a value to the sender.