1.17.02.48 load sample fails with special character

[le_parasite]

Full Version:
OpenMPT v1.17.02.48

Has the bug occured in previous versions?
I dont know



Description of the bug:

maybe due to some windows bug, but when you try to load a sample with special "letter", the sample won't load.

How often does it happen?:

always

How to reproduce (step by step description):

name a sample "Dvořák.wav" and try to upload it.

Edit: More information is available on the issue tracker.

[Saga Musix]

Hm, i sense unicode incompatiblities here...

[Sam_Zen]

I guess so too.

[Saga Musix]

The strange thing is that this filename is always passed as "Dvorák.wav" to MPT, not only when opening a sample but also in the treeview... So maybe the WinApi passes a "optimized for non-unicode platforms" version of that string to modplug...?

[LPChip]

The ř char isn't part of the standard ascii table. Its an extended char, whereas the á is part of the standard ascii table.

And by standard, I mean 0-255.

[Saga Musix]

I know that! But I'm not sure what causes the bug here, maybe I have to learn about more about string types in C++....

[bvanoudtshoorn]

I'd guess that it's a conversion issue; ie, the filename's represented in format x in the system, is converted to format y for modplug, and then modplug tries to open the file using format y, and the system complains. But I'm just guessing.

This MSDN section might be useful, though.

[Saga Musix]

Well, the filename is retrieved from a CFileDialog object. I directly tried to route that filename to a MessageBox (without a temporary variable) and it was still non-unicode.

[LPChip]

So this dialog gives the wrong filename back? Maybe there's a setting in the dialog to enable it. Otherwise, the control needs to be updated.

[Saga Musix]

I'll close this one as a related issue has been posted on the issue tracker.