Announcement

Collapse
No announcement yet.

DrawShadowText API function

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • DrawShadowText API function

    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.

    Code:
    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
    Best regards
    Jules
    www.rpmarchildon.com

  • #2
    Perfect over here, used as:
    Code:
          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!
    hellobasic

    Comment


    • #3
      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() ?
      Last edited by Jules Marchildon; 16 Aug 2009, 02:15 PM.
      Best regards
      Jules
      www.rpmarchildon.com

      Comment


      • #4
        should the delcare be changed to DrawShadowTextW() ?
        No. There is not an ASCII version of this function, only unicode.
        Forum: http://www.jose.it-berater.org/smfforum/index.php

        Comment


        • #5
          Perfect, thanks Jose!
          Best regards
          Jules
          www.rpmarchildon.com

          Comment


          • #6
            >>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.
            Code:
            DECLARE FUNCTION DrawShadowTextW LIB.. ALIAS "DrawShadowText" ...
            ...
               CALL DrawShadowTextW ( params)....
            MCM
            Michael Mattias
            Tal Systems (retired)
            Port Washington WI USA
            [email protected]
            http://www.talsystems.com

            Comment


            • #7
              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.
              Jeff Blakeney

              Comment


              • #8
                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
                Michael Mattias
                Tal Systems (retired)
                Port Washington WI USA
                [email protected]
                http://www.talsystems.com

                Comment


                • #9
                  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.
                  Jeff Blakeney

                  Comment


                  • #10
                    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
                    Michael Mattias
                    Tal Systems (retired)
                    Port Washington WI USA
                    [email protected]
                    http://www.talsystems.com

                    Comment


                    • #11
                      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.
                      Forum: http://www.jose.it-berater.org/smfforum/index.php

                      Comment


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

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

                        Code:
                        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
                        Michael Mattias
                        Tal Systems (retired)
                        Port Washington WI USA
                        [email protected]
                        http://www.talsystems.com

                        Comment

                        Working...
                        X