Beyond OOP : ActiveX and Distributed Objects

François Ghoche, ATON Consulting

Inprise Conference - Denver, CO - 11 Aug 1998
 

Building Visual dBASE ActiveX forms and components. The paper covers the Why and How of components for Visual dBASE developers. ActiveXs are covered in greater detail and the JazzAge ActiveX Factory is used to create ActiveX forms and components from Visual dBASE application modules. The version of MIDAS delivered with the client/server version of Visual dBASE version 7 is also covered.


 
  1. Introduction
  2. Components-Based Development is the new name of the game.

    So what happened to Object Oriented programming, which was supposed to be the beginning and the future of everything ?

    Well, OO is still there and will stay. However, it has not met all the expectations.

    While OO have brought tremendous changes to application development, it has not enabled easy interchange of objects between different development environments, or between different enterprise paradigms.

    This is where components come in.

    A component displays a standard interface to the outside world. It publishes and documents properties, methods and events. At the same time, it is "encapsulated" in a wrapper, which hides its internals to the outside world.

    So, a component can indeed be an object in the OO sense, but not necessarily so...

    As a matter of fact the code inside the component can be written in C++, Pascal, VB, or even ... Cobol. Thus, you can also build components out of Visual dBASE code. All you need is the knowledge of how to encapsulate it in the appropriate wrapper and follow the component model's specifications, as appropriate for the model you are developing for.

    Of course, a more straightforward way is to use a specialized tool to do all that wrapping work for you. We shall use the JazzAge ActiveX Factory -- Forms and Objects Edition version 1.7(http://www.jazzagesoft.com) as our friendly wizard for our journey into components.

    Visual dBASE version 7.x can use ActiveX components, but doesn’t provide for the possibility to create ActiveX out of Visual dBASE application modules. JazzAge will provide for a workshop to turn Visual dBASE forms into ActiveXs as well as handling the necessary management for those ActiveXs.

    But first, we shall go through some quick and short explanations and lay down the decor (2. Components – A (very) short historic background.).

    After that, several examples will be proposed to illustrate the various design possibilities we now have for our Visual dBASE applications (3. ActiveX components – So what... ).

    We will then summarize the advantages of using ActiveX components (4. ActiveX components – What for ).

    The next step will be to build an ActiveX out of an existing Visual dBASE form (5. ActiveX components – How).

    After going through this basic working example, the following section will propose to implement more advanced features in our ActiveX (6. ActiveX components – More ).

    A more theoretical section is included as a (summary) reference for ActiveXs ins and out (7. ActiveX components – What are they).

    The version of MIDAS included in the current shipping version of Visual dBASE 7 is then briefly covered (8. Components -- What about MIDAS ?).

    Finally you will find a short conclusion about what to expect next (9. Components -- What’s next).
     
     

  3. Components – A (very) short historic background
  4. Two standards are currently competing for the leadership : JavaBeans and ActiveXs.

    The JavaBean is the champion of the Java world lead by Sun, and backed by the followers of the CORBA standard specifications.

    The ActiveX is the Microsoft contender in the component arena. We are working on the Windows platform with Visual dBASE. The component model we use is Microsoft's Component Object Model (COM) on the desktop, and it’s extended version – DCOM (Distributed Component Object Model) – when components are spread over a network.

    To make a long story short, it all started sometime ago with DLLs. You know about the advantages of those dynamically loadable library modules, which can be used by one or more applications – provided you know about the name and syntax of their published functions, of course.

     

     

    VBXs brought a first answer by providing a standard interface to publish properties, events and methods of a DLL, and make it easier to integrate them into higher level languages and tools. But you probably know about that since the early days of Visual Basic and dBASE for Windows.

    Then, OCXs brought a new dimension by merging Object Linking and Embedding (OLE) into the component game. The .OCX file acts as a container component, where several ActiveX components and their resources can be compressed and stored.

    At this point, however, a component could be invoked and activated only if it resided on the same computer as the client application. This is where the Microsoft COM specification evolves into DCOM, enabling sharing components between different computers linked on a network.

    You can now have a client application on one computer, while the ActiveXs it calls is residing in a repository on another computer.

    By the way, the client application as well can be an ActiveX.

    Alright, this is enough for a start. We shall go through more extended theory in a specific section (see : 7. ActiveX components – What are they).

  5. ActiveX components – So what...
  6. Alright, so this is another "new technology" buzzword. I am a Visual dBASE developer. ActiveX, so what...

    How about going through some simple examples to illustrate the different ways we now can choose from to design and implement a Visual dBASE application.

    The examples are included in the code zip file which comes with this paper on the BorCon’98 CD. They are all based on the same Clients.dbf table and use a similar user interface. The code is kept to a minimum on purpose, so that the differences can be more easily understood.

    1. A "standard" standalone Visual dBASE form
    2.  

       

      This is a very simple Visual dBASE form indeed (check Clients.wfm, Clients.exe and Clients.prj in the code). It is a standalone SDI form that can be used to browse through the records of the clients.dbf table data. Remember that functionality has been kept to a minimum so that the difference in the coding can be more easily seen in the next steps.

    3. A web-based distant access to a Visual dBASE backend
    4. In this case, the Visual dBASE application is hosted on the same computer as a Web server. It communicates with the server via a CGI gateway. It generates HTML pages on the fly, which are sent back to the Web browser on the client computer.

      The user interface is the Web browser and its functionality is limited to what is offered by the HTML language – unless of course if you embed JavaScript or VBScript in the pages and the browser can execute the additional language. 

       

      This example has been generated using the Visual dBASE Web Tools (check the code in the VdBWeb directory). Functionality has been kept as close as possible to the standalone form example.

    5. Using a Visual dBASE ActiveX
      1. in a Visual dBASE form
      2. In this example, we use a Visual dBASE ActiveX – produced as detailed later in this paper – by simply dropping it on an empty new form in the Visual dBASE form designer.

         

        We instantly get a full-featured working application, as the functionality of the ActiveX is made available in the new form. Looks a lot like the screen shot for the first example ? No wonder, it’s the same one turned into an ActiveX... (check directory VdBCl and project JaClients.prj in the code – see section 5. ActiveX components – How)

      3. in another development tool
      4. In this example, the Visual dBASE ActiveX has been dropped on a new form in the Delphi Form Designer. Some more functionality has then been added.

        The example can be found in the Delphi directory. 

      5. in a web browser
     

    This HTML page can be found in the code (check JaVdBCli.htm in the Jage directory). It has been generated automatically by the JazzAge ActiveX Editor for test purposes when the JazzAge project was compiled (see : Testing the ActiveX in MS-Internet Explorer).

    At thia point, please note that the user interface functionality is not that of HTML. Rather, the example works the same as the two former examples and as the original Visual dBASE Clients.wfm standalone form.

    Note : It needs MS Internet Explore version 3 and up, or Netscape Navigator with the adequate ActiveX plug-in to operate.

  7. ActiveX components – What for
  8. 4.1 Basic ActiveX opportunities

    4.2 Additional advantages

    JazzAge also offers some features not available to most other ActiveX capable development tools :

  9. ActiveX components – How
  10. In this section, we will go through the development process to illustrate the effort needed and the result achieved. We shall use the standalone Visual dBASE form we have demonstrated as the basis for our example (see: ActiveX components – So what...) and turn it into an ActiveX form.

    5.1 Using the JazzAge ActiveX Editor

    The first step is to create a JazzAge project to handle the new ActiveX. The tool used for this purpose is the JazzAge ActiveX Editor, which will help us handle the whole ActiveX generation and deployment process.

    The steps involved in the creation of a JazzAge / Visual dBASE ActiveX are :

    The following paragraphs will walk you through the following : Now let us design the Visual dBASE ActiveX (name, properties, methods and events).

    Launch the JazzAge ActiveX Editor.

    Create a new project (use the menu : File / New), name it JaVdB for instance -- this is the name used in the examples and from which other filenames will be automatically derived. 

    Type in the DocString (the ActiveX will be identified by this DocString in the Visual dBASE Component Palette as well as in other container application where it would be used).

    Then type in the name and path of the Visual dBASE executable we shall produce later on, and check the "EXE 32" radio button as the implementation type . Note that at this point the Visual dBASE executable doesn’t necessarily exist yet. We shall create it in a later step.

    Create a new ActiveX in the project, assign it a name : JaVdBClients (and also a docstring, helpcontext...). 

     

    If we want to access properties methods and events of the future Visual dBASE ActiveX from the container client application, we need to define those properties, methods and events (see: 6.1.1. Back to the JazzAge ActiveX Editor).

    Note: If the purpose is to simply embed the ActiveX as a fully functional application in a container form – as done in the simple example we will first cover in JaVdBCl.prj – there is no need to surface properties, methods or events.

    Then we have to define a couple other attributes, namely the type of control (Simple Frame in our case) and the default size (in pixels).

     

     

    After the ActiveX definitions have been validated, by pushing the "OK" button in the lower left part of the screen, the specifications are checked and the "OK" button changes back to "New".

    Get back to the "Project" tab and save the JazzAge project from the File menu.

    We are now ready to compile the JazzAge project. To do that, select the "Commands" tab, check the box for a Win32 target ActiveX, and push the "Compile" button. 

     

    Compiling the project has also generated the following :


    Let’s leave aside the JazzAge Editor for a moment and let’s take care of the Visual dBASE part of the project.
     

    5.2 The Visual dBASE project

    5.2.1 Creating the project

    We are going to take the same form used for the Clients.exe form as used for the first example of a simple form application : Clients.wfm (see: 3. ActiveX components – So what...).

    Let’s first create a new Visual dBASE project (menu : File / New / Project) : 

     

    Then copy the Clients.wfm form from the standalone project directory into the new project directory we have just created. Clients.wfm is the form we have demonstrated for the standalone Visual dBASE application (ActiveX components – So what...). You will find in the directory of this project in the zip file of the code which comes with this paper.

    Rename the Clients.wfm file into JaVdBSvr.wfm in the Windows Explorer (the file name is not important -- this choice for a name just intends to point to the fact that we are revamping a Clients standalone form into a JazzAge Visual dBASE server form. Then, include the form into the Visual dBASE project by drag and drop from the Visual dBASE Navigator.

    We shall revamp this form into a remote ActiveX server form in a later step.

    Note : The complete directory and files for this project can be found in the code in the VdBAx directory.

    We now have to create a new form in the project : the Control Factory form.

     5.2.2 The Control Factory

    The Control Factory form will turn our Visual dBASE application into an ActiveX Form Server.

    We would need only one Control Factory form even if we had several Visual dBASE forms to transform into ActiveXs (in one given application).

     

     

     

     

    The sole role of the Control Factory form is to create and delete instances of the remote ActiveX Form, when requested by the client part of the ActiveX.

    The Control Factory form must contain the JaVdBClientsCF ActiveX, produced by the JA Editor when the project was compiled.

    From the Visual dBASE Project Explorer, launch the Visual dBASE Form Designer to create a new form.

    In the Visual dBASE Form Designer, you have first to set up the ActiveX previously created in the JazzAge ActiveX Editor -- as you would do with any newly installed ActiveX that you would like to use in the Form Designer. To do this use the File / Set Up ActiveX Components menu. 

    The DocStrings (descriptions) for the following three ActiveX must be found in the left pane – which contains all the ActiveX from the Windows registry – and selected to be moved to the right pane, which contains the ActiveXs which will appear in the Visual dBASE Form Designer Component Palette.

    Back in the Form Designer’s new form, select the Component Palette and the "ActiveX" tab. The CF ActiveX is identified by the DocString you had previously entered for it in the JazzAge ActiveX Editor, to which the string ‘CF’ has been appended. As a matter of fact, the DocString appears as a speedtip when you hold the mouse pointer on the ActiveX icon for a while.

    Drop the ‘CF’ ActiveX on the new form surface (this will be the only control appearing on the form). 

     

    The JaVdBClientsCF ActiveX exposes two events, to which the following code must be attached :

     

    function nativeObject_ONCREATECONTROL(ControlName, ControlHandle)
       ControlHandle := 0
       if UPPER(Controlname) == "JAVDBCLIENTS"
          form.oClientServerForm = NEW JaVdBSvrForm()
          form.oClientServerForm.Mdi = false
          form.oClientServerForm.Open()
          ControlHandle := form.oClientServerForm.ActiveX1.NativeObject.ActivateControl()
       endif
       this.WriteParameter(1, ControlHandle)
    return

    function nativeObject_ONUNLOADSERVER
       form.Close()
    return

    Note : Remember the ActiveX properties / events are accessed through its "NativeObject" in the Object Inspector.

    The JazzAge Object Engine fires OnCreateControl when it requires the creation of a new instance of  a Visual dBASE ActiveX Form, JaVdBClients in this case. OnCreateControl will thus take care of the remote server ActiveX instantiation when requested by the client ActiveX.

    OnUnloadServer is fired to notify the Visual dBASE application acting as a Form server that it should terminate. OnUnloadServer will be triggered when the application containing the client ActiveX is terminated.

    Some more code is needed in the header of the form :

    // make the RM server form class description available:
    Set procedure to L:\projects\javdb7\vdbax\javdbsvr.wfm additive

    This is the form we will revamp with the RemoteModule of the ActiveX (see : The revamped Clients form).

    // insure the form is always launched as SDI
    local f
    f = new javdbcfForm()
    f.mdi = false // ensure not MDI
    f.open()
    return
    ** END HEADER -- do not remove this line

    Note : You can also use the following code instead, which is shorter and more elegant (it was suggested by Ken Chan after all the slides were ready for the presentation...) :

    OpenForm( false )
    procedure OpenForm
    ** END HEADER -- do not remove this line

    Save the JaVdBCF form and, back in the Visual dBASE Project Explorer, make sure it is set as the main form in the project, as it has to be created as soon as the application is launched.

     5.2.3 The revamped Clients form

    We shall now turn the JaVdBSvr form (formerly the standalone Clients.wfm) into an ActiveX.

    Open it in the Form Designer and look for the JaVdBClientsRM ActiveX in the "ActiveX" tab of the Components Palette (it is identified by its DocString ending with a ‘RM’ string). Drop it on the form. 

     

    Using the Inspector, add the following method to the NativeObject’s OnDeactivateControl event :

    function nativeObject_ONDEACTIVATECONTROL
       form.Release()
    return
    Basically that’s all there is to do to use your new ActiveX !...

    Well, in fact some cleanup code can be useful to :

        function Open
          // hide ActiveX shape
          form.ActiveX1.Top := -300
          Super::Open()
        return

      Note : We shall leave this piece of code out at test time, because actually seeing things happening is a good way to see and understand the sequence of events.

    local f
    f = new javdbsvrForm()
    f.mdi = false // ensure not MDI
    f.Open()
    return
     
    Or :

    JaVdBSvr( false )
    Procedure JaVdBSvr
     

    To finish the ActiveX preparation, you now still have to save the form, get back to the Project Explorer, compile and build the executable JaVdBSvr.exe. 


    5.3 Testing the ActiveX

     5.3.1 Testing the ActiveX in MS-Internet Explorer

    Anxious to see what is the result of your hard work (well, not that hard, indeed) ?

    Easy : when the JazzAge project was compiled, an HTML test page was created by JazzAge : JaVdBCli.HTM. You will find it in the Jage directory. Just double-click that file in Windows Explorer (if you have a default browser declared), or else launch your web browser and open this page (remember the browser must be ActiveX-enabled).

    Et voilà ! Instant Visual dBASE ActiveX application in your Web browser. 

     

    What happened is that the ActiveX was automatically opened and the main form executed.

    Note : While your mind is travelling at the speed of light in all directions thinking about the wonderful possible applications you will build, just remember that for this simple example to work, Visual dBASE (or the virtual machine runtime) and the BDE must have been previously installed on the computer where the browser was launched...

    Here is the HTML code behind that page :

    html>
    <head><title>JazzAge HTML Test Page</title></head>
    <body>
    <p>JaVdBClients ActiveX</p>
    <p><object
    CLASSID="CLSID:4E0676E1-2245-11D2-A061-0080ADFFF984"
    CODEBASE="http:///javdb32.ocx"
    WIDTH="400"
    HEIGHT="300">
    </object></p>
    </body>
    </html>

    Check 6.3.4 Downloading a JazzAge ActiveX from a Web site for more info on this item.

    + 5.3.2 A client application

    Now that we have demonstrated we can use a "thin client" (a Web browser) to execute a Visual dBASE application, let’s get back to Visual dBASE and create a new project. We shall use our Visual dBASE / JazzAge JaVdBClients ActiveX in this application.

    Launch the Form Designer to create a new form. Drop a JaVdBClients ActiveX on the form.

    Note : This is the ActiveX we have originally described in the JazzAge ActiveX Editor. 

     

    That’s all there is to it. You now have a fully functional application, equivalent to the standalone Visual dBASE Clients.wfm (Clients.exe in the examples code), as well as to the web browser-based example we have covered in the previous section.

    Save, compile and test the new form. You can then produce a working executable out of it from the Visual dBASE Project Explorer. 

    Here is the complete code for this form. The code wouldn’t be different if the original form we have revamped into an ActiveX included much more functionality that made its own code several pages longer.

    ** END HEADER -- do not remove this line
    //
    // Generated on 28/07/1998
    //
    parameter bModal
    local f
    f = new JaVdBClForm()
    if (bModal)
    f.mdi = false // ensure not MDI
    f.readModal()
    else
    f.open()
    endif
     
    class JaVdBClForm of FORM
    with (this)
       scaleFontBold = false
       height = 16.0455
       left = 23
       top = 0.2727
       width = 61.4286
       text = ""
    endwith
     
    this.ACTIVEX1 = new ACTIVEX(this)
    with (this.ACTIVEX1)
       height = 13.6364
       left = 2
       top = 1.5
       width = 57.1429
       license = "JALIC"
       state = "BCBBBBBBBIBBBBBBPPDJBBBBKJCPBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBDFBBBBBBBLBBBBBBECBBECBBECBBECBBBBBBBDBBBBBBBBBBBDBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB"
       classId = "{4E0676E1-2245-11D2-A061-0080ADFFF984}"
    endwith
     
    endclass

     
      5.3.3 Using the Visual dBASE ActiveX in other development tools

    Using a Visual dBASE ActiveX in Delphi, VB or Powerbuilder is not much different than using it in Visual dBASE, as we have seen in the first section.

    You will find a Delphi example in the Delphi directory of the code zip file.

    This screen shot shows the work on the Visual dBASE ActiveX in the Delphi Form Designer.

     

     

    This is the final Delphi form at execution time.

     

     

    As you may see, in this example some of the properties which have been surfaced in the ActiveX are used in the Delphi code. 

  11. ActiveX components – More
  12. 6.1 Implementing access to internal functionalities

    In our example, we have considered the Visual dBASE JaVdBClients ActiveX as a complete application, where all the necessary functionality is implemented in the JaVdBSvr form.

    We have now to consider another case, where the ActiveX implements a specific set of functionality, which has to be surfaced to the client application, where these features will be used in the application processing logic.

    This could be the case for a business object (order form, invoice data capture, query module, Euro conversion module, etc.) or utility component (runtime toolbox, printer utility, communication tool, etc.).

    Another category can be more closely related to the database development nature of the Visual dBASE environment. One can thus design components including dictionary and business rules for a specific table or database, for instance.

    As a possible extension of this last domain, such components could be used to implement one-to-many DCOM components, for instance. In this case, the ActiveX components can reside on a server (where the ActiveX form server is executed) but the client application using the ActiveX can be on a different client computer.

    In this case, the remote part of the ActiveX execute on the server, where the BDE would handle the database processing. This would however require a substancial amount of coding, as we then have to surface on the server ActiveX side all the properties / events / methods which are needed at the client side to control the processing.

    What this mean is that every property, method or event of the server ActiveX -- whether from native Visual dBASE classes or of your own classes or sub-classes -- that you would need in the client ActiveX would have to be surfaced in the JazzAge ActiveX Editor. Then in the client ActiveX you would need to process the properties, methods and events of the server ActiveX instead of the original ones in your server-side Visual dBASE code.

    6.1.1 Back to the JazzAge ActiveX Editor

    Back to the JazzAge ActiveX Editor, load the JaVdB project, select the "ActiveXs" tab and then the "Properties" tab.

    For this example, we shall publish only a few properties, the purpose being to illustrate the task with minimal features and not to overload the code, which would make it less self-explanatory. 

     

    We shall thus publish properties related to the dataset, as used in the form (client number, client name, phone number, yearly sales) plus a Rowset class property : EndOfSet. 

    The Type is entered via a selection box.

    When finished, select the "Methods" tab. As an example for the methods, let us publish the First method of the Rowset class. 

    In the "Events" tab, type OnNavigate (we will publish the OnNavigate event of the Rowset class). 

    We won’t process any parameters in this simple example. 6.1.2 Surfacing the properties in the Visual dBASE code

    Back in Visual dBASE, open JaVdBSvr.wfm in the source Editor to add code to support the properties.

    To each <PropertyName> Property exposed by the ActiveX Form corresponds a pair of OnSet<PropertyName> and OnGet<PropertyName> events exposed by the JaVdBClientsRM ActiveX dropped in the Form.

    Supporting a Property is done by adding some code in methods linked to those OnSet and OnGet events :

    function nativeObject_OnGetcNom(Value)
    this.WriteParameter( 0, form.entryfieldNom1.Value)
    return
     
    function nativeObject_OnGetcNro_Client1(Value)
    this.WriteParameter( 0, form.entryfieldNro_Client1)
    return

    function nativeObject_OnGetcTelephone(Value)
    this.WriteParameter( 0, form.entryfieldTelephone1)
    return

    function nativeObject_OnGetnVentes_an(Value)
    this.WriteParameter( 0, form.entryfieldVentes_an1)
    return

    function nativeObject_OnGetlEndOfSet(Value)
    this.WriteParameter( 0, form.client1.rowset.EndOfSet)
    return

    function nativeObject_OnSetcNom(Value)
    form.entryfieldNom1.Value := Value
    return

    function nativeObject_OnSetcNro_Client1(Value)
    form.entryfieldNro_Client1 := Value
    return

    function nativeObject_OnSetcTelephone(Value)
    form.entryfieldTelephone1 := Value
    return

    function nativeObject_OnSetnVentes_an(Value)
    form.entryfieldVentes_an1 := Value
    return

    function nativeObject_OnSetlEndOfSet(Value)
    //form.lEndOfSet := Value
    return

    Note : For an explanation of the method WriteParameter see : Creating the Property Page Form.

    To each property exposed by a Visual dBASE ActiveX Form should correspond a private member. We may have to initialize some variables/properties to handle that as soon as the form is created, if they cannot be linked directly to actuel for; properties. The most adequate place probably is overloading the Open method of the form.

    function Open
       // initialize local variables/properties
       // corresponding to ActiveX properties
       this.lEndOfSet = false
       Super::Open()
    return
     

    Next, we have to add code to support methods. To each <MethodName> Method exposed by the ActiveX Form corresponds an On<MethodName> event exposed by the JaVdBClientsRM ActiveX dropped in the Form.

    Supporting a Method is done by adding some code to those On<Method> event. We have surfaced only one method in our example :

    function nativeObject_OnFirst
    form.rowset.First()
    return
     

    To each <EventName> Event exposed by a JaVdBClients ActiveX Form corresponds a Fire<EventName> method exposed by its JaVdBClientsRM ActiveX. All it takes to fire an event from within a JazzAge / Visual dBASE ActiveX Form is therefore to invoke such a Fire<EventName> method :

    function rowset_onNavigate(type, nRows)
    this.parent.parent.ActiveX1.nativeobject.FireOnNavigate()
    return
     

    Finally, save the form, and back in the Project Explorer compile and build the Visual dBASE executable.



    6.2 Property pages

    When you are implementing an unknown ActiveX in an application, it can be difficult to understand and test the behavior of the component. Property pages are intended to address this need.

    Providing the host development tool implements this feature of the ActiveX specs, the developer of the ActiveX can provide an additional component embedded in the OCX to provide for a dialog box to manipulate the properties of the ActiveX at design time.

    6.2.1 Modifying the JazzAge project

    To illustrate this feature, save the ActiveX properties you were editing (push the "OK" button) and go to the "Property Pages" tab at the Project level.

    Enter the following data : 

    JazzAge will automatically generate the property page ActiveX when the project is compiled.

    The next step is to assign the property page to the ActiveX. To do that, select the "ActiveX" tab and then the "Property pages" tab for the ActiveX. Drag and drop the JaVdBClientsPP property page from the left pane to the right pane (holding down both the [Ctrl] key and the left mouse button). 

    Now you can save the ActiveX properties you were editing (push the "OK" button) and get back to the "Project" tab. When in the Project tab, first save the project and then select the "Commands" tab and push the "Compile" button to re-compile the project, taking into account the new items.

    JazzAge has re-generated and registered the same items as the previous time – updated with the included properties, methods and events – but with an additional one : a JaVdBClientsPP ActiveX – the property page ActiveX – which has also automatically been registered in the Windows registry.

     6.2.2 Creating the Property Page Form

    Back to Visual dBASE, open the JaVdB.prj project and add a new form : the JaVdBPP.wfm property page form for our ActiveX.

    From the Components Palette, drop a JaVdBClientsPPRM ActiveX on the form, after you have added it from the menu File / Set up ActiveX component. The JazzAge ActiveX Editor according to our specifications has just generated this ActiveX.

    The next step is to drop a few couples of Text / Entryfield controls on the form, one for each of the properties we have published for the JaVdBClients ActiveX in the JazzAge ActiveX Editor. 

     

    Now, let’s create some methods attached to the ActiveX’s NativeObject events. It exposes the same OnDeactivateControl event, plus a few additional property page specific events: OnSetObject, OnApply, and OnIsPageDirty

    function nativeObject_ONDEACTIVATECONTROL
    form.Release()
    return

    OnSetObject is fired by the JazzAge Engine to connect the Property Page Form to the ActiveX to be edited. OnSetObject gives the Form a chance to reflect the edited ActiveX state into its user interface.

    function nativeObject_ONSETOBJECT
    // Assigning the property page activeX properties
    // to the entryfields
    form.ecNro_Client.Value = this.GetProperty("cNro_Client")
    form.ecNom.Value = this.GetProperty("cNom")
    form.ecTelephone.Value = this.GetProperty("cTelephone")
    form.enVentes_an.Value = this.GetProperty("nVentes_an")
    form.checkblEndOfSet.Value = this.GetProperty("lEndOfSet")
    return

    OnApply is fired to have the Property Page transfer the content of its user interface back to the edited ActiveX, and reflect the changes made by the user.

    function nativeObject_ONAPPLY
    // updating the content of the entryfields to the
    // activeX properties
    this.SetProperty("cNro_Client", form.ecNro_Client.Value)
    this.SetProperty("cNom", form.ecNom.Value)
    this.SetProperty("cTelephone", form.ecTelephone.Value)
    this.SetProperty("nVentes_an", form.enVentes_an.Value)
    this.SetProperty("lEndOfSet", form.checkblEndOfSet.Value)
    return

    The JazzAge Object Engine fires OnIsPageDirty when it needs to know whether changes have been made to the ActiveX reflected in a Property Page.

    function nativeObject_ONISPAGEDIRTY(bDirty)
    this.WriteParameter(0,1)
    return

    Since VdB7 does not handle 'out' ActiveX event parameters, a JazzAge ActiveX exposes a special method, WriteParameter, used to assign a value to a returned event parameter. In this case, WriteParameter is used to forward JazzAge the handle of the newly created ActiveX form.

    The  JaVdBClientsPPRM ActiveX produced by JazzAge exposes a couple of standard methods (SetProperty, GetProperty) used to retrieve or set the properties of the ActiveX control currently being edited in the Property Page.

    6.2.3 Extending the Control Factory Form

    The Control Factory Form added to the Visual dBASE application to extend it as an ActiveX Form Server will be invoked by the JazzAge Object Engine when a new Property Page instance is required, based on its name (JaVdBClientsPP in this case).

    The OnCreateControl event must be added the code to create JaVdBClientsPP instances :

    function nativeObject_ONCREATECONTROL(ControlName, ControlHandle)
    ControlHandle := 0

    if UPPER(Controlname) == "JAVDBCLIENTS"
       form.oClientServerForm = NEW JaVdBSvrForm()
       form.oClientServerForm.Mdi = false
       form.oClientServerForm.Open()
       ControlHandle := form.oClientServerForm.ActiveX1.NativeObject.ActivateControl()
    endif

    if UPPER(Controlname) == "JAVDBCLIENTSPP"
       form.oPropertyPageForm = NEW JaVdBPPForm()
       form.oPropertyPageForm.Mdi = false
       form.oPropertyPageForm.Open()
       ControlHandle := form.oPropertyPageForm.OJAVDB7CLIENTSPP.NativeObject.ActivateControl()
    endif

    this.WriteParameter(1, ControlHandle)
    return

    As you can see, creating Property Page instances is similar to creating ActiveX Form instances.

    Note : Of course, you can also use an ELSEIF instead of the second IF structure.

    6.2.4 Usage

    The next time you drop a JaVdBClients ActiveX on a form in the Form Designer, right-click on the shape of the component on the form. Just select the "ActiveX Properties" menu choice to launch the Property Page form.

     

     

    The Property Page form will be embedded and deployed in the same OCX as the other ActiveXs of the project.


    6.3 Deployment

    6.3.1 Embedding and getting ready to ship

    Once you are satisfied with your Visual dBASE ActiveX, re-launch the JazzAge ActiveX Editor to embed the Visual dBASE Form Server executable and build the final, standalone, self-installable/uninstallable OCX.

    An embedded JA OCX file contains, among others, the compressed Visual dBASE ActiveX Form Server. 

      6.3.2 Web deploying a JazzAge ActiveX

    Once tested and validated, a JazzAge / Visual dBASE ActiveX can be uploaded to a Web site acting as an object store. The URL of the web site where to deploy the component can be assigned to a project within the JazzAge Editor : 

     

    Any Internet enabled tool can achieve web deploying for an ActiveX. However, this can also be done using the JazzAge ActiveX Editor :

     

     

    You can also embed additional files in the OCX, which will be uncompressed and extracted automatically when the OCX file is installed in the target system.

     

     

    Note : You cannot control the installation directory. The files will be copied to the default download directory for the ActiveX on each specific computer. Don’t throw away your copy of InstallShield as yet !

     6.3.3 Installing/uninstalling a JazzAge ActiveX on a client machine

    JazzAge produces standard, self-installable/uninstallable OCX files.

    When a JazzAge OCX file is installed on a client site, the JazzAge Object Engine (runtime DLL) automatically extracts and decompresses the files (Visual dBASE ActiveX Form EE server, among others) in the current directory, and updates the Windows registry.

    When a JazzAge OCX is uninstalled,  the JazzAge Object Engine cleans up the registry and automatically deletes the previously extracted files.

    A JazzAge OCX file requires the presence of the JAX runtime DLL (220 Kb) on a site to operate properly.

    6.3.4 Downloading a JazzAge ActiveX from a Web site

    A JazzAge OCX deployed on a web site can be automatically downloaded by Internet Explorer when it loads a page containing a reference to it :

     

     

    We have already covered the HTML test page in the examples at the beginning of this paper (see : 3. ActiveX components – So what...)

     

    6.4 Additional features


    6.4.1 Licensing
     

    A licensed ActiveX distinguishes between situations where it is being used in designing a consuming application versus being used in running a consuming application.

    At design time, an ActiveX can require the presence of a particular license key file before allowing its host development environment to instantiate it in a designed form. By verifying the existence of the license key file, the ActiveX recognizes that the machine has a valid license for it.

    When the consuming application is compiled and stored to disk as an executable, the development environment requests a key from each licensed ActiveX it contains and bundles it in the produced executable file.

    At runtime, the bundled key is presented to the licensed ActiveX when instantiated, unlocking its capabilities, without searching for a license key file.

    JazzAge offers a very simple way of following this licensing protocol, by the means of a set of three events fired by the JazzAge Object Engine, and to which the licensed ActiveX must respond.

    To implement licensing, you have to check the appropriate box in the JazzAge ActiveX Editor :

     

     

    In the Visual dBASE part of the project, support for licensing must be added to the Control Factory code.

    The Control Factory ActiveX exposes 3 events fired by the JazzAge Object Engine to support licensing : ONGETLICINFO, . ONREQUESTLICKEY and ONCHECKLICKEY.

    ONGETLICINFO returns information about the state of licensing for the ActiveX which class name in passed in the ControlName parameter.

    function nativeObject_ONGETLICINFO(ControlName, RuntimeKeyAvail,
    LicVerified)
    // Return a value of 1 in the RuntimeKeyAvail parameter
    // which zero based index is 1.
    this.WriteParameter(1,1)
    // Return a value of 1 in the LicVerified parameter
    // which zero based index is 2.
    this.WriteParameter(2,1)
    return

    ONREQUESTLICKEY is fired when the host development tool requires a license key to be bundled in the compiled consuming application. ControlName contains the class name of the ActiveX which license key is required.

    function nativeObject_ONREQUESTLICKEY(ControlName, LicKey)
    // Return a string license key in the LicKey parameter,
    // which zero based index is 1.
    this.WriteParameter(1,"JAVDB7ActiveX1LicKey")
    return

    ONCHECKLICKEY is fired when a consuming application attempts to check a previously bundled license key before being allowed to instantiate an ActiveX corresponding to the key. ControlName contains the name of the ActiveX class, and Lickey the license key to be checked.

    function nativeObject_ONCHECKLICKEY(ControlName, LicKey, bChecked)
    // ONCHECKLICKEY should return a null value by default in
    // the bChecked parameter, which zero based index is 2.
    this.WriteParameter(2,0)
    if (ControlName=="JAVDB7ActiveX1")
    if (LicKey =="JAVDB7ActiveX1LicKey ")
    this.WriteParameter(2,1)
    endif
    endif
    return

    NOTE : ONGETLICINFO, ONREQUESTLICKEY and ONCHECKLICKEY are only fired for ActiveX which ‘Licensing’ attribute has been set at design time.

    6.4.2 Code signing an embedded ActiveX

    Once embedded, an ActiveX can be code signed, using digital IDs such as those provided by Verisign. Code signing an ActiveX can be done using the JazzAge Editor:

    A code signed ActiveX will be checked by Internet Explorer when downloaded from a Web site, displaying a credential like :

     

     

    6.4.3 DCOM Deployment

    To be invoked and manipulated remotely from a client site, a DCOM server must have registered itself, including its URL, in the registry of the client site.

    Redeploying a DCOM server therefore implies a registry update on each client site, which can be difficult and painful.

    The local/remote parts architecture of the ActiveXs which can be created with JazzAge offers a much simpler way of deploying DCOM servers.

    All it takes to modify the location of a DCOM server is to go back to the JazzAge Editor, reload the project, modify its DCOM URL entry, increment the project version and regenerate the project OCX.
     
     

    The .INF file, created when the project is compiled for each control, reflects the new version request. The HTML page referring to the updated Controls do not have to be modified. All the modifications mentioned below can be done locally, on the development/deployment site.

    The next time the HTML page is referred, the Web browser will compare the ActiveX version required by the HTML page to the version of the component previously downloaded to the local site. Since the versions don't match anymore, a new component download occurs, bringing the new DCOM URL to the local site. 

     

     



    6.5 Advanced DCOM Controls
     

    You can build advanced DCOM controls, exposing their properties/methods/events over a network,  and COM/DCOM Many-to-1 servers, that is servers creating object instances to which any number of clients can connect, either locally or remotely, over a network.

    6.5.1 Architecture of the JazzAge ActiveXs: Local and Remote parts

    The JazzAge ActiveXs are both Controls and Objects supporting DCOM. They can be instantiated and manipulated remotely, over a network. But what does it mean for an ActiveX Control to be remote?

    A JazzAge ActiveX is in fact made of two internal parts: a local part and a remote one. When an ActiveX container creates a JazzAge ActiveX, it deals with its local part, while the remote one stays in the form transformed by JazzAge in an ActiveX. The two local and remote parts are fully and transparently managed by the JazzAge Object Engine, a client ActiveX will never have to deal with them. 

     
     

    When the container invokes a method of the JazzAge ActiveX it contains, the method invocation is received by the local part of the ActiveX, and then forwarded to its remote counterpart, where it is turned into an event handled by the revamped form.

    Most of the time, the remote part of a JazzAge ActiveX is inserted inside its local fellow area and both appear as a block to their container. 

     


    6.5.2 DCOM Controls

    JazzAge offers to some of its ActiveXs (the invisible at runtime ones) the possibility of having the local and remote part of a control run on separate machines, possibly over a network.

    The JazzAge Object Editor can be used to assign a separate DCOM URL to each invisible at runtime ActiveX of a project. The JazzAge Object Engine uses that DCOM URL when a Control instance is created, to decide on what site the remote part of the new control is to be created. The Form Server Visual dBASE application will run on that DCOM URL site.

    A JazzAge invisible at runtime Control appears as an icon when dropped in a form at design time. It becomes invisible when the form enters into run mode. At runtime, a JazzAge invisible control collects the property accesses and method invocations and forwards them to its remote part running on a different machine. It receives the events fired by the remote part and propagates them to its container.

    6.5.3 Many-to-1 Controls

    You can create ActiveX servers creating object instances to which several clients can connect at the same time.

    The properties and methods of such Many-to-1 objects can be invoked simultaneously by all their clients. The JazzAge Object Engine automatically forwards the events fired by a Many-to-1 control to all its clients.

    A Many-to-1 object receives events fired by the JazzAge Object Engine when a client connects or disconnects. 

     




  13. ActiveX components – What are they
  14. The following paragraph presents some key notions and mechanisms related to ActiveX EXE/DLL servers and ActiveX controls.

    Note : JazzAge handles most of, if not all, the code implied to comply with the ActiveX mechanisms described below.


    7.1 More about ActiveXs

    ActiveX Controls appear in the form of files with a .OCX extension. Those .OCX files are in fact normal DLLs exposing a few functions required by OLE2.

    An ActiveX DLL can implement and expose any number of ActiveX Controls. It can also contain in its resources the toolbox bitmaps representing the controls it exposes.

    An ActiveX Control is an independent and standalone piece of software offering a certain type of functionality to be reused and integrated in a RAD type tool. An ActiveX control must expose a certain number of services defined by the OLE2/COM specifications, and required by the integrating tools.

    7.2 ActiveX controls and the Windows registry

    The Windows registry of a PC stores the list of all the currently registered and available ActiveX components. To each ActiveX corresponds a set of entries in the registry providing (among others) the following information:


    When a client requires the creation of an ActiveX object, given its Name, the COM runtime browses the registry, extracts the location of the server responsible for the object and forwards the instantiation request to this server. The server does the instantiation and returns an object pointer to the client through COM.


    7.3 DLL and EXE ActiveX servers

    ActiveX objects can either be implemented by DLL or EXE binary files.

    An ActiveX managed by a DLL server operates in the same process as its client, through direct function calls.

    The communication between a client and an EXE provided object rely on messages crossing the process boundaries and handled by the COM machinery.

    A client instantiates and accesses an ActiveX transparently to the type of server managing it. A 16 (32) bit client can access ActiveX objects in a 32 (16) bit EXE server.


    7.4 ActiveX Objects and Controls

    A distinction must be made between ActiveX Objects and ActiveX Controls. ActiveX Objects were also named Automation objects before the OLE2 to ActiveX terminology shift. ActiveX Controls were known as OCXs.

    An ActiveX Object exposes Properties and Methods. It can be explicitly created, accessed and destroyed by client applications.

    An ActiveX Control is most often a visual component, inserted in a form. It exposes Properties and Methods but also Events establishing a two-way communication channel between the client and the component itself.


    7.5 An ActiveX Control knows how to paint itself

    As a standalone and independent component, an ActiveX Control knows how to paint itself when inserted in an ActiveX container, without any implication of this container. Since a JazzAge ActiveX is in fact a form, dialog box, revamped as an ActiveX, it already knows how to display itself in a container. Turning a VB, Delphi ... form in a JazzAge ActiveX has no effect on its painting code.


    7.6 An ActiveX exposes Properties/Methods/Events

    An ActiveX Control exposes Properties, Methods and Events.

    Properties represent the state variables of an ActiveX, they can be read and written by their environment. Each Property is given a name, and a type (integer, float, string ...).

    Methods represent the different operations that can be applied to an ActiveX. A Method has a name, a list of parameters, and a return type.

    An ActiveX can emit events under certain circumstances to which the developer making use of it can link code. Like a Method, an Event has a name and a list of parameters.

    The ActiveX DLL file implementing a set of ActiveX controls includes a special section, named TypeLib, containing the definition of all the Properties/Methods/Events exposed by those controls. Such TypeLibs can be used by ActiveX containers to browse and inspect the controls implemented by any ActiveX DLL.


    7.7 An ActiveX is self documented

    An ActiveX TypeLib not only contains Property/Method/Event definitions, but also their individual documentation. The JazzAge Editor can be used to document a Property/Method/Event while designing it by assigning it a description text, or linking it to a help file topic. This documentation will then be made available to the developers by any ActiveX container tool.


    7.8 An ActiveX is self-serializable

    An ActiveX must be able to save its state in a file (a process called serialization), and later restore it (deserialization) on a request issued by its container. This mechanism is used by ActiveX containers to save the state of the various ActiveXs used by an application when switching from design to run mode or when generating the final executable. In this case, generating the final executable, the different ActiveXs serialized data is stored in the executable file itself. When the so produced executable is launched, it creates the ActiveXs it contains on request, and deserializes the corresponding data, so as to retrieve the ActiveX state defined at design time. Serialization/deserialization is therefore a key service an ActiveX must offer.


    7.9 An ActiveX must insert itself smoothly in any ActiveX container

    When required to insert itself in a form, an ActiveX control must follow a precise and complex protocol with its container. This process is completely handled by JazzAge, and hidden to the developer.


    7.10 The different types of ActiveXs

    The ActiveX specification separates ActiveX controls in different types, based on their behavior and appearance in design and run mode, when manipulated in container tools.

    An Invisible at runtime control will only be shown in design mode. It will be made invisible at runtime. A timer control firing events at preset intervals would be designed as invisible at runtime. It would be visible at design-time (so the user can edit its properties, or attach code to its events) but not at run time.

    A Standard control would appear as an empty rectangle at design time, and be fully activated when switching to run mode.

    A Simple Frame control would be fully activated as soon as dropped in a form, at design time. It would also be activated when in run mode. A Simple Frame would already be fully running when in design mode. It could also act as a container for other controls.

    JazzAge produces ActiveXs belonging to any one of the previously described ActiveX control types. The type of a control is one of the attributes that can be set using the JazzAge ActiveX Editor.


    7.11 An ActiveX must register/unregister itself automatically

    When first installed on a new machine, an ActiveX must be able to register itself into the host Windows registry. It implies to provide a certain and precise type of information and record it in this registry. An ActiveX must also be able to unregister itself, and optionally delete the files copied or created when installed. An ActiveX DLL is required to export a couple of standard functions for that purpose. JazzAge automatically includes all the necessary code in the ActiveXs it produces.


    7.12 An ActiveX must provide a bitmap to be inserted in a design time toolbar

    An ActiveX DLL should include in its resources one bitmap representing each different ActiveX control it contains. Those bitmaps will be inserted in ActiveX container toolbars. When designing an ActiveX with the JazzAge Editor, the developer has the opportunity of assigning a bitmap to its component, by specifying a path to a BMP file, edited with PBRUSH for example. JazzAge will then automatically insert such bitmaps in the final .OCX file, and register them properly when installing it on a new machine.


    7.13 An ActiveX optionally exposes Property Pages

    An ActiveX can expose and implement its own user interface to let the user visualize and edit its state at design time. When dropped in a form at design time, an ActiveX receiving a right button click opens a set of Property Pages grouping related properties and offering the necessary user interface to visualize and edit them.

    The JazzAge Editor can be used to edit Property Pages and link them to one or more ActiveXs. Implementing such Property pages can be done with any development tool connected to JazzAge, in exactly the same way as for ActiveX Controls.


    7.14 Advanced mechanisms related to ActiveX properties : property binding

    ActiveXs support a simple sort of property change notification. An ActiveX Control can optionally send notifications when some or all of its properties change. Those notifications can be processed by the container logic to provide property-binding mechanisms.

    An ActiveX Control describes its properties in its type library (typelib), including whether they are bindable or not (that is whether they emit change notifications or not).

    An ActiveX can decide to make its properties send notifications individually.

    A property can send two different notifications : OnRequestEdit and OnChanged.

    An OnRequestEdit notification is sent when a property is about to change but has not yet changed. This gives sinks attached to the property opportunities to save the original value, but also to veto the property change.

    An OnChanged notification is sent whenever and after the property changes value.

    A property sending change notifications can be displayed to the user at design time as bindable or not. Furthermore, a property can be displayed as the best one representing the Control as a whole. This can be used by containers to bind to a Control rather than to a single property.

    JazzAge fully supports the property change notifications. A developer can choose to have any of its ActiveX properties send such notifications or not. This is done at the time the properties are designed, using the JazzAge Editor.


    7.15 Enumerated Types

    Besides standard types (2 byte integers, 4 byte integers, strings...), ActiveX allows to define custom types, such as enumerated types which represent a set of predefined values.

    The JazzAge Editor can be used to interactively design enumerated types and assign them to properties or method and event parameters.
     

    7.16 ActiveX Component Licensing

    A licensed ActiveX distinguishes between situations where it is being used in designing a consuming application versus being used in running a consuming application.

    At design time, an ActiveX can require the presence of a particular license key file before allowing its host development environment to instantiate it in a designed form. By verifying the existence of the license key file, the ActiveX recognizes that the machine has a valid license for it.

    When the consuming application is compiled and stored to disk as an executable, the development environment requests a key from each licensed ActiveX it contains and bundles it in the produced executable file.

    At runtime, the bundled key is presented to the licensed ActiveX when instantiated, unlocking its capabilities, without searching for a license key file.

    JazzAge offers a very simple way of following this licensing protocol, by the means of a set of three events fired by the JazzAge Object Engine, and to which the licensed ActiveX must respond.
     

    7.17 ActiveX Component download, Web deployment
     

    7.17.1 Presentation

    The Internet Component Download is a mechanism through which applications download, certify and install ActiveX components from the Internet.

    To be downloadable, an ActiveX component must have been previously copied to a Web site acting as an object store.

    ActiveX component downloads most often occur with HTML pages containing ActiveX controls. In an HTML page, the <OBJECT> tag indicates an ActiveX control. An <OBJECT> tag looks like:

    <OBJECT>
    CLASSID="C75CBBF5-7DA2-11D0-902A-0000E830E40C"
    CODEBASE="http://www.jazzagesoft.com/javb4/javb432.ocx"
    </OBJECT>

    It provides the URL of the .OCX binary file implementing the ActiveX, along with its CLSID (an OCX can implement several objects/controls).

    When the Web browser finds an <OBJECT> tab, it checks to see if the component is already installed and searches the local system for the specified CLSID. If the component was already installed, its server is launched and it creates an instance of the required object. Otherwise, the browser downloads the server, based on the URL found in the <OBJECT> tag.

    Such a URL points to an HTTP server acting as an object store. The code is downloaded and installed on the local site. See figure 2.1 


    Figure 2.1: ActiveX component download

    7.17.2 Advanced component deployment: runtime profiles, versioning ...

    The <OBJECT> tag detailed below:

    <OBJECT>
    CLASSID="C75CBBF5-7DA2-11D0-902A-0000E830E40C"
    CODEBASE="http://www.jazzagesoft.com/javb4/javb432.ocx"
    </OBJECT>

    contains a CODEBASE entry giving the URL of the .OCX file exposing the control embedded in the HTML page. A CODEBASE entry can also refer to .INF files providing much more information about the runtime environment required by the control.

    An .INF file appearing in the CODEBASE entry of a HTML <OBJECT> tab is a text file very similar to an .INI file, and conforming to the following syntax:

    [Add.Code]
    <filename>=<section_name>
    ...

    [<section_name>]
    File=<URL>
    [FileVersion=<a,b,c,d>]
    [File-%opersys&-%cpu%=<URL>]
    CLSID=<ActiveX_CLSID>
    [DestDir=[10|11]]

    The Add.Code section lists all the files to be installed, including optional files. Each file section is identified by its <section_name>.

    The following keys are valid in a file section:

    File=<URL>

    Indicates where the file can be downloaded from. If no value is specified, component fails if the file is not already installed on the user’s machine.

    FileVersion=<a,b,c,d>

    Specifies the minimum required version of the file given in the File entry. If no value is specified, any version is accepted

    File-%opersys%-%cpu%=<URL> | ignore

    Gives a URL for a file depending on the target operating system (%opersys%) and CPU (%cpu%). %opersys% can be one of [win32/win16/mac]. %cpu% can be one of [x86/ppc/mips/alpha.]

    CLSID=<ActiveX_CLSID>

    CLSID of the component described by the current .INF file.

    DestDir=[10|11]

    DestDir can be set to 10 to place the file into the \windows directory or to 11 to place the file into the \windows\system directory. If no value is specified, the file is placed in the cache directory.

    Example: SMILE.INF

    [Add.Code]
    Smile.OCX=Smile.OCX
    MFC40.DLL=MFC40.DLL

    [Smile.OCX]
    file-win32-x86=http://www.smile.comp/components/smile/smile.ocx
    CLSID={ABDCDEFG-0000-0000-0000-123456789ABC}
    FileVersion=1,0,0,100

    [MFC40.DLL]
    File=http://www.smile.comp/components/runtime/mfc40.dll
    FileVersion=4,0,0,5



    7.18 Trustworthy Components

    Before installing a downloaded ActiveX component, the Web browser ensures the file is safe to install by searching it for a signature bloc (also known as digital signature). The signature block contains information about the author of the file, a public key and an encrypted digest of its content. The file digest was produced by a one way hash algorithm and then encrypted using the private key corresponding to the public key appearing in the signature block.

    The verify service invoked by the Web browser re-ashes the file content, decrypts the received file digest using the public key and then compares the results. If the two digests don’t match, the file has been tampered with and a warning message displays to the user who is then free to reject it, and prevent its installation on the client site.

    The verify service (known as Windows Trust Provider Service) maintains on the local site a list of certificates describing the approved component providers. When a new certificate is presented, a message displays the name of the software, identity of the publisher and Certificate Authority (CA) having validated the information. The user can then accept the presented certificate and store it on the local machine.

    Signing components requires obtaining a certificate from a Certificate Authority (CA) such as Verisign (www.verisign.com).


    7.19 DCOM: Distributed ActiveX

    A client can transparently instantiate and manipulate ActiveX objects implemented by DLL or EXE ActiveX servers running locally but also on a remote machine, over a network. A remote connection between a client and an object is entirely and transparently handled by the DCOM runtime, without requiring any modification of either the client or the object server.

    In order to be accessed remotely, an ActiveX object must have been previously registered on the client machine, therefore providing the URL of its server.

    With the current version of DCOM, available on NT4.0 and Win95, only EXE servers can be DCOM servers. 


  15. Components -- What about MIDAS ?

  16. 8.1 MIDAS - the full version

    MIDAS stands for Multi-tier Distributed Applications Services Suite. It comes with a set of advanced components, servers, and core technologies for multi-tier application development. These services enhance those provided by Microsoft with Windows NT 4.0 and DCOM.

    According to the official docs, the MIDAS feature set includes :


    Borland MIDAS is a suite of three distinct technologies that work together to make multi-tier distributed applications easy to build. These technologies consist of :
    The various parts can work individually or in conjunction with each other.

    The version supplied with Delphi 4 Client/Server now also supports the CORBA environment. The protocols supported in the later version are :

     

     

    As you can see from the diagram, the MIDAS set of tools act as a middleware between thin client applications and the server applications and databases. It provides for a very powerful distributed computing environment.


    8.2 MIDAS - for Visual dBASE

    To use all the MIDAS features, however, you need to use Delphi (or C++Builder) as a development tool... Well, anyway, you cannot really use all the features with the current version of Visual dBASE. Why ? 

    1. To use the remote data and business brokers, specific components/classes are provided in Delphi. The equivalent not being provided in Visual dBASE, getting to the equivalent result would require a substantial amount of low-level coding, if ever possible without appropriate technical documentation. If you want to try yourself at accessing the DLLs for the Remote DataBroker and the ConstraintBroker, you can have a look at http://www.inprise.com/midas/papers/components.html
    2. The MIDAS version delivered with the Client/Server version of Visual dBASE 7 is obviously a scaled down version, which doesn’t not include all the features.

    So, what’s left ?

    The OLEnterprise set of features, which includes :


    You can use the Object Explorer to browse the components declared in the Windows system registry, and then choose the ones you want to export to another system on the network.

     

     

    You can also use the Object Explorer to browse the TypeLib of an ActiveX :

     

     

    If you need to manage distributed components that you will use in your Visual dBASE applications, then OLE Enterprise can certainly be useful to you. However, if you have decided to create Visual dBASE ActiveX components with a tool such as the JazzAge Object Factory, you may be wise to consider using the built-in functionality in this product. It could simplify the deployment and centralize it in the same user interface as the ActiveX project (the JazzAge ActiveX Editor).

    Remember the version of OLEnterprise included with Visual dBASE 7 can enable the developer to use DCOM or RPCs. If you do have to use RPC-based components, you may have a better choice (or no other choice) than using OLEnterprise.

    OLEnterprise can also help you get around some DCOM limitations. Here is an extract from a paper by Charlie Calvert :

    "OLEnterprise has several advantages over DCOM:


    Well, a few lines of code written By Charlie in Delphi, of course. Anyway, if you decide to go this way, here are some tips by the same author, which will save you some of the time I had to spend on trying to tune up the puzzle :

    "When installing OLEnterprise on a Windows 95 machine, do not install into the default directory, but instead install off your root, and try to avoid long file names in the directory path. Any problems with OLEnterprise and long filenames on Windows 95 machines will be corrected in future releases of the product. To work around any potential problems, simply install into a directory structure that does not use long filenames.

    There are four key pieces in the OLEnterprise toolset:


    When using the Explorer, you need to learn how to import and export objects. This is an intuitive process accomplished by manipulating the menus or by right click on items in the main panels of the application. You should probably spend some time using the default sample programs shipping with the product to make sure you understand importing and exporting objects. In particular, go to etc\samples\auto\memoedit to find a good pre-built sample program."

    Let’s hope that the next version of Visual dBASE will provide for a better integration with the MIDAS technology and the future Application Server. Or, maybe a set of tools could be made available separately to provide for such functionality. 


  17. Components -- What’s next

  18. 9.1 Components world

    Components will invade all avenues and corners of the computers’ world in the coming years.

    The various announcements made by Inprise/Borland and the new products and directions showed at this year’s Conference demonstrate this. They also emphasize the leading role the editor of Visual dBASE wants to take in the technologies used for that market.

    Further, the tools and technologies proposed by Inprise/Borland have a central goal: break the iron wall between competing middleware technologies. They will provide interoperable tools, using such different standards as DCOM, CORBA, RPC or IIOP in a more transparent way for the developer and the user.


    9.2 JazzAge

    The next version of JazzAge, JazzAge 2.0, due next fall, will provide many enhancements and new features.


      9.2.1 ActiveX Documents

      An ActiveX Document server is an application serializing its state in a file with a special extension (say .XXX) and running in an ActiveX Document container like Internet Explorer or Office Binder. The .XXX files act as HTML pages, when IE loads such a .XXX file, the corresponding Document server is automatically launched and its forms appear inside the IE framework.

      9.2.2 Hyperlink source and target support

      The JazzAge 2.0 ActiveX Document servers will support Hyperlink as a source and/or target. A JA ActiveX Document appearing in IE can contain links to other URLs and trigger them programmatically, as a hyperlink source. The current Document will then receive notifications monitoring the hyperlink. An ActiveX document can also be a Hyperlink target and be activated as a URL by IE.

      9.2.3 Asynchronous data download

      A JA 2.0 ActiveX Form/Document can perform asynchronous downloads of files, based on their URL. It will then receive notifications of the download progress.

      9.2.4 Multi-window ActiveX controls


      JazzAge 2.0 will offer the unique capability of building multi-window ActiveX controls, able to change the window they contain at runtime.




    If you haven’t started yet to use components in your development projects, you should consider doing so. It could greatly increase your productivity. It can also enable you to consider implementing features you haven’t considered before.

    The next step is to consider building components yourself. I hope that some obvious and unsusual advantages have striked your mind during this presentation, or while reading this paper. And by now, you know that with the help of JazzAge you can build components with your favorite development tool, Visual dBASE.

    Fellows Visual dBASE developers, we sure are armed for the future !
     

    François Ghoche - July 98

     
    François Ghoche can be reached at :
    E-mail fgwebfghoche.com
    mail : ATON - BP 49 - 78042 Guyancourt (France)
    voice : +33 (0) 139 440 301
    fax : +33 (0) 139 440 331
    World Wide Web : www.fghoche.com 
     


    Special thanks to Philippe Monteil (JazzAge Software) for his patient coaching on the ActiveX road, as well as helping in providing documentation for this paper.
    Philippe can be reached at pmonteil@jazzagesoft.com or http://www.jazzagesoft.com




    © copyright 1998, J. François Ghoche. Complete and unabridged reproduction authorized for non-commercial use. Extracts or other only by written authorization. Some parts are © copyright 1997, JazzAge Software Sarl. Brands product names and trademarks are registered trademarks of their respective holders.