Jim Karabatsos - GUI Computing
This is one of the most exciting new tools that I have had the pleasure to play with in recent memory. Those that have read my articles before will know that I am a big fan of the Delphi programming environment and that one of the reasons that I particularly like it is the fact that you can create your own custom controls. While there is certainly a little bit of learning involved, the learning curve is really not very steep, certainly nothing like the mastery of the black arts required to write OCX pardon me, ActiveX controls.
Apiary OCX Expert is finally out of beta and we are free to talk about it. It is an Add-On to the Delphi development environment that creates an OCX wrapper around a Delphi VCL component. Of course, you could do it all yourself manually; after all Delphi can call any API, so anything you can do with C++ you can do with Delphi. Trust me on this one, you do not want to do it yourself. It's hard.
When installed, a new project type appears in the File|New
Selecting OCX Expert and clicking OK will launch the expert and guide you through a series of screens that make creation of the OCX a snap.
The first thing you must do is point to the source file that contains the VCL component you want to convert to an OCX. Yes, that does mean that you need the source code in order to create the OCX. It's my policy to never use a control in Delphi if I don't have the source. I only wish VBX and OCX vendors would make source code available for licensing, as I hate that sinking feeling when a buggy VBX breaks your code and you are totally reliant on the control author to fix it for you.
You actually only need the first part of the control's source - up to the "implementation" key-word. Most controls come with this much source anyway, in the form of an ".INT" or interface file.
You are then presented with a list of all the control types that are defined in that source file. You can select one or more of these types to be exposed as OLE controls, by the OCX that will be generated. In the screen shot, the TDateButton is a contained control that I do not want exposed, so I have selected only the TDateEdit object.
The next thing you see is a screen that lets you change some of the default names generated by the expert. From this screen, you can go back to select additional VCL source files so you can add more controls into the one OCX. This is important as you will want to create OCXs that contain all your commonly-used controls bound together. This allows you to ensure that they all work together well, and also means that the overhead of including the Forms library in the OCX is spread amongst a number of controls.
|The second column actually contains the bitmap that will be used for your control when it is in the toolbox of a development environment - like VB4. Unfortunately, the OCX standard allows only 15x16 pixel bitmaps, whereas Delphi's VCL controls use 24x24 pixels. The expert "scales" the bitmap for you, but what it really does is mangle it <g>. Fortunately, double-clicking the bitmap brings up an integrated bitmap editor that allows you to fix it err touch it up <g>.|
When you're done selecting controls, you fill in the version and copyright information in a simple screen.
Then you select the output file location, press the Finish button and the Expert proceeds to create the source code to the OCX. After a status dialogue churns away for a few seconds, you are left in Delphi with the new project loaded.
The first file loaded is a simple text file which reports on the conversion process. The report lists all those properties that did not make it across the conversion. I will admit that when I first saw this my heart sank. It certainly seemed that a lot more had been rejected than accepted John West would have been proud. Closer investigation, however, reveals that the stuff rejected was all the low-level stuff from the very early ancestors in the VCL hierarchy. Most (if not all) of the properties and methods that you would normally think of as being associated with the controls do in fact make it through the conversion, in one form or another.
The DPR (project) file is for a DLL that exports the four functions that must be exported by all OCXs (refer to screen capture of 'DateEditorOCX.DPR' - 10Kb). A limitation in the Delphi expert interface currently prevents the expert from forcing Delphi to create the OCX with the right extension. You will need to manually rename the resultant .DLL file to the equivalent .OCX file. Not difficult, but it's a step that should be automatable but isn't - which just goes to show that not even Delphi is perfect <g>.
Here is the OCX in VB4/32, in design mode on the left, and at run time on the right with the date selection activated. Note that the calendar is actually a Delphi form that is shown modally when the date selection button is pressed. As you can see, you can create quite sophisticated controls using Delphi.
The guts of the OCX are in the associated PAS file (refer to snap). If you ever really wanted to understand how OCXs work, then you would be well advised to study this source code. It is far more transparent than the MFC-related stuff present in OCX source code, generated by Visual-C++. As you can see, there are no smoke or mirrors here. This is straight Delphi (Object Pascal) source code that works directly to the OLE API.
Is this a worthwhile tool? Absolutely. I very rarely give an unqualified thumbs-up to a tool, but this is one of the tools that you really should have. It's not perfect. Not all aspects of the ActiveX changes were available at release, so we are talking OCX Expert rather than ActiveX Expert. You can't create controls that relate to other controls (you couldn't easily create an Elastic control, for example). Bottom line, however, is that you can do enough - easily enough - that you need this tool.
Visit Apiary's web site at http://www.apiary.com for more information. Better yet, go ahead and order it from GUI Computing.