COMOS Quickstart Developer
COMOS Quickstart Developer
© innotec GmbH
© innotec GmbH
Connecting or extending Comos externally Starting Comos via the command line
Parameters
The following parameters can be included in any order to the Comos call:
Example
Comos /D z:\ReleaseDatenbank\Comos.mdb /P SO1 /NO
1 Old technology
As an alternative to the above, you can also work with parameters separated
by spaces. In that case you must follow a specific order:
Example:
Comos.exe z:\ReleaseDatenbank\Comos.mdb 1 SO1
This older form should not be mixed with the use of parameters.
1.2.1 XIF.exe
XIF can start Comos via an external program call, it can open a project, select
an object in the Navigator, and open a report on which the selected object has
been placed.
Parameters
/DT: Data type of the database. Replaces the /DB and /DN
parameters for Server databases; you get the data type
from workset.initString, for example:
/DT: [SQL - SERVER]PT_SQL_SERVER_1
Examples
XIF.exe /MD: V /DB: ACCESS /DN: C:\Comos_DB\ComosPT.MDB /PR:
H001 /ON: =PM09FA00.EM02;Auto /PA: DETAIL
Application examples
• Search for object by FullLabel
The device or document being searched for can also be identified by means
of the FullLabel. However, the FullLabel does not take folders or
prefixes into consideration. If a document is searched for by means of
FullLabel and not found, then all the parallel folders are now searched
automatically to see whether the object can be found. In addition, any
possible prefixes are also considered.
• Open a report
An object can be placed on multiple reports. For that reason you can now
input in addition the /PA: <Symbol type> option. This allows you to input
a specific report type onto which the object in question is placed. Please note
that in this case the object may not be placed on two reports of the same
type.
1 If no document was found (the object is not placed on a report of this type or
the symbol type is unknown), the Properties window of the object then opens.
You can also use this function in a targeted way if the Properties window is
to be opened explicitly by simply entering an unknown symbol type as the
option.
if (GetTagBit("U2") == 1)
strcpy( SystemUID, "/ID: C1D45BO8U7 " );
else if (GetTagBit("Error") == 1)
strcpy( SystemUID, "/ID: A1D9VBO5U7 " );
else
strcpy( SystemUID, "/ID: A1D9VBO5U7 " );
ProgramExecute( ASString );
}
1
1.2.2 XIF.init
The following steps demonstrate the core points of the access. Obviously a
workable VB project will still require all sorts of extensions, such as more
variables, error trapping, and the like. The following brief illustration thus
does not necessarily imply that error trapping, for example, can be dispensed
with.
1. Set reference to VB project
The dialog for the component references is opened in Visual Basic.
Search for "comos.dll" and link it. The entry "Comos Kernel " appears
in the dialog window.
2. Set and create topmost object
The "workset" is the entry object in the Comos object hierarchy:
Dim m_wset As IComosDWorkset
Afterwards the object still has to be created in the usual way:
Set m_wset = CreateObject("COMOS")
3. Open database
If you give the "Init" command with two blank parameters (which are
only of interest for advanced developers), you can open the database very
easily in this way:
m_wset.Init("","",<<Data base name>>)
From this point on you can work in the usual way. For example, you can work
as if you were using the object debugger: you can set an object and then call
up the functions from it.
Sample file
<comos>\Help\English\Further Documentation\Comos general\
ComosFormInterface.zip
In this zip file there is an example as to how the Properties windows of devices
can be integrated into Comos. The example assumes that you have a sound
knowledge of VB.
Overview
The following information applies solely to the creation of Properties win-
dows. In addition, there are still other extension options for Comos, such as
the creation of PlugIns or your own attributes.
The basic steps for the integration of new Properties windows are as follows:
1. Creation of a VB project
A ProgID is also allocated within the VB project.
1 IEditForms has among other things the important task of getting three stan-
dard functions for the simulation of "events":
Abort Button [Abort], the button with a cross [X] in the window
frame.
Apply Button [Apply].
Ok Button [OK].
The developer is not forced to use these three standard functions. The three
functions can also be left blank without any code. However, the developer
must click once on the functions so that they are actually entered in the code.
Reason: All the Properties windows of devices in Comos make use at least of
the three controls [Abort ], [Apply ] and [OK ] (and the button with the cross
that reacts in the same way as [Abort ]). Since these three functions are man-
datorily implemented, this makes the software considerably more stable: there
would be an error when the controls were triggered if these functions did not
exist. However, nothing happens because these pseudo-events (the functions
Abort, Apply and Ok) are implemented, but blank.
2.2IEditFormsEventHandler
If the components are regularly to react to events initiated by other compon-
ents, there must be an additional login as event handler:
Implements ComosVBInterface.IEditFormsEventHandler
For simplicity, this implementation was not given in the code examples in file
ComosFormInterface.zip. It is as follows: Comos.exe accepts the actual Win-
dows events and informs IEditFormsEventHandler when one of them has been
triggered.
In IEditFormsEventHandler the following Windows events are allocated to six
standard functions:
OnAbort Button [Abort], area with a cross[X] in the window
frame.
OnApply Button [Apply].
OnChange Process that can be saved ("change").
Thus, for example, the [Apply] button is set to activated.
Thus in the following the developer has nothing more to do with the Windows
events but instead works with functions that operate the relevant specific
events. Thus it is also left up to the developer to allocate the above-mentioned
functions to self-defined pseudo-events, for example, to keyboards com-
mands or mouse menus.
Only for completeness, it needs to be said that similarity of the names of some
of the functions does not in any way change the basic fact that they are indeed
different functions.
Thus, for example, in IEditForms there is an Abort and in IEditFormsEvent-
Handler there is an OnAbort. Both functions fulfill similar tasks, namely to
function as pseudo-events, but are nonetheless not identical.
The topic of "Events" is covered further in item 5.
3. Versions
Fundamentally speaking, in software development there is the problem that a
component can also be developed once this is already in production use. The
problem then arises that the components of a program must know in commu-
nication what the functional scope (interface) the other components have.
This problem is resolved in Comos with a "version". In IEditFormsEventHand-
ler there are the following lines for this purpose:
1 The versions concerned involve versions of the Comos interfaces. The list of
the relevant version numbers of the Comos interfaces is thus embedded in the
customer component with GetVersion and so Comos knows which actual
component version this third-party component belongs to.
If the publics are defined in the third-party component and these in turn are
used in further third-party components, the developer himself is responsible
for interface management. Comos does not know the publics of the third-party
components.
4. Input / Output
m_EnableChange, m_ExampleObject, m_ItemObjects
Here the objects are passed to the component. In this example you can then
change the name and description of these objects.
5. Events
If you wish to get "events" (trigger them yourself), then write the following:
Private Sub IEditForms_EventsHandlerAdd
The typical case: the component is unloaded and then no longer needs to be
logged in to the event handler.
6. Tabs
m_Partners
All the properties areas together of a device make up a collection. You can tell
from the Configuration tab of the CDevice which properties areas there can
be: all the entries of the first level are areas that could be a "partner". For
example, that could be the tabs. But the "general area" above the tabs is also
a "partner" of this type. Note also with the Specification tab that all the Spe-
cification tabs held there and all the attributes belong to this one partner.
These collections are managed with:
Private Property Get IEditForms_Partners
and
Private Property Let IEditForms_Partners
and
Private Property Set IEditForms_Partners 1
7. Start mode
m_StartMode
Currently there are two start modes:
MainMenu: if the component is called up from the Comos menu
Default: in all other cases
8. ProgID
Private Property Get IEditForms_ProgID
The ProgID is not set here but in the VB project instead. The ProgID is fixed
in the code here and thus can only be fetched with a Get.
9. Hold the component in the background
Private Sub IEditForms_ShowMode
If a device is closed, for example, then not everything is necessarily unloaded.
Instead you can also set the component to be invisible and then you can access
it again more quickly if you need to later.
10. Error handler
ComosStdErrorHandler:
StdErrorHandler Err, Modulename, "Sub IEditForms_Apply"
This is the standardized Comos error handler. You can of course write your
own one instead.
Sample file
<comos>\Help\English\Further Documentation\Comos general\
ComosSpecification.zip
In this zip file there is an example of how you can integrate your own attribu-
tes into Comos. The example assumes that you have a sound knowledge of
VB.
Overview
1. Create a VB project
Attributes must of course use the Comos object of an attribute. The Comos
object permanently saves the information in the database.
The attribute itself is normally written to the ctl file as for a control.
The display and capabilities of the attribute can be set via an extra Property-
Page, of which there will be more later.
3. Declaring and managing your own control properties
In addition, you can define properties for the display of the control. The cor-
responding interface for it is the so-called "PropertyPage".
If you use a PropertyPage of this type, you can additionally allow the user to
change the default properties of the control (font, size, etc.).
However, the PropertyPage is primarily required if the attribute is to possess
special display properties. An example of this would be the Comos "List"
attribute, which has a whole of extra properties over and above those of the
default control properties.
This distinguishes the attributes of the Properties windows of the device: there
the user is not allowed to change the default properties or to define his own
properties and to then allow these to be changed by the user.
1
The amended properties are stored in the PropBag of VB:
m_MyProperty = PropBag.ReadProperty("MyProperty", 0)
The inputs of the user are accepted and written to the Comos object. You are
of course tied to the properties and methods that are made available by ICo-
mosDSpecification, see the "Comos Kernel" documentation.
Integrate attribute
Attributes are selected via "Display type". If you wish to use your own attri-
bute, you must therefore create and integrate your own display type.
1 The following list is used to regulate which types of display of attributes are
recognized by Comos:
System project, @System |OCXCONTROLS.
Comos has an internal list of attributes. This internal list takes effect if the
OCXCONTROLS does not exist or has been corrupted. However, OCXCONTROLS
takes priority over the internal list.
OCXCONTROLS is not in the Release database and must be created by yourself
as required. You can restrict yourself to the desired additional lines in such a
case. It is not necessary then to enter all the attributes in this list.
Structure of OCXCONTROLS:
Sample file
<comos>\Help\Deutsch\Sonstige Dokumentation\Comos Allgemein\
ComosPlugIn.zip
In this zip file there is an example of how you can integrate your own PlugIns
into Comos. PlugIns are independent forms that can be started within Comos
and communicate with Comos via a fixed defined interface. PlugIns offer
somewhat more design freedom than does creating a Properties window for a
device: Properties windows assume and require that IEditForms is imple-
mented and that a number of overall conditions are complied with. There are
no such restrictions when designing a PlugIn. PlugIns are made available to
the user by means of their own icon bar. The example assumes that you have
a sound knowledge of VB.
Overview
1. Create a VB project
The prerequisite is that the project name of the Class-Module must always
start with "CPlugIn", since this text is used as a search string to find
entries in the Registry. All the entries that are found in the Registry, are
1
then automatically allocated to the PlugIns menu bar in Comos.exe when
the user activates the | LOAD PLUGINS menu item.
Set the references in the VB project:
ivbcomos.dll
The entry "ComosVBInterface " appears in the dialog window. In
particular, this component gets the interfaces with which the PlugIn
communicates with Comos.
XStdMod.dll
This component primarily gets the default Comos error handler. If you
wish to use your own error handler, you can do without XStdMod.dll.
2. Program the PlugIn as indicated below.
container
Fixed definition, is not changed.
prototype.frm
The form calls up the container and carries the customer OCX.
xxx.ocx
The customer OCX. Please note that a default is not implemented via
IEditForms, as opposed to the Properties windows. The customer takes
the responsibility for the standard controls ([OK], [Abort], [Apply]) and
also the underlying logic (undo, save, etc.)
xxx.cls
Contains the actual logic.
3. All components of the project are renamed.
In principle you only need to replace all the places in which the text "Proto-
Type" occurs.
4. Prepare the bitmap
Ensure that the names match.
The bitmap (16x16 bmp file) must have the same name as the PlugInDLL and
be located in parallel with the DLL (thus as a rule in Ocx\CPlugIns).
1 The form is not allowed to have a border style, because the container still has
to be loaded around this form and the container brings its own border with it:
Friend Property Set Container
The user can develop his or her own DLL and make use of Comos functions
in the DLL. An example of a Visual Basic project is found under
Help\Deutsch\Sonstige Dokumentation\Comos allgemein\
UserDefRevPrn.zip
Make sure the drop-down menu in the Project options is set to User-defined
and make sure you enter the ProgID in the lower field.
ProgID = Name of the VB-project + . + class name.
Comos possesses a dll that can be used to startup Comos in any test environ-
ment:
<Comos directory>\OCX\startup.dll
Set the reference in the VB Project menu:
PROJECT | REFERENCES, and select “Comos StartUp “
Startup.dll
• Property Comos As IComosDWorkset
The Comos object hierarchy, starting with Workset, is available, see the
documentation Comos Kernel.
1 • Sub DatabaseOpen()
Opens the “Open Database“ window for database registration.
• Function ExecuteCommandline(CommandLine As String) As Long
It is equivalent to a direct start or a Comos startup via the command line.
• Sub ProjectOpen()
Opens the “Open Database“ window for database registration, and then
opens the “Open Project“ window and finally opens a window for
Working-layers (if working layers are available).
• Sub Terminate()
Terminates Workset, Comos and the application, in which Comos is being
executed. Thus this command should not be used in a pure test environment;
in this case the application is Visual Basic. In other words: this command
will stop entire VB application in a test environment.
Components to be test
Additional components are of course required for a functioning test environ-
ment. The Startup.dll only provides you with the Comos-login, nothing
more than that.
For example, a Navigator (ProjTree) and a few fields to retrieve information
from devices can be placed on a Form. The device can be accessed starting
from Workset, which is in the Startup.dll.
Here is an example:
Dim gStartUp As ComosStartUp.StartUp
Dim gWS As IComosDWorkset
gWS.Terminate
End If
Set gWS = Nothing
1
Set gStartUp = Nothing
End Sub
Additional information:
ProjTree1is the Comos component
<Comos directory>\OCX\Projtree.ocx
These components must of course be placed on a Form. The Command2_Click
command button initializes the Navigator placed in the test environment with
the currently selected project.
The Sub Form_QueryUnload terminates the test environment. The Terminate
for Workset called here is not the same as the Terminate in the Startup.dll
(since the latter one will terminate the application as well).
The above is the known dialog for database registration. After selecting the
database, the [COMOS LOGIN]
button is to be clicked.
The drop-down list Project (Working Overlay) now gets initialized. Open the
list and view the projects,
followed by the corresponding working layers of the project.
1 The [Next] command button opens the project and the next form Frm-
Test.frm:
The OCX that was used to explain the properties technique for devices is
shown on the right, see also →SECTION 1.3.2: PROGRAMMING THE COMOS PROPERTIES
WINDOW IN VB.
Goal
In the following example the product and the median value of three attributes
is to be determined with the aid of an own DLL. The result is output on the
same tab in the attributes specified for it.
Sub OnChange()
'After editing the unit or the value
Dim Spec1, Spec2, Spec3, Spec4, Spec5
Dim Calculation
End If
End If
Next
1
msgbox doccoll.count
Set DocMgr =
CreateObject("ComosDocumentManager.DocumentManager")
DocMgr.PrintDocuments DocColl
'Then select the appropriate PDF printer and print and
print...
End Sub
This script is entered in the script block of PrintManager and prints out the
documents from the selected entries.