'ANSI' directive added to local external functions when migrating with PFC

[Rick]

We have a PFC PB 9 app that we just migrated to PB 11. In both
pfc_n_cst_platformwin32 and pfc_n_cst_platformunicode there's a Local
External Function called GetUserNameA that we use to get the username
from the operating system. I just noticed that when Powerbuilder
migrated the app to PB 11, it appended an ALIAS FOR clause ("for
backward compatibility") as well as an ";ansi" directive to the
function definition. Turns out that with this ANSI directive, the
function now no longer works; it returns only the first character of
the username. Any thoughts on why this happened and what I can do
about it? Thanks much. (This is my first experience with PFC!)

[Jeremy Lakeman]

Generally in the windows API if there's an A at the end of the method
name change it to a W or append ;ansi to an alias.

eg;
function boolean GetUserNameW(ref string lpBuffer, ref ulong nSize)
library "ADVAPI32.DLL"

But really you should download the latest version of the pfc framework
to include other enhancements and bugfixes that have been made.

[Rick]

Thanks; I just realized I incorrectly indicated GetUserNameA in my
message -- the script actually uses does use GetUserNameW. The
migration to PB 11 appended the ;ANSI directive which causes it to not
work -- it only returns the first character of the user name. When I
remove the ;ANSI directive it then works fine.

I guess the two things I'm wondering about are: why does the migration
add the ;ANSI directive, and why does that directive cause it to not
work?

[Jeremy Lakeman]

Because the unicode platform class was not used in an ansi version of
PB. And the migrate process adds ansi to all external functions with
string parameters.

[Rick]

Thanks. So is my best course of action to simply delete the ";ansi"
references?

> string parameters.- Hide quoted text -
>
> - Show quoted text -