Is it just me, or is windows.d badly incomplete?  It knows nothing about GDI or User, is missing pretty much everything that's not in Kernel.

winsamp.d sample won't build, either.

Sean

"Sean L. Palmer" <seanpalmer@earthlink.net> wrote in message news:acss9j$2ime$1@digitaldaemon.com...

> Is it just me, or is windows.d badly incomplete?  It knows nothing about
GDI
> or User, is missing pretty much everything that's not in Kernel.
>
> winsamp.d sample won't build, either.

It depends on whether you use Walter's windows.d (incomplete but correct),
or my (much bigger but with lots of bugs and not 100% compatible with
Walter's). I would recommend to use Walter's, and add your functions
where appropriate. This way, we'll (hopefully) get a complete, hand-crafted,
API translation.

Alternatively, if somebody is aware of a language with _typed_ constants, and with lack of macros support (or with no use of it in the appropriate headers), which has API declarations translated for it, I'd glad to give it another try in writing a translator.

"Sean L. Palmer" <seanpalmer@earthlink.net> wrote in message news:acss9j$2ime$1@digitaldaemon.com...
> Is it just me, or is windows.d badly incomplete?  It knows nothing about
GDI
> or User, is missing pretty much everything that's not in Kernel.
>
> winsamp.d sample won't build, either.

It's badly incomplete. Mainly because I've been too lazy to finish it.

"Sean L. Palmer" <seanpalmer@earthlink.net> wrote in news:acss9j$2ime$1@digitaldaemon.com:

> Is it just me, or is windows.d badly incomplete?  It knows nothing about GDI or User, is missing pretty much everything that's not in Kernel.
> 
> winsamp.d sample won't build, either.
> 
> Sean
> 
> 

I took Pavel Minayev's windows.d file and renamed it pwindows.d Then I modified it to include Walter's windows.d file and fixed all the resulting errors.  As Walter's windows.d file grows I go in and comment out sections of the pwindows.d file that conflict and I fix my code that uses it.

The main question for me with a good windows.d file is what to do
with the ascii/unicode issue.  For now I've been directly using the
fuction names like RegisterClassExA or CreateWindowExA.  However
I like the idea of being able to build an ascii or unicode version
from the same source.  The only way I can see this working is with
things like...

version(ascii)
{
  alias RegisterClassExA RegisterClassEx;
  alias CreateWindowExA CreateWindowEx;
}
version(unicode)
{
  alias RegisterClassExW RegisterClassEx;
  alias CreateWindowExW CreateWindowEx;
}

"Patrick Down" <pat@codemoon.com> wrote in message news:Xns921B8F7C29050patcodemooncom@63.105.9.61...
> I took Pavel Minayev's windows.d file and renamed it pwindows.d Then I modified it to include Walter's windows.d file and fixed all the resulting errors.  As Walter's windows.d file grows I go in and comment out sections of the pwindows.d file that conflict and I fix my code that uses it.
>
> The main question for me with a good windows.d file is what to do
> with the ascii/unicode issue.  For now I've been directly using the
> fuction names like RegisterClassExA or CreateWindowExA.  However
> I like the idea of being able to build an ascii or unicode version
> from the same source.  The only way I can see this working is with
> things like...
>
> version(ascii)
> {
>   alias RegisterClassExA RegisterClassEx;
>   alias CreateWindowExA CreateWindowEx;
> }
> version(unicode)
> {
>   alias RegisterClassExW RegisterClassEx;
>   alias CreateWindowExW CreateWindowEx;
> }

Aliases work for types, but not for function names (perhaps this should be an enhancement). You could create a function CreateWindowEx() overloaded for unicode and ascii arguments, and all it does is wrap a call to the W or A version.

Can you alias a function declaration like that?  It'd be nice to be able to provide an alternate name for a function.  I suppose one could always provide a simple wrapper but that'd lose performance.

Sean

"Patrick Down" <pat@codemoon.com> wrote in message news:Xns921B8F7C29050patcodemooncom@63.105.9.61...

> I took Pavel Minayev's windows.d file and renamed it pwindows.d Then I modified it to include Walter's windows.d file and fixed all the resulting errors.  As Walter's windows.d file grows I go in and comment out sections of the pwindows.d file that conflict and I fix my code that uses it.
>
> The main question for me with a good windows.d file is what to do
> with the ascii/unicode issue.  For now I've been directly using the
> fuction names like RegisterClassExA or CreateWindowExA.  However
> I like the idea of being able to build an ascii or unicode version
> from the same source.  The only way I can see this working is with
> things like...
>
> version(ascii)
> {
>   alias RegisterClassExA RegisterClassEx;
>   alias CreateWindowExA CreateWindowEx;
> }
> version(unicode)
> {
>   alias RegisterClassExW RegisterClassEx;
>   alias CreateWindowExW CreateWindowEx;
> }

"Walter" <walter@digitalmars.com> wrote in news:acu12k$25q5$1@digitaldaemon.com:
>> version(ascii)
>> {
>>   alias RegisterClassExA RegisterClassEx;
>>   alias CreateWindowExA CreateWindowEx;
>> }
>> version(unicode)
>> {
>>   alias RegisterClassExW RegisterClassEx;
>>   alias CreateWindowExW CreateWindowEx;
>> }
> 
> Aliases work for types, but not for function names (perhaps this should be an enhancement). You could create a function CreateWindowEx() overloaded for unicode and ascii arguments, and all it does is wrap a call to the W or A version.

I didn't know that about alias.  I though it was a generic renaming mechanism.  However the overloading the function is a better idea anyway.

"Walter" <walter@digitalmars.com> wrote in message news:acu12k$25q5$1@digitaldaemon.com...
> Aliases work for types, but not for function names (perhaps this should be
> an enhancement). You could create a function CreateWindowEx() overloaded
for
> unicode and ascii arguments, and all it does is wrap a call to the W or A version.

I've been doing this version(unicode) wrapping stuff and it's very tedious. The process would be immensely easier if alias worked for functions (and maybe even variables!) in addition to types, because that's what they're using #define for in WinUser.h.

Really it should be generalized so that alias just makes an "alternate" identifier that something should be known by.  That would take care of one of the big uses for icky macros in C.

If you integrate with and alias together you have something very cool:

struct pixel
{
  ubyte r,g,b,a;
}

{
  pixel [][] image;
  for (int i = 0; i<image.length; ++i)
    for (int j = 0; j<image[i].length; ++j)
    {
       alias image[i][j] curpixel;
       curpixel.r = curpixel.g * curpixel.b + curpixel.a;
    }
}

The alias version doesn't introduce ambiguity or possible symbol clashes because it doesn't pull stuff into the current scope, it just makes one new identifier that acts like a scope and/or expression shortcut.

Sean

Hmm, you're also extending alias to include expression fragments!

"Sean L. Palmer" <seanpalmer@earthlink.net> wrote in message news:acu7fl$2j1i$1@digitaldaemon.com...
> Really it should be generalized so that alias just makes an "alternate" identifier that something should be known by.  That would take care of one of the big uses for icky macros in C.
>
> If you integrate with and alias together you have something very cool:
>
> struct pixel
> {
>   ubyte r,g,b,a;
> }
>
> {
>   pixel [][] image;
>   for (int i = 0; i<image.length; ++i)
>     for (int j = 0; j<image[i].length; ++j)
>     {
>        alias image[i][j] curpixel;
>        curpixel.r = curpixel.g * curpixel.b + curpixel.a;
>     }
> }
>
> The alias version doesn't introduce ambiguity or possible symbol clashes because it doesn't pull stuff into the current scope, it just makes one
new
> identifier that acts like a scope and/or expression shortcut.
>
> Sean
>
>

"Sean L. Palmer" <seanpalmer@earthlink.net> wrote in message news:acu3qf$2fn4$1@digitaldaemon.com...
> Can you alias a function declaration like that?  It'd be nice to be able
to
> provide an alternate name for a function.  I suppose one could always provide a simple wrapper but that'd lose performance.

The simple wrapper won't lose performance because it gets inlined.