Subject: RE: [SWIPL] Extensions to ActiveX DLL

From: "Douglas R. Miles" <[email-masked]>
Date: Fri, 28 Sep 2001 16:20:36 -0700

> 
> Paul Singleton wrote:
> > Philip Warner wrote: (yes this concerns prolog calling COM/OLE then the
other way around)
> 
> > Thanks to Douglas R. Miles, I now have the source for the 
> ActiveX DLL for
> > SWIPL; I would be interested in comments from anybody who 
> has used (or
> > considered using) the library. 

Actually thank David Hovel from Microsoft, who wrote them :)
They were posted in the APLHA directory by Jan a while back. 

> 
> 
> I considered using this, but concluded that the way it 
> converted ActiveX 
> data values (and object refs) to and from Prolog was inconsistent.
> 
> I spent a lot of time reimplementing it, but eventually gave up, 
> deciding I was unlikely ever to finish it :-) (in any sense, but 
> especially, produce something useful and memory-safe)

I spent about three months myself working on a ActiveX to prolog
serialization library.  I think I have it down by now.  It works in
conjunction with SWIACTX  .. normally SWIACTX converts intrinsic VT_* types
and when you cant you get an activex_object(-RefID).  From there you walk
down the object model basically the same way from prolog that VB would use
CallByName against the activex_object/1. 

I am very interested, and still __slowly__, working on getting a generic moo
gaming system (by MS) to operate programmatically from prolog.  I was
excited (or distracted) when I saw how to automate the creation and
interfacing to ActiveX with object templates retrieved from TLBINF32.DLL.
That part is actually done.. Making it not a confusing or a month to learn
how to say "hello world" part is still pretty tough.  I was thinking of
reusing as much of the Logitalk paradigm for describing objects from prolog.
Still, even Logitalk can turn a simple VB object into alot of work. 

> 
> I came to realize, as should have been obvious to me, that any such 
> interface requires clear goals, design and rationale.
> 
> Some suggested goals:
> 
>   * be able to create instances of (almost) any ActiveX 
> object, and call 
> (almost) any method

Absolutely.. I think one of our toughest parts is when a method requires
that we submit an Object as one of the parameters.  

When submitting parameters am doing something similar to this:

"this is a string"
22.22 % VT_DOUBLE
23432 % VT_LONG
"this is a string"
'should this be a string?'
objectptr(VBsObjPtrLong)
'DLLError'(Severity,Module,Code,Message)
'KnownClassName'(parameter1,paramter2)  % And let our 
			%connector code _search for the most likely_ object
VB already holds in memory

new('KnownClassName'(parameter1,paramter2,...)) % Based on some contracted
constructor that VB will CreateObject (CoCreate) the correct class. and
Propput the parameters in iteratively. 

>   * be able to represent, as a Prolog term, (almost) any ActiveX data 
> value, preferably canonically, and convert to and from ActiveX 
> representation without loss of information

Some objects have a Parent that has itself as a child.. (and its siblings)
while serializing to prolog terms there needs to be a way to know how when
to walk up or down the hierarchy of recursive properties.. Might be fun to
use the ugraph system for representing each property (in case to properies
point to the same object. But not sure if two properies hold the same string
if they should point to the same atom in the graph? Ugraph representation
also makes simple everyday use tougher, however with a couple prolog
accessor predicates that can simplify it (flatten it out). Letting VB build
the arcs since its closer to the live objects.

> 
>   * handle callbacks and events (of limited use without these)
> 
> I say "almost" in case an incomplete but useful solution is 
> feasible (I want to actually put this to use in commercial projects).

Callbacks are weird, from what I gather a VB written interface would have to
have an activeX component itself subscribed to the 'event' and then invoke
the proper prolog code.  This is not very hard to do.. but it requires of
prolog is some checking in some toploop routine.  Which makes prolog
actively have to 'watch'.  On unix one could just have a thread listening.
What is the status of the Multithreading on NT?

> 
> Here are some enhancements I attempted:
> 
>   * cooperative garbage collection of ActiveX object refs by 
> linking to 
> SWI-Prolog's atom garbage collection

Now that seems like some work.  Most of the time, I thought, ActiveX objects
keep a count of their accesses and references.. But I understand you still
have to make a decision when you wanted to release them from your global
context.  Can we add trail_hooks or cut labels that tell when we are done
with the object?

> 
>   * avoid any use of SWI-Prolog "string" type (obsolescent)
> 
>   * handle arrays of more than one dimension, and with bounds 
> other than zero

really like your: array(LoBounds,Type,ListOfList...OfType)

> 
>   * handle Variants and Arrays of Variants (containing anything)
> 
> 
> Data conversions/representations:
> 
>   * String <-> atom
> 
>   * Boolean <-> @true, @false
> 
>   * Array(Type) <-> array(LoBounds,Type,ListOfList...OfType)
> 
>   * Date <-> date(Year,Mon,Day)+time(Hour,Min,Sec)
> 
>   * Currency <-> currency(Hi,Lo)
> 
>   * Variant.Empty <-> @empty
> 
>   * Variant.Null <-> @null
> 
>   * Variant.Decimal <-> decimal(Scale,Sign,Hi32,Mid32,Lo32)
> 
>   * Variant.Error <-> error(Severity,Facility,Code)
> 
>   * Nothing <-> @nothing
> 
> 
> Miscellaneous issues:
> 
>   * what to do with ByRef parameters?
> 
>   * SWI-Prolog atoms are (in general) arbitrary, non-textual byte 
> strings: conversion <-> String is not always appropriate
> 
> 
> Eventually I decided it might be smarter to leverage Visual 
> Basic 6.0, 

Definately

> which supports CallByName and CreateObject, and is memory-safe, and 
> catches all errors, but unfortunately it seems that calling 
> VB6 from C 
> is not properly supported (I found a Knowledge Base article 
> which gave 
> the very restricted circumstances in which it is safe, and gave up) 
> (again :-).

Pretty much it seems like everything you want to do, can be done in VB..
apart from connecting to VB itself.  That was why during my attempt i was
using SWIACTX like one would a network VPN to a more elaborated object
broker.

> 
> I'd gladly hand over what I've done, but it's not clear where 

I would like to look at it.  (I'll email you mine tommorow)

> it should 
> be going, or whether it can get anywhere sensible...
> 
> Paul Singleton