Maybe it's too simple or I've lost practice (lack of spare time), but what
should I add to my program to use SetConsoleTextAttribute() and
GetStdHandle()? Thanks in advance.

Go to Pavel's DedicateD site and get his Windows.d api wrapper.  It's much more complete than the one that comes with the D compiler.

Sean

"Carlos" <carlos8294@msn.com> wrote in message news:ae632a$l6v$1@digitaldaemon.com...
> Maybe it's too simple or I've lost practice (lack of spare time), but what
> should I add to my program to use SetConsoleTextAttribute() and
> GetStdHandle()? Thanks in advance.

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

> Go to Pavel's DedicateD site and get his Windows.d api wrapper.  It's much more complete than the one that comes with the D compiler.

And also much more buggy... but that's another story.

In general, unless you use MANY API functions, I highly recommend that you write prototypes for them yourself, and then submit whatever you get to Walter for inclusion into his windows.d. Not only your code will be cleaner, but we will also get a hand-crafted WinAPI import file at some point in the future.

I say just take yours (minus the parts that conflict with Walter's) and just fix the bugs that turn up.

Otherwise Walter will never get around to it.  That's a LOT of headers to go through and fix up and convert.

Sean

"Pavel Minayev" <evilone@omen.ru> wrote in message news:ae710s$1k2e$1@digitaldaemon.com...
> "Sean L. Palmer" <seanpalmer@earthlink.net> wrote in message news:ae6pkd$1bem$1@digitaldaemon.com...
>
> > Go to Pavel's DedicateD site and get his Windows.d api wrapper.  It's
much
> > more complete than the one that comes with the D compiler.
>
> And also much more buggy... but that's another story.
>
> In general, unless you use MANY API functions, I highly recommend that you write prototypes for them yourself, and then submit whatever you get to Walter for inclusion into his windows.d. Not only your code will be cleaner, but we will also get a hand-crafted WinAPI import file at some point in the future.

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

> I say just take yours (minus the parts that conflict with Walter's) and
just
> fix the bugs that turn up.
>
> Otherwise Walter will never get around to it.  That's a LOT of headers to
go
> through and fix up and convert.

There are a few problems that need to be solved first. The biggest one is
that Phobos won't compile with my windows.d, due to some type differences.
For example, my version assumes HANDLE it an uint (because it originates
from
Pascal unit), while Walter correctly defines it as void*. As the result, you
cannot use "null" whenever a null handle is required in my version, but have
to employ 0 (or the NULL constant), while Walter's version requires null...

"Sean L. Palmer" <seanpalmer@earthlink.net> escribió en el mensaje news:ae6pkd$1bem$1@digitaldaemon.com...
> Go to Pavel's DedicateD site and get his Windows.d api wrapper.  It's much more complete than the one that comes with the D compiler.
>
> Sean
>
are SetConsoleTextAttribute() and GetStdHandle() already implemented?
because i can't get them to work...

"Carlos" <carlos8294@msn.com> escribió en el mensaje news:aelghu$act$2@digitaldaemon.com...
>
> "Sean L. Palmer" <seanpalmer@earthlink.net> escribió en el mensaje news:ae6pkd$1bem$1@digitaldaemon.com...
> > Go to Pavel's DedicateD site and get his Windows.d api wrapper.  It's
much
> > more complete than the one that comes with the D compiler.
> >
> > Sean
> >
> are SetConsoleTextAttribute() and GetStdHandle() already implemented?
> because i can't get them to work...
>
>

ok, sorry. my mistake. they do work. this is what happened: i made a test program and named it color. so when i ran it, nothing happened. obviously! win xp (don't know if 2000 or nt have) has a color command itself!

> > > Go to Pavel's DedicateD site and get his Windows.d api wrapper.  It's
> >

I'm using Pavel's file, but I get these errors. What's wrong with this code?

void gotoxy(int x, int y) {
    COORD c;
    c.X = x - 1;
    c.Y = y - 1;
    SetConsoleCursorPosition (GetStdHandle(STD_OUTPUT_HANDLE), c);
}

by itself, it generates an error (Error 42: Symbol Undefined _SetConsoleCursorPosition@12). what does the @ mean? it's not the line number...

Almost the same happens here: (Error 42: Symbol Undefined
_FillConsoleOutputCharacterW@24)

void clrscr() {
    COORD coord;
    DWORD written;
    CONSOLE_SCREEN_BUFFER_INFO info;

    coord.X = 0;
    coord.Y = 0;
    GetConsoleScreenBufferInfo(GetStdHandle(STD_OUTPUT_HANDLE), &info);
    FillConsoleOutputCharacterW (GetStdHandle(STD_OUTPUT_HANDLE), ' ',
        info.dwSize.X * info.dwSize.Y, coord, &written);
    gotoxy (1, 1);
}

And while this works fine...

int wherex() {
    CONSOLE_SCREEN_BUFFER_INFO info;
    GetConsoleScreenBufferInfo(GetStdHandle(STD_OUTPUT_HANDLE), &info);
    return info.dwCursorPosition.X;
}

this doesn't...

int wherey() {
    CONSOLE_SCREEN_BUFFER_INFO info;
    GetConsoleScreenBufferInfo(GetStdHandle(STD_OUTPUT_HANDLE), &info);
    return info.dwCursorPosition.Y - 2;
}

Why?

Now that's funny.  ;)

Sean

"Carlos" <carlos8294@msn.com> wrote in message news:aeljej$dh8$1@digitaldaemon.com...
>
> "Carlos" <carlos8294@msn.com> escribió en el mensaje news:aelghu$act$2@digitaldaemon.com...
> >
> > "Sean L. Palmer" <seanpalmer@earthlink.net> escribió en el mensaje news:ae6pkd$1bem$1@digitaldaemon.com...
> > > Go to Pavel's DedicateD site and get his Windows.d api wrapper.  It's
> much
> > > more complete than the one that comes with the D compiler.
> > >
> > > Sean
> > >
> > are SetConsoleTextAttribute() and GetStdHandle() already implemented?
> > because i can't get them to work...
> >
> >
>
> ok, sorry. my mistake. they do work. this is what happened: i made a test program and named it color. so when i ran it, nothing happened. obviously! win xp (don't know if 2000 or nt have) has a color command itself!

You would also have to link with the Windows DLL which implements GetConsoleScreenBufferInfo and FillConsoleOutputCharacterW.  I believe that's kernel32.dll... so you need an import library kernel32.lib.  Luckily it's distributed with D (or should be... on Pavel's site same place as the windows.d if not).

Some kind of command like:

c:\dmd\bin\dmd.exe myapp.d kernel32.lib

It really doesn't get much simpler than that.  Maybe have modules (in Windows version of D at least) give some signal to link.exe that it should link in some .LIB file or .OBJ file or multiple ones during link phase.  I would *love* the ability to embed that information in the language somehow (some kind of "link" keyword might even be nice).  Isn't linking universal? You always have to link.  So we can embed the concept of linkage into our programs as a language construct.  If you don't do it there you end up needing some kind of external file for the same info anyway (.makefile) which is not central to the point where integration is known (in the .OBJ files that the linker is manipulating is embedded commands to it passed thru by the compiler from the source code.) Maybe set it up so you can drag the pretty *.D files' icons onto the pretty DMD.EXE icon to compile and run it. Something your grandmother could accomplish.

Then newbie questions could easily be avoided by having windows.d automatically cause linkage with kernel32.lib (and gdi32.lib, and user32.lib, and oleaut64e.lib these days).  Not that it's a problem really... it would be nice to see more new faces around here.  ;)

D would be pretty easy to learn, probably about as hard as pascal to master. I think it would make a really good first language if only it were more seasoned.  Language is not even beta yet.  And by the time of D 2.0 it might be a more developed language, a bit harder to master but a much better day-to-day tool.  I don't care what is elegant; a compiler is a tool for the programmer and serves only to make his job (and life!) easier if that's at all possible.  Without having to remember all kinds of little trivia about what header links with what dll.

Walter:  what is the release timetable for D 1.0?  When is beta and release scheduled?   Maybe so we can start debating D 2.0   ;)  Seriously this seems to be gelling... a few bugs and maybe some more optimizations (don't want to make D look bad right off the bat by being the "slow" language) but otherwise the compiler seems pretty solid and getting quite to the point of stopping adding features to D 1.0.  Unless anyone knows of anything seriously lacking in the language at present which needs immediate addressing.

Sean

"Carlos" <carlos8294@msn.com> wrote in message news:aelp0m$imq$1@digitaldaemon.com...
> > > > Go to Pavel's DedicateD site and get his Windows.d api wrapper.
It's
> > >
>
> I'm using Pavel's file, but I get these errors. What's wrong with this
code?
>
> void gotoxy(int x, int y) {
>     COORD c;
>     c.X = x - 1;
>     c.Y = y - 1;
>     SetConsoleCursorPosition (GetStdHandle(STD_OUTPUT_HANDLE), c);
> }
>
> by itself, it generates an error (Error 42: Symbol Undefined _SetConsoleCursorPosition@12). what does the @ mean? it's not the line number...
>
> Almost the same happens here: (Error 42: Symbol Undefined
> _FillConsoleOutputCharacterW@24)
>
> void clrscr() {
>     COORD coord;
>     DWORD written;
>     CONSOLE_SCREEN_BUFFER_INFO info;
>
>     coord.X = 0;
>     coord.Y = 0;
>     GetConsoleScreenBufferInfo(GetStdHandle(STD_OUTPUT_HANDLE), &info);
>     FillConsoleOutputCharacterW (GetStdHandle(STD_OUTPUT_HANDLE), ' ',
>         info.dwSize.X * info.dwSize.Y, coord, &written);
>     gotoxy (1, 1);
> }
>
> And while this works fine...
>
> int wherex() {
>     CONSOLE_SCREEN_BUFFER_INFO info;
>     GetConsoleScreenBufferInfo(GetStdHandle(STD_OUTPUT_HANDLE), &info);
>     return info.dwCursorPosition.X;
> }
>
> this doesn't...
>
> int wherey() {
>     CONSOLE_SCREEN_BUFFER_INFO info;
>     GetConsoleScreenBufferInfo(GetStdHandle(STD_OUTPUT_HANDLE), &info);
>     return info.dwCursorPosition.Y - 2;
> }
>
> Why?