0

While working with the Win32API, the function i must use returns its results by writing them to buffer of type LPTSTR as well as the individual number of characters that were written.enter code here

As this buffer is a string, and the function can return multiple values, the actual result data look something like this:

Value1\0Value2\0Value3\0\0

What is the best way to get this into a QStringList?

Andrew
  • 1,344
  • 1
  • 12
  • 20

1 Answers1

0

LPTSTR = Long Pointer to TCHAR. On modern systems (those with unicode support) this is synonymous with a WCHAR array.

Since your output buffer will contain characters where each is two bytes it is thus compatible with UTF16.

QString has a fromUtf16 static method which requires a simple cast to satisfy the compiler.

In this case, we MUST also specify the total length of the entire string. Failure to do this results in QString only reading the input data up until the first null character, ignoring any other result data.

Once we actually have a QString to work with, splitting it is simple. Call QString's split() method specifying a null character wrapped in a QChar.

Optionally, and required in my case, specifying SplitBehavior as SkipEmptyParts ensures that no empty strings (the result of parsing the null character) end up in my desired result (the QStringList of values).

Example:

// The data returned by the API call.
WCHAR *rawResultData = L"Value1\0Value2\0Value3\0";

// The number of individual characters returned.
quint64 numberOfWrittenCharacters = 22;

// Create a QString from the returned data specifying
// the size.
QString rString = 
QString::fromUtf16((const ushort *)rawResultData, numberOfWrittenCharacters);

// Finally, split the string into a QStringList
// ignoring empty results.
QStringList results = 
rString.split(QChar(L'\0'), QString::SkipEmptyParts);
Andrew
  • 1,344
  • 1
  • 12
  • 20
  • 1
    No, `LPTSTR` is `TCHAR*` where `TCHAR` is `char` or `wchar_t` depending on a conditional define. So your code is quite wrong. I cannot understand why you would want to use `TCHAR`. It was useful when you needed to target a system without Unicode, e.g. Windows 98. Those days are long gone. – David Heffernan Mar 12 '16 at 15:20
  • @IInspectable Fixed, Thank you! – Andrew Mar 12 '16 at 16:09
  • @David Heffernan A while back when i was learning about how strings were handled in the WinAPI i came across this: http://stackoverflow.com/questions/234365/is-tchar-still-relevant From what i understood there was no actual PROBLEM with using TCHAR, it was just the "older" way to do things. Are you suggesting using WCHAR exclusively as that is the current modern standard? Other than defining rawResultData as TCHAR*, what else is wrong? Thanks for your help! – Andrew Mar 12 '16 at 16:16
  • Do you want to use ANSI? If not, don't make the code more complex by using `TCHAR`. Use `wchar_t`. – David Heffernan Mar 12 '16 at 16:19
  • @David Heffernan Understood! I've made a few edits. Let me know if it is now correct. – Andrew Mar 12 '16 at 16:29
  • Nope. `TCHAR` is `wchar_t` or `char` as determined by a compiler option. You use `TCHAR` when you want to be able to compiler in either mode. There is no place for `TCHAR` here at all. – David Heffernan Mar 12 '16 at 16:32
  • `TCHAR` is not defined by the system. It is defined by the compiler. Modern systems (and that really is any release of Windows NT dating back to Windows NT 3.1, released in 1993) internally use Unicode (UTF-16LE). While the API still provides ANSI versions, those merely convert from ANSI to Unicode and back, and are essentially extra work for no benefit. Just use Unicode throughout, i.e. `wchar_t` and APIs with a trailing `W` (e.g. `MessageBoxW`). – IInspectable Mar 12 '16 at 16:33