Last month’s article discussed the instantiation or creation of our objects in an application. These objects are usually developed using the native application tool that we do most of our development in. However, some development tools are better suited for certain functions while not as well adept at others. For example, Visual FoxPro is excellent at handling and managing database information. However, it’s native command set is not the fastest tool for managing and handling graphics and graphics objects. I ran into this problem recently when developing an updated version of my scheduling software. The scheduling software was being designed to manage appointment objects on a time based grid object. My goal was to display color-coded appointments for multiple people or objects simultaneously across a network. Visual FoxPro could manage the data access extremely quickly. It could query several hundred appointments from a schedule database file for a given day and person in about 0.2 seconds. The problem that I ran into was then painting those several hundred appointments onto the schedule form using native Visual FoxPro commands. To make my design easier to use I had created a graphical appointment object that could be used over and over as was discussed in my earlier articles. The problem was the internals of how Visual FoxPro managed its graphical drawing of objects in Windows.

The original solution I developed began with looping through the query results from the schedule for the selected date or dates and then instantiating an appointment object for each record and locating it onto the schedule grid. I quickly found that the object that was originally designed as a container object that had 4 objects contained within it. This design caused Visual FoxPro to slow down so badly that you could watch each appointment paint itself onto the screen after painting more than 60 or 70 appointment objects onto the screen. Approximately 150 man-hours was spent in designing and testing this original design only to find that it was not acceptable. After discussing the problems with technical support and finding out that there were no work arounds for the speed issue of drawing container objects, I began looking at another approach. This time I decided not to create an appointment object based upon a container object that contained multiple graphics object, but rather use a single graphical object to display the appointment. It wasn’t the desired look I had desired but provided adequate speed for the application. However, I was still not satisfied with the overall speed of the resulting scheduler application. I still wanted the appointments to scroll quicker in the time grid and be more responsive to user selection and such.

Another solution to the problem was to purchase a library of ActiveX controls that had been developed in C++ specifically to draw scheduling objects and appointment objects. This is where we get into the hosting of ActiveX controls in your development tool. Most of today’s software development tools such as Visual Basic, Delphi, C++ and others have the ability to host ActiveX controls within their forms or application object. The implementation and compatibility of hosting these objects though varies widely. Luckily after trying several different scheduling objects I found a product that worked and behaved fairly well within Visual FoxPro’s interface. The software objects were written in Visual C++ and were very compatible with Visual FoxPro since it is written in Visual C++ as well. The only bad thing about using ActiveX controls within an application is they usually have to be installed and registered in the registry before they can be used. Your software must copy DLL and OCX files onto the system in order to use the ActiveX controls in your application. This opens a can of worms with version issues between ActiveX controls being used by multiple software applications on the same machine. This is also the reason why installing a new software application can break existing installed software on your system. This is why one of the first questions a support technician will usually ask you is, "Did you install any new software on your PC?"

Now, that you’ve gotten your ActiveX control and want to use it in your application, you must instantiate it in code or add the object to your user interface development tool. Once the control is created in memory it can be used the same as your other custom objects that you had created earlier. You would set the properties and call the methods of the ActiveX object within your application just as any other native object. Sometimes however, there may be some issues such as those that I ran into when the ActiveX control has the same Method or Event name as a native Method or Event in your development tool. This is where you must check your development tools documentation as to how to call the ActiveX control’s Method verses your development language’s native method. Another problem with using 3^rd party software components is usually in the flexibility of the component as designed. If it doesn’t do something exactly the way you want it to you may have to wait months for the developers to create a new upgrade to the product to fix a problem or add another feature which you desire. Using this tool definitely improved the painting speed of my appointment scheduler but caused me some grief in working around object selection problems between the native Visual FoxPro objects and the ActiveX control such as menus and such. However, I did achieve pretty close to what I was looking for and the cost of the product paid for itself in the time it would have taken to write my own high speed graphics tools.