DrawShadowText API function

[Jules Marchildon]

Has anyone tried this API before?

I have the application themed WITH an XP manifest in the resource file.
I have the commoncontrol version 6 initialized...

..the output renders the correct colors, but the characters are showing up as solid bars
looks like non-printable characters, so I think its grabbing the wrong memory for the string.

DECLARE FUNCTION DrawShadowText LIB "COMCTL32.DLL" ALIAS "DrawShadowText" ( _
       BYVAL hdc      AS DWORD,_   'Handle to a device context (HDC).
       BYVAL lpszText AS LONG, _   'A pointer to a string that contains the text to be drawn
       BYVAL cch      AS LONG, _   'A UINT that specifies the number of characters in the string that is to be drawn
       BYVAL lprect   AS LONG,_    'A pointer to a RECT structure that contains, in logical coordinates, the rectangle in which the text is to be drawn.
       BYVAL dwFlags  AS DWORD,_   'A DWORD that specifies how the text is to be drawn.
       BYVAL crText   AS LONG,_    'A COLORREF structure that contains the color of the text. (RGB(255,0,78))
       BYVAL crShadow AS LONG,_    'A COLORREF structure that contains the color of the text shadow (RGB(255,0,255))
       BYVAL ixOffset AS LONG, _   'A value of type int that specifies the X coordinate of where the text should begin.
       BYVAL iyOffset AS LONG _    'A value of type int that specifies the Y coordinate of where the text should begin.
             ) AS LONG


      LOCAL hDC     AS DWORD
      LOCAL rc      AS RECT
      LOCAL szText  AS ASCIIZ*255
      LOCAL ps      AS PAINTSTRUCT
      
      SetRect rc, 10,10,200,40
      hdc = beginpaint(hwnd,ps)
          szText   = " Hello Shadow Text !"
          DrawShadowText hdc,VARPTR(szText),-1,VARPTR(rc),0,RGB(0,255,255),RGB(64,64,64),1,2
      endpaint hwnd,ps

thx.
regards,
Jules

[Edwin Knoppert]

Perfect over here, used as:

      Local hDC     As Dword
      Local rc      As RECT
      Local szText  As String
      Local ps      As PAINTSTRUCT
      
      SetRect rc, 10,10,200,40
      hdc = beginpaint(nCbHndl,ps)
          szText   = UCode$( " Hello Shadow Text !" )
          DrawShadowText hdc,StrPtr(szText),Len(szText) / 2,VarPtr(rc),0,RGB(0,255,255),RGB(64,64,64),1,2
      endpaint nCbHndl,ps
      Function = 1

Thanks, good tip!

[Jules Marchildon]

Thanks Edwin,
UCASE$() makes it work.
I've never come across this before. Hmm...
...does that mean this is a 32-bit OLE API or interface method?

added:
Casting in the original C code, "LPCWSTR" Long Pointer to Wide Character STRing.
I guess I missed that one, should the delcare be changed to DrawShadowTextW() ?

[José Roca]

should the delcare be changed to DrawShadowTextW() ?

No. There is not an ASCII version of this function, only unicode.

[Jules Marchildon]

Perfect, thanks Jose!

[Michael Mattias]

>>should the delcare be changed to DrawShadowTextW() ?

>No. There is not an ASCII version of this function, only unico

Actually, if it helps you remember you need a unicode text string, there is no reason not to either replace the standard DECLARE or add your own for procedure "DrawShadowTextW". Just don't change the ALIAS clause.
e.g.

DECLARE FUNCTION DrawShadowTextW LIB.. ALIAS "DrawShadowText" ...
...
   CALL DrawShadowTextW ( params)....

MCM

[Jeff Blakeney]

Personally, if that API can only be used with unicode strings, then I think the name should reflect that fact. As Michael shows, it is easy enough to add another declare or modify the existing one. The only thing is, if the API documentation only lists it without any identifier that it works with unicode only, which is most likely, then you might have difficulty finding the declare again later.

Looks like another example of Microsoft not following the rules.

[Michael Mattias]

Jeff, there are actually quite a few Windows APIs which are "unicode strings only" and are not named with a "W". A good example is most of the "Shell" functions, eg ShFileOperation. All the strings in that parameter block must be Unicode.

MCM

[Jeff Blakeney]

I'm sure there are a lot of API calls that don't specify that they only work with unicode. Microsoft is notorious for that sort of confusing behaviour.

I suppose, as long as the parameters and return value are specified as being unicode strings, then it probably isn't a huge problem but it would certainly be nice to tell at a glance at a piece of source code whether the call is unicode only or not.

[Michael Mattias]

You know, M/S may only use the "W" notation if there actually are two versions, an "A" and a "W."

The thing is, the "A" and "W" are generally not very obvious... you have to look in the detail SDK documentation to see if there are in fact separate ANSI and Unicode versions of a function, in which case the difference is only in the ALIAS used when defining the external.

MCM

[José Roca]

There are exceptions to the rule. For example, DsGetDcCloseW and SHOpenPropSheetW don't have an "A" version.

Also, although the C++ headers include prototypes for SHCreateFileExtractIconA and SHCreateFileExtractIconW, only SHCreateFileExtractIconW exists. There are more.

The only certain way is to check the list of exported functions.

[Michael Mattias]

> There are exceptions to the rule. For example, DsGetDcCloseW ...

Curious the exported names of all the "DsGetDcxxx" functions in netapi32.dll...

DsGetDcCloseW
DsGetDcNameA
DsGetDcNameW
DsGetDcNameWithAccountA
DsGetDcNameWithAccountW
DsGetDcNextA
DsGetDcNextW
DsGetDcOpenA
DsGetDcOpenW
DsGetDcSiteCoverageA
DsGetDcSiteCoverageW

.. and for the DsGetDcClose function, really curious since that has no string params nor does it return a string.

Well, there must have been some kind of rationale... wasn't there?

MCM