With the focus of product development being integration, the COM technology, in conjunction with forms and event driven programming, is moving to the forefront as one of the more powerful features of Visual SmartWare.  COM has been called many things in its lifetime.  COM enabled applications allow for communications between two applications.  Each application provides a set of objects or methods to the other application. This call for a COM interface is started with the  create_object function.  The Object Model of the providing application is than available to the calling application. The relationship between the two applications is often referred to as a server/client relationship.  Applications can be the server or the client or both.

COM is similar to dynamic linked libraries as both are binary in nature and provide a function interface.   SmartWare is able to act as either.  All Microsoft Office applications are COM enabled as well as many of the most common business applications on the market.

Automation is a term used to describe the interaction of many different applications.  With the amount of data that must be handle in today's business environment a database will be a requirement for office automation.  Visual SmartWare will provide a central hub for this exchange of data and provide a powerful database as well.  With automation a SmartWare shipping program could be automation with the company's Quickbooks accounting application.

One of the keys to writing COM code in SmartWare is proper and complete documentation of the Object Model of the application. We feel that the following help files are very useful in describing the Object model for the following Microsoft Office modules

If integration is a key to your application, there are many options available.  current trends are ODBC, COM, and Window APIs. Some technologies such as DDE are supported by are considered to be aging in today's markets.

If web integration is important, SmartWare databases can be accessed with ADO and ASP on Window based web servers.   There options available to UNIX based web servers, however, SmartWare is primarily moving forward on the Window platforms.  If a Linux\UNIX version is required please contact us directly.

SmartWare does run across terminal services and has been shown to work in Citrix environments as well. 

As mentioned previously, the COM interface begins with the create_object function.  The following is an example of how a COM interface is created.

local qbs

local request

qbs = create_object("QBFC5.QBSessionManager")

In this example we are declaring a variable called qbs. Setting qbs as the root object of the COM interface.  The COM interface being called up is QBFC5 which is Quickbooks. Quickbooks is providing the SessionManager.  Everything after this is part of Quickbooks Object Model.  This code is written in the SPL Editor but must be understood by the Quickbooks application.  As you can see proper documentation of the Quickbooks Object Model would be essential.  This is true of all COM interactions.

In the previous example you will notice that the parameters of the OpenConnection2 and BeginSession functions are passed as either numeric values or as literals.  Many Object Models will use constants.  For example, with the OpenConnection2 function the third parameter is passed as a 3.  This third parameter happens to sets the mode in which to open Quickbooks.  Quickbooks could of used a constant named omsingle or ommultiple to control the mode.  SmartWare does not support the constants of other COM providers.  The value of the  named constant may be obtained and use its place, in this case (3).  Furthermore, the parameter's order may need to be determined. In this case the opening mode is the third parameter.

Many Object Model documentation will show the use of named parameters. Normally parameters occur in a strict order.  However if the parameters are optional and the function has many parameters, it seems there should be a way to shortcut the situation of providing all of the values.  Named parameters are attempt to do just that.  Named parameters attempt to eliminate the parameter order requirement.

Lets say that we have a fuction called foo().  And function foo has 10 parameters. The third parameter sets the country.  Some Object Models will use the following format to identify the parameter it is passing. This is called a named parameter.

foo(country:= US)

SmartWare does not support named parameters.  The following is how the same parameter may be passed using SmartWare. if the parameters 4 through 10 are optional they may or may not be able to be omitted.

foo("", "","US")