Advertisement
If you have a new account but are having problems posting or verifying your account, please email us on hello@boards.ie for help. Thanks :)
Hello all! Please ensure that you are posting a new thread or question in the appropriate forum. The Feedback forum is overwhelmed with questions that are having to be moved elsewhere. If you need help to verify your account contact hello@boards.ie
Hi there,
There is an issue with role permissions that is being worked on at the moment.
If you are having trouble with access or permissions on regional forums please post here to get access: https://www.boards.ie/discussion/2058365403/you-do-not-have-permission-for-that#latest

windows sdk - naming convention

  • 08-11-2003 12:27am
    #1
    CH
    Closed Accounts Posts: 358 ✭✭


    anyone know why some methods in the windows sdk end with a capital "A".

    thanks.


Comments

  • #2
    dazberry
    Registered Users, Registered Users 2 Posts: 2,152 ✭✭✭dazberry


    Relates to parameters:

    A signifies a call that supports 8 bit ANSI characters.
    W signifies a call that supports wide strings (unicode) or 16 bit characters.

    Depending on what you're using there may be a third call, but that normally just maps to the A call.

    D.


  • #3
    casper-
    Closed Accounts Posts: 437 ✭✭casper-


    Yes, and to save yourself some time, you can just add UNICODE to your project preprocessor definitions list and auto-switch to the 'W' versions. Pretty much every method has three names,

    GetWindowText
    GetWindowTextA
    GetWIndowTextW

    The first one is just a #define that maps to either the Ansi or Wide version. Normally you don't think about this, but when you do turn on Unicode and have to support Win98 you'll find yourself sometimes having to call the 'A' methods explicitly since unicows is not a complete layer.


  • #4
    Talliesin
    Closed Accounts Posts: 9,314 ✭✭✭Talliesin


    Originally posted by jedidjab79
    Normally you don't think about this, but when you do turn on Unicode and have to support Win98 you'll find yourself sometimes having to call the 'A' methods explicitly since unicows is not a complete layer.

    Another possibility is to do two builds, one with Unicode and _Unicode defined, and one without, and then put both versions into the installer and let the installer decide which version to install.

    NT/2000/XP will support the 'A' versions, 95/98/ME will support some of the 'W' versions. To make matters worse which functions 9x will support the W versions for depend on the version of IE installed.

    To make matters even more confusing whether "Unicode" means UCS-2 or UTF-16 is rather ill-defined as well, granted it doesn't really matter for a lot of functions or for a lot of calling code, but it can be a right nuisance when it does matter.


Advertisement