Update - 9th July 2010.Version 1.2 (Purebasic 4.5 edition).
A bug in COMatePLUS' error reporting has been fixed in the Purebasic 4.5 edition of COMatePLUS. Other editions were not affected by this bug because I inadvertently created COMatePLUS for PB 4.5 from an out of date version of COMatePLUS... doh!!! How the hell I did that is beyond me?
See the nxSoftware site for the download.
===============================Update - 5th June 2009.Version 1.1.
COMatePLUS version 1.1 seems to have passed the x64 test (though I still keep an open mind on that score!)
Therefore, COMatePLUS 1.1 is for both PB x86 and PB x64.
I have also upgraded the error reporting to take into account the FACILITY_WIN32 HRESULT values. In the case of such errors being reported, and when COMatePLUS does not recognise the error in question, COMatePLUS will query the system for a suitable Win32 error description etc.
See the nxSoftware site for the download.
===============================Update - 4th May 2009.Version 1.0.4.
COMatePLUS version 1.0.4 makes a slight alteration to event handlers in that a global handler (\SetEventHandler(#COMate_CatchAllEvents,...)) can now return values through the #COMate_OtherReturn flag. That is, you can specify that your global handler be geared up for returning values through a variant structure which is passed to your handler etc.
See the nxSoftware site for the download.
===============================Update - 30th April 2009.Version 1.0.3.
COMatePLUS version 1.0.3 adds a new 'helper' function :
which takes a 'friendly name' of a COM interface and, if successful, places the 128-bit IID of the interface into a specified buffer.
I added this to assist with the SetEventHandler() method of the COMateObject class which, for more advanced uses, takes an optional IID etc.
NOTE that this function cannot be used to obtain a CLSID from a COM component's friendly name. COMatePLUS already does that automatically.
Tested on Vista only.Examples of friendly names for COM interfaces :
- ... etc.
===============================Update - 29th April 2009.Version 1.0.2.
COMatePLUS version 1.0.2 adds a facility for specifying an 'out-going interface' when setting up an event handler for some object or other.
This is essentially for 'advanced users' only, but, basically, COMatePLUS event handlers are based upon an 'out-going' interface which is 'connected' to the underlying COM object through what is called a 'connection point'. Now, many components support different 'out-going' interfaces offering a different range of events which we can tap into and thus we can, if appropriate, direct COMatePLUS to use a specific out-going interface (and thus effectively choose a set of events which we might wish to consider).
To direct COMatePLUS to use a specific out-going interface, simply pass the address of a buffer holding the IID of the relevant interface to the SetEventHandler() method of the COMateObject class (through a newly added optional parameter).
Otherwise, COMatePLUS will simply use the first 'suitable' out-going interface which it encounters (which was the case with all previous versions of COMate) !
There is a new demo (thanks hm) to show this in action with a web-gadget.
The manual has also been updated, in particular limitations of COMatePLUS' event handling are discussed.
COMatePLUS is a complete replacement for COMate for Purebasic 4.3, so much so that I will no longer support the earlier versions of COMate in any way, shape of form! Got to draw the line somewhere! I have asked for the original COMate thread to be locked.
The original COMate thread is here
First thing to say is that COMatePLUS is what COMate should have been in the first place!
Second thing to say is that all existing COMate programs (for Purebasic 4.3) should run without modification with COMatePLUS.
So what does COMatePLUS bring to the COM party then?
Let me quote from the user manual :
COMatePLUS represents quite a jump forward over earlier versions of COMate, both in terms of it's internal workings and the facilities offered to the developer when working with automation servers. These changes were motivated by a desire to allow much faster access to COM methods/properties than was currently available through COMate's existing command processor.
COMatePLUS can process 'strings' of 'closely related' method/property calls far far faster than earlier versions of COMate, although you do have to specifically make use of the new facilities in order to take advantage of any possible speed increases etc.
Earlier versions of COMate, when given a command string as part of a method/property call, would first undertake the sometimes lengthy process of tokenising and parsing the command string looking for method calls, parameter types, type modifiers ...... etc. and only when this process was complete would it consider executing the COM method etc. When the COM method finished its work, the results of all that tokenising and parsing would be discarded, meaning that if the same method/property needed to be called again (perhaps with modified parameters) then the processing of the command string would need to be undertaken again!
A somewhat wasteful affair don't you think?
COMatePLUS takes a different approach, one inspired by SQLite's use of 'prepared statements' etc.
Basically, COMatePLUS allows you to pre-compile a command string right down to a level suitable for passing directly to a COM server. The result of this compilation is what I have termed a COMatePLUS statement which can be executed at any time and as many times (against different COMate objects if required) as required etc. Parameters can be altered between calls very quickly.
The important thing is that the original COMateObject class now uses these pre-compiled statements 'behind the scenes' and so all existing COMate based code should run fine with COMatePLUS with no modifications whatsoever. Of course, all existing code will not run any faster; only code specifically making use of these prepared statements can benefit from these changes.
A couple of newly added demo programs written to showcase COMatePLUS' prepared statements show a 10-fold increase in speed on my system, -something which is not to be sniffed at!
The following functions have been added by COMatePLUS for working with prepared statements (see the relevant sections of this manual for details) :
In addition, a new method has been added to the COMateObject class :
which is, in a sense, the reverse of the COMate_WrapCOMObject() function.
All of the COMateObject class methods dealing with calling COM methods/properties have also been modified by the addition of an optional parameter in which we can pass a COMatePLUS statement handle etc. See the COMateObject class section of this manual for details.Other alterations to the COMate library.
You can now also opt to remove all error reporting from your COMatePLUS application. Simply define the constant #COMATE_NOERRORREPORTING = 1 at the top of your source, before including the main COMatePLUS source file.
In a sense, if the original COMate is to be considered as an interpreter (programming), then COMatePLUS is to be considered a compiler!
Whilst you work your way through the modifications to COMate, you may wonder why I have opted to implement certain features in the way I have? For example, take a look at the mechanism through which you modify parameters within a compiled statement! Here, you are required to deal directly with COM variant structures.
All of these questions are addressed in the extensive modifications to the user manual and so I will not address them here. (All related to issues of speed and efficiency which is what these compiled statements are designed to enchance.)
Needless to say that I advise even the most experienced COMate users to read the section on modifying statement parameters - and I mean every word!
There are some serious issues for you to consider and some potentially application wrecking pit-falls to avoid!
In terms of speed gains, as stated above, only those applications designed to explicitly use pre-compiled statements will see any benefit and then only if the application is such that a compiled statement requires executing many times, -usually whilst modifying parameters etc.
In my first test, I wrote a quick program to write 30000 cells to an Excel spreadsheet and found only moderate increases in speed etc. This is because Excel is slow at writing data and caches all write operations anyhow! The best way of quickly writing data to an Excel sheet is via a 2-dimensional safearray (thanks MrMat).
My second very contrived test involved the VBScript regular expression object to which I applied 1 million string replacements.
Without using pre-compiled statements the operation took around 65 seconds on my system to complete.
Using compiled statements the same program took less than 6 seconds! 'nuff said!
Please see the nxSoftware site for the download. You can still download the last version of the original COMate as well if you wish, though why you might do so is beyond me at the moment?