locked Re: Strange UI phenomenon


HamApps Support (VK3AMA)
 

On 25/10/2020 8:25 am, g4wjs wrote:
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

de Laurie VK3AMA

Join Support@HamApps.groups.io to automatically receive all group messages.