From paul.singleton@bcs.org.uk Fri Sep 28 11:53:29 2001
Received: from cmailg2.svr.pol.co.uk (cmailg2.svr.pol.co.uk [195.92.195.172])
	by swi.psy.uva.nl (8.11.2/8.11.2) with ESMTP id f8S9rTv25970
	for <prolog@swi.psy.uva.nl>; Fri, 28 Sep 2001 11:53:29 +0200 (MET DST)
Received: from modem-49.erythromycin.dialup.pol.co.uk ([62.136.93.49] helo=bcs.org.uk)
	by cmailg2.svr.pol.co.uk with esmtp (Exim 3.13 #0)
	id 15muKU-0006W2-00; Fri, 28 Sep 2001 10:53:10 +0100
X-Mozilla-Status: 0801
Message-ID: <3BB32DF9.1080006@bcs.org.uk>
Date: Thu, 27 Sep 2001 14:47:37 +0100
From: Paul Singleton <paul.singleton@bcs.org.uk>
User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-GB; rv:0.9.2) Gecko/20010726 Netscape6/6.1
X-Accept-Language: en-gb
MIME-Version: 1.0
To: Philip Warner <pjw@rhyme.com.au>
CC: SWI Mailing List <prolog@swi.psy.uva.nl>
Subject: Re: [SWIPL] Extensions to ActiveX DLL
References: <3.0.5.32.20010927223155.0226f600@mail.rhyme.com.au>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Philip Warner wrote:

> 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. 


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 came to realise, 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

  * 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

  * 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).

Here are some enhancements I attempted:

  * cooperative garbage collection of ActiveX object refs by linking to 
SWI-Prolog's atom garbage collection

  * avoid any use of SWI-Prolog "string" type (obsolescent)

  * handle arrays of more than one dimension, and with bounds other than 
zero

  * 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, 
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 :-).

I'd gladly hand over what I've done, but it's not clear where it should 
be going, or whether it can get anywhere sensible...

Paul Singleton


