Hi,
in association with ts-soft enterprises Wink I bring you COMate, a PB utility for controlling COM automation servers (components).
Realising that a couple of projects I am working on will soon require to use some COM I decided to study OLE automation in depth, and the best way I found of doing this was to grab the open-source DispHelper library (written in c) and convert it to Purebasic. :)I have of course modified the library to suit my own ends!
The main thing is that whilst the original DispHelper library uses a c-style Printf() syntax, my offering (COMate) uses what is, for me at least, a much more comfortable Visual Basic like syntax.
Contrast :
VB code :
Code:
1
2
3
| Dim excel As Object
Set excel = CreateObject("Excel.Application")
excel.Visible = blnTrue |
converted to Purebasic with the PureDispHelper library :
Code:
1
2
3
| Define.l ExcelApp
ExcelApp = dhCreateObject("Excel.Application")
dhPutValue(ExcelApp, ".Visible = %b", #True) |
and now converted to Purebasic with COMate :
Code:
1
2
3
| ExcelObject.COMateObject
ExcelObject = COMate_CreateObject("Excel.Application")
ExcelObject\SetProperty("Visible = #True") |
Features of COMate :
* Completely free!
* It comes in the form of a PB source code include file.
* Ansi or Unicode and/or Threadsafe etc. (Well, as threadsafe as any COM components you may be controlling!)
* An oop interface.
* Method / property parameters are encoded in a very natural (VB) way within command strings.
* Method/property calls can embed a chain of property-gets, each of which return a subobject etc. (all handled automatically by COMate).
* Command strings can include escape characters in the form $xxxx where xxxx represents a 4 hexadecimal digit character code.
* Easy enumeration of collections.
* Automatic freeing of all strings (unlike DispHelper).
* Full threaded error reporting. Each thread can report (if requested) the most recent COM error as well as a 'friendly' text description if appropriate. This means that if two threads are, for example, working on the same instance of a COM component, then the errors reported in one thread will not affect the other thread!
I think you'd get a good feel for COMate (as well as the differences between this and DispHelper) by browsing the various demo programs which are mostly simple conversions of the PureDispHelper demo programs written by ts-soft, mk-soft and Kiffi; to whom I offer my thanks.
COMate itself uses some code developed by ts-soft and he has been instrumental in helping me test COMate and indeed he translated some of the demo programs for use with COMate. ts-soft is thus very much a part of this project. Indeed, I would like to state right now that he is to be held responsible for any bugs! :)
The COMate package includes the two source include files (one just has constants etc.) various demos and a very comprehensive CHM user manual. This manual is really the first place for those who have never used COM before. :)
You can access the download through the nxSoftware site.
============================================
Update - version 1.1.0. 6th Sept. 2008.
My thanks to all those who have tested out the first version of COMate and to SFSxOI in particular for creating some nice WMI demos.
Changes for this new version include :
* Addition of a 'BYREF' parameter type-modifier. This is for calling methods (VB) in which certain parameters have been declared with the 'ByRef' modifier. For many COM objects it is not enough to simply pass the address of a variable, you will also need to use this new modifier. Particularly true for components created in VB.
* COMate can now house ActiveX controls. See the demo programs and the help manual for details. I haven't added 'Event sinks' yet for trapping events/messages sent by such controls, but it is only a matter of time! Wink Consider this part to be in 'beta' stage because I took a slightly different approach here than PureDispHelper and so it remains to be seen whether more than just a handful of ActiveX controls will function correctly?
* Have totally rewritten the command parser and various utility functions in order to increase the speed. DispHelper does not utilise such a parser and so will of course generally run faster. Increasing the speed has been accomplished by simply removing all PB string functions from the aforementioned functions and replacing with memory buffers and 'in place' alteration (via pointers) of strings. Tests on my machine of these functions (when stripped from COMate) show a x50 increase in speed. Take this with a pinch of salt though! It remains to be seen what effect (if any) these new routines will have, speed-wise, on COMate itself. :)
This new version is now to be known as COMate-Turbo! ;)
* Have included a slightly modified version of mk-soft's / ts-soft's excellent 'VariantHelper' utility within the COMate-Turbo download, because there was a slight bug with the 'SafeArray' macros. Some COM methods/properties will return a SafeArray (yuk!) See the 'Demo_IPAddresses.pb' demo for an example of dealing with a return from a COM method in the form of a SafeArray.
NOTE that the VariantHelper utility can only deal with SafeArray's of one dimension. Beyond this you are on your own! ;)
See the nxSoftware site for the download.
=========================================
