Re: [Audacity-devel] New features commited (Unicode)

[Vaughan J. <va...@au...>]

Markus Meyer wrote:

> Vaughan Johnson schrieb:
>
>> 1) string literals. Many places in the code, there are implicit 
>> concatenations, where for readability, a string is split across 
>> multiple lines, e.g.:
>>
>>         wxMessageBox(_("CleanSpeech only allows recording mono track.\n"
>>                        "Recording not possible when more than one 
>> window open."),
>>                        _("Recording not permitted"),
>>                        wxOK | wxICON_INFORMATION,
>>                        this);
>>
>> This compiles fine in MSVC for Debug or Release build, but not Unicode:
>
>
> No idea about this. Works fine on GCC for me.


There's another way, I didn't know about, just using backslash. From 
MSVC "C Language Reference":

        "Long strings can be bro\
        ken into two or more pieces."

    is identical to the string

        "Long strings can be broken into two or more pieces."

It compiles in MSVC Unicode, but is that a Visual C extension only? Will 
you please try it on GCC & let me know? There are lots of occurrences, 
and I've already made most of them non-contenated strings, but putting 
them on multiple lines is a lot easier to read & edit.


>
>
>> 2) This, line 51 in PlatformCompatibility.cpp:
>>
>>         HANDLE findHandle = FindFirstFile((const char*)pathToFind, 
>> &findData);
>>
>>    generates this error:
>>
>>    audacity\src\PlatformCompatibility.cpp(51) :
>>        error C2440: 'type cast' : cannot convert from 'wxString' to 
>> 'const char *'
>>
>> Should that be (const char*)(pathToFind.mb_str())?
>
>
> That should be pathToFind.c_str(), because FindFirstFile automatically 
> is 16-bit or 8-bit depending on the build.


Right, thanks, but fn_str(), as Tuomas Suutari pointed out.



>
>>
>> 3) Calls to one-byte fns, e.g.,
>>
>>   wxFFile file(fopen(FILENAME(mFileName.GetFullPath()).fn_str(), "wb"));
>
>
> It should be wxFFile file(FILENAME(mFileName.GetFullPath()).c_str(), 
> "wb") because wxFFile (and also wxFile) already have a wxChar 
> constructor. IIRC this is wrong in the wx documentation (it still 
> contains the wxFFile::wxFFile(const char*, const char*) constructor).


Excellent. I was sticking the with wxFFile(FILE* fp) constructor because 
the documentation says char*, even though it's actually wxChar*. Serves 
me right for believing the documentation!

To be picky, the 2nd arg needs wxT(), so it should be:
    wxFFile summaryFile(FILENAME(mFileName.GetFullPath()).fn_str(), 
wxT("wb")));



>
>> 4) That being the case, what about calls to lib fns that don't have a 
>> wide-char version, e.g.,
>>
>>   SNDFILE *sf=sf_open(FILENAME(mFileName.GetFullPath()).fn_str(), 
>> SFM_READ, &info);
>>
>> which generates
>>
>>    audacity\src\blockfile\SimpleBlockFile.cpp(196) :
>>        error C2664: 'sf_open' : cannot convert parameter 1 from 
>> 'const wxChar *' to 'const char *'
>
>
> Just use mb_str() which always returns 8-bit. The only drawback will 
> be that it may not be possible to open the file when the conversion to 
> 8-bit fails (but this is a problem of libsndfile, which does not 
> support unicode strings). I think it is a platform-defined behaviour 
> which encoding is used and expected within these calls.


Okay, I'll do it that way for now and put a note that it may break.


>
>> I think these file-handling things must be fixed for it to actually 
>> work with Unicode on Linux, right?
>>
>> And I understand that Unicode is not essential for Windows, but I did 
>> read that modern versions of Windows are based on Unicode, and that 
>> the code should run faster in Unicode, because the OS won't have to 
>> keep translating between Unicode and ANSI. Of course, we don't do 
>> that much string-handling...
>
>
> The problem with Unicode is that many Linux distributions come with 
> Unicode-enabled libs by default so it is important to support Unicode 
> or the user will have to re-install wx libraries, and sometimes GTK. 
> Of course, Unicode is also a good thing to support per se. The main 
> problem I see is that the whole Unicode thing cannot really be tested 
> in western countries (even in Germany we don't really need Unicode for 
> our umlauts and stuff, and with a system-wide codepage of ISO-8859-1 
> or so things "just work" most of the time). So the best thing would be 
> to have a contributor / developer from a country like China or so. 
> Otherwise I think it is rather difficult to find and fix bugs.
>
> For the Windows developers, maybe it would be good practice to create 
> the Unicode build next time you update your wxWidgets installation (if 
> you happen to have Windows 2000 or Windows XP, that is). This would 
> help development on Linux. The release builds should still be created 
> with 8-bit support on Windows (because otherwise they won't work on 
> Win98, e.g.).
>
>
> Markus
>

Thanks for all that info, Markus. I've got a Unicode Debug version 
building on Windows, & it records, but all the effects zero out the 
waveform -- maybe a filenaming thing. If you or some other developers 
will let me know about that string concatenation thing, I'll check it 
in. The 8-bit builds are still working.

Thanks,
Vaughan