Walter,

Having had very little trouble getting the basic direct draw com interfaces to work from D, I though I'd have a play at getting something a bit more meaty working.

I noticed a few places with
structs like this in the MS idl files

typedef struct tagCUSTDATA {
    DWORD cCustData;            /* number of custom data items in rgCustData
*/
    [size_is(cCustData)] LPCUSTDATAITEM prgCustData;
                                /* array of custom data items */
} CUSTDATA, * LPCUSTDATA;

I've been changing it to
struct CUSTDATA {
    DWORD cCustData;            /* number of custom data items in rgCustData
*/
  LPCUSTDATAITEM prgCustData;
                                /* array of custom data items */
}
alias CUSTDATA * LPCUSTDATA;

BUT was not sure if (due to the size being just before the ptr) I could be a
little more "D"
struct CUSTDATA {
 CUSTDATAITEM[] prgCustData;
}

which started me thinking, on your search for a killer app, easier COM
programming might be a very good selling point for D, the small amount I've
done so far its a shallower learning curve than C or C++.
as I see it one improvement would be arrays
being able to define the above in some so
CUSTDATA cd;
cd.prgCustData = new CUSTDATAITEM[n];
works as expected.
and some solution to the usual C way of doing
typedef struct foo_s {
    int length; item[1] data
}FOO, * LPFOO;

LPFOO myarray = (LPFOO)malloc( sizeof(FOO) + len*sizeof(item));
myarray.length = len;

or even (getting OT) a variable syntax directive
{%idl%{
        ..... structs and interfaces in idl
}}
obviously dreaming here (VOT) but I'd want it to load idl.dll to parse and
generate the AST/DAG
so I could write
{%mine%{
        some strange syntax
}}
and have mine.dll process and generate the AST.

I initially considered rewriting the types to be more D like, but eventually came to the conclusion it was  a mistake. One reason is it's just impractical to try and duplicate Microsoft's COM documentation for all those gazillion API functions, while changing the argument types.


"Mike Wynn" <mike.wynn@l8night.co.uk> wrote in message news:bgc4e9$1smu$1@digitaldaemon.com...
> Walter,
>
> Having had very little trouble getting the basic direct draw com
interfaces
> to work from D, I though I'd have a play at getting something a bit more meaty working.
>
> I noticed a few places with
> structs like this in the MS idl files
>
> typedef struct tagCUSTDATA {
>     DWORD cCustData;            /* number of custom data items in
rgCustData
> */
>     [size_is(cCustData)] LPCUSTDATAITEM prgCustData;
>                                 /* array of custom data items */
> } CUSTDATA, * LPCUSTDATA;
>
> I've been changing it to
> struct CUSTDATA {
>     DWORD cCustData;            /* number of custom data items in
rgCustData
> */
>   LPCUSTDATAITEM prgCustData;
>                                 /* array of custom data items */
> }
> alias CUSTDATA * LPCUSTDATA;
>
> BUT was not sure if (due to the size being just before the ptr) I could be
a
> little more "D"
> struct CUSTDATA {
>  CUSTDATAITEM[] prgCustData;
> }
>
> which started me thinking, on your search for a killer app, easier COM programming might be a very good selling point for D, the small amount
I've
> done so far its a shallower learning curve than C or C++.
> as I see it one improvement would be arrays
> being able to define the above in some so
> CUSTDATA cd;
> cd.prgCustData = new CUSTDATAITEM[n];
> works as expected.
> and some solution to the usual C way of doing
> typedef struct foo_s {
>     int length; item[1] data
> }FOO, * LPFOO;
>
> LPFOO myarray = (LPFOO)malloc( sizeof(FOO) + len*sizeof(item));
> myarray.length = len;
>
> or even (getting OT) a variable syntax directive
> {%idl%{
>         ..... structs and interfaces in idl
> }}
> obviously dreaming here (VOT) but I'd want it to load idl.dll to parse and
> generate the AST/DAG
> so I could write
> {%mine%{
>         some strange syntax
> }}
> and have mine.dll process and generate the AST.
>
>
>
>
>
>
>
>
>