> > the name I proposed is related to MSDN syntax and to ms libs. > To be clear in MSDN function: > CreateCompatibleDC() is defined: > > Requirements > Windows NT/2000/XP/Vista: Included in Windows NT 3.1 and later. > Windows 95/98/Me: Included in Windows 95 and later. > Header: Declared in Wingdi.h; include Windows.h. > Library: Use Gdi32.lib. > > > Instead GetPixelFormatSize() is defined: > > Function Information > Header Declared in GdiplusPixelFormats.h, include gdiplus.h > Import library gdiplus.lib > Minimum availability GDI+ 1.1 > Minimum operating systems Windows 98, Windows XP, Windows 2000, Windows NT > 4.0 SP6 > > so following ms docs you can know where they have to be included and > filename to be adopted (in above samples first is wapi_gdi32.c, the second > is wapi_gdiplus.c).
> So I repeat my proposal to follow MS docs in file names. Thanks for clarifying, I still agree with you. > What it means "will accept parameters in the same order and types, >> including structures" ? Referring to ms docs or between them ? >> > I suppose ms docs. > > One problem I recall in mind is about length parameters. > There are some win functions that have length parameters (mostly with > string parameters) that, in many wrappers I have seen, is dropped because we > have hb_parclen() that returns string length. > In this case I prefer to follow ms syntax checking presence of above > parameters using i.e.: > dwLen = ( ISNIL( 6 ) ? hb_parclen( 5 ) : hb_parnl( 6 ) ) If you ask me, I'd rather fully ignore the explicitly passed length parameter, as the only result of that is potential buffer overrun and big security holes (and/or more complicated and bug-prone interface code) potentially resulting in easy to make fatal mistakes on the .prg level. I've fixed FWRITE() and BASE64() conversion just recently in this regard. Anyhow if someone doesn't want to pass the full string, we have 'LEFT()' there to help, and there is little point in replicating this functionality in each API functions. IMO. Generally speaking, while keeping a more or less transparent WINAPI layer, we should also try to blend into the Harbour language as much as possible. Not being a hardcore WINAPI user for me it's difficult to tell any specifics, but it's probably a matter of balancing between what feels natural for a Harbour programmer while giving a straight as possible WINAPI interface. If in doubt I'd personally in all cases prefer to favour the "Harbour feel". "Harbour feel" means that .prg programmer shouldn't be able to cause a GPF/memory corruption using .prg level WINAPI calls. Brgds, Viktor
_______________________________________________ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
