PureBasic Forums - English

srod wrote:Now to correct this damn BYREF business!

ByRef works here like a charm.

Thanks for the new version!

Greetings ... Kiffi

Try passing a string BYREF !!! Bang!

Update - version 1.1.1. 7th Sept. 2008.
Apart from fixing the whole BYREF business which was completely flawed and ill thought out, I have plugged a major hole in COMate's supported parameter types, namely variants! Doh! Needless to say you can now pass variants by value or by reference (See Num3's Open Office example which is posted in this thread!)

There are a couple of things to beware of with COMate parameters (and in particular when using BYREF) which I leave to the help manual (see the page on 'COMate command strings' for details).

Finally, for those enaged with (or to ) WMI, there is a very very useful scripting utility which I came across which I have thrown into the COMate package and which should make things a lot easier!

See the nxSoftware site for the download.

Right, I'm off to study 'Event sinks' now... Let's hope I have more luck than I generally do with kitchen sinks!

srod wrote:Right, I'm off to study 'Event sinks' now... Let's hope I have more luck than I generally do with kitchen sinks!

Awesome

A small example for those, who uses Outlook:
lg
Marco

Thanks for the update and for the demo.

Thanks Marco - I've added your example to the list of demos available in the next update.

srod wrote: Right, I'm off to study 'Event sinks' now... Let's hope I have more luck than I generally do with kitchen sinks!

Awesome! .... is this what is needed to fully use VBScript control? (ie, pass PB procedures to the script to call, etc).

I have no idea!

An event sink is used by those components/objects which offer some kind of event notification. The client program sets up an 'outgoing' interface which, if the COM object offers up this functionality, 'connects' to the object in question which then calls methods in this interface as appropriate.

This is of course particularly useful for ActiveX controls which have some kind of visual interface etc. Other objects can still use this mechanism however.

For our purposes, there really is only one way to go and that is to implement the outgoing interface as an iDispatch interface and rely upon the COM object's type-library to supply the names of the events etc. It is all very elegant.

Now, I know very little about VBS and the VBS ActiveX control, but if it didn't offer up the relevant interfaces for connecting through an outgoing 'sink' interface then I would be very surprised. However, my understanding is that with this mechanism, our resulting 'event procedures' would be called at the discretion of the VBS control itself, typically in response to certain events etc. Now, the only way for a script to 'arrange' for the PB 'sink' function to be called manually would be if the script could 'invoke' an event itself. This would seem to me more than plausible. In fact, can you declare your own 'events' in VBS? If so, then yes this should be more than possible!

Whether you can call compiled functions through other means in a VB script I couldn't say.

Update - version 1.1.2. 8th Sept. 2008.
Version 1.1.2 adds the ability to receive events raised by COM objects (particularly ActiveX controls). My thanks to freak for his permission to use and adapt his 'EventSink' code for use in COMate.

New features :

• Added a new function COMate_WrapCOMObject(). This takes any COM interface obtained by any means and attempts to wrap the underlying object up within a COMate object so that you can easily call any dispinterface functions etc. Designed for use with event handling procedures in particular.
• A new method (SetEventHandler()) added to the COMateObject class allowing the user to attach an event-procedure to the object which is called by the underlying COM object whenever it raises an event.
• Four additional methods added to the COMateObject class for use only within an event-procedure for retrieving parameters passed by the underlying COM object as part of the event notification etc.
• Added a couple more demo programs; one showing how to use the event-handling procedures etc. (A translation of a PureDispHelper demo.)

The help manual has been adjusted accordingly.

See the nxSoftware site for the download.

For COMate_WrapCOMObject(); do you still need to supply the CLSID and IID also, like in a data section, in the code?

SFSxOI wrote:For COMate_WrapCOMObject(); do you still need to supply the CLSID and IID also, like in a data section, in the code?

Nope, no GUID's required, just provide an interface pointer. The idea is that you may have obtained an interface pointer from some operation; e.g. CoCreateInstance_() and wish to quickly call some method without going through the vTable etc. In this case you can attempt to wrap it up in a COMateObject and call the method using COMate automation etc.

This function is really intended for event-handlers where some event may pass a parameter (or two!) in the form of some COM interface or other. You can then use the COMate_WrapCOMObject() function to wrap this new object into a convenient COMateObject so that you can call it's dispinterface methods directly without having to worry about the COM interface's vtable etc. It is really just for convenience.

I know this differs from the GetObjectProperty() method of the COMate class where I automatically wrap up any iDispatch interfaces returned in the form of a COMateObject for convenience (thus avoiding the need for COMate_WrapCOMObject())), but I decided against doing this with event parameters because any objects passed in the form of an event parameter needs the client application to use it's Release() method anyhow. Because of this I figured that converting any event-objects to COMateObjects was best done manually in these cases.

**EDIT : bug!!! Your post led me to a little bug in the COMate_WrapCOMObject() function!

Update - version 1.1.3. 9th Sept. 2008.
Bug fixed with the COMate_WrapCOMObject() function.

See the nxSoftware site for the download.

Hello srod,

i have a curious problem. I want to create a TypeLibInfo-Object
(TlbInf32.dll). The DLL ist registered.

But COMate_CreateObject() returns 0 and
COMate_GetLastErrorDescription() says everything is OK:
In VB6 there is no problem: TIA & Greetings ... Kiffi

How do you install COMate ?
When I run even a simple example , I have always
"Line 17 : Structure not found: i" as an error message, in include COMate_Residents.pbi

I don't know how you can run samples....