On 24/10/2020 21:41, HamApps Support
(VK3AMA) wrote:
As for the UTF-8 naming issue, I
am investigating why that is occurring. The underlying code
that retrieves all the audio endpoints defined on the PC fully
supports UTF-8. Something is being lost in getting that data
over to the main JTAlert executable.
de Laurie VK3AMA
Hi Laurie,
this may not be relevant and your comment above just be using
incorrect terminology, but wide-strings in Windows are not
utf-8, they are 16-bit characters encoded with utf-16
little-edian Unicode values. You might convert them to
multi-byte Unicode strings, utf-8 for example, to send over the
network, store in a file, or other space constrained media.
--
73
Bill
G4WJS.
Tnx Bill,
My head starts hurting every-time I have to start thinking about
ANSI, ASCII, UTF-8, Unicode, codepages, multi-byte versus
single-byte strings, etc, etc.
With respect to this sound device name problem. The strings
returned from enumerating the endpoints are variable-length
encoded UTF-8, but it was getting those strings over to JTAlert
that was the issue. The AutoIT based string comparison routines of JTAlert were not
UTF-8 compatible, combined with legacy XP era winmm.dll calls
conspired to bring on a migraine! Its my own fault for clinging
onto the old AutoIT code base for so long and trying to be clever
integrating .NET code. Code refactoring is currently underway
