View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0001027||OpenMPT||General||public||2017-09-21 12:28||2018-02-23 12:14|
|Product Version||OpenMPT 1.27.01.00 / libopenmpt 0.3.1 (upgrade first)|
|Target Version||OpenMPT 1.28.01.00 / libopenmpt 0.4.0 (upgrade first)|
|Summary||0001027: Remove various WCHAR hacks for !UNICODE|
There are various hacks in the codebase that were only needed for unicode filename support in !unicode builds. Those can be removed now, as well as all explicit call too FooW WinAPI functions.
|Tags||No tags attached.|
|Has the bug occurred in previous versions?|
|Tested code revision (in case you know it)|
r9154 removes filename UTF8 tunneling in document handling
We need to decide if we want TCHAR PathString or not; if we don't, modifying CTreeCtrl.h doesn't make much sense, as it's used in PathString-related contexts only. So it's either both or none.
Another option might of course be to just completely remove support for ANSI builds. This would cost us some compile-time string type checking though.
Removing explicit WCHAR support in FileDIalog would allow us to use CFileDialog again, which has the advantage of automatically using IFileDialog when available rather than the classic GetOpenFileName/GetSaveFileName. This in return has the advantage that specifying a hook procedure for selection changes (like we do when "preview samples in file dialogs" is checked) does not enforce the "classic" pre-Vista file dialogs.
COM GUID functionality is still std::wstring, however the COM API is based on OLECHAR, which is WCHAR even in ANSI builds, thus it does not make much sense to change that area.
Are there any other bigger areas that still need to get converted?
Any usage of mpt::ustring in the UI leads to using the widechar WinAPI functions, but I don't think that's necessarily an issue that needs to be fixed. The only time this is going to be relevant will be if we switch to a GUI toolkit that prefers utf8 strings over wide strings, in which case we have to remove the WinAPI functions that are being called anyway. So I'd leave these sites as-is and consider this issue to be resolved.
There are probably still some minor places that could use cleanup.
|2017-09-21 12:28||manx||New Issue|
|2017-09-21 12:28||manx||Status||new => assigned|
|2017-09-21 12:28||manx||Assigned To||=> manx|
|2017-09-21 12:29||manx||Relationship added||related to 0000570|
|2017-10-28 08:20||manx||Additional Information Updated||View Revisions|
|2017-10-28 08:21||manx||Additional Information Updated||View Revisions|
|2017-10-28 08:22||manx||Note Added: 0003316|
|2017-10-28 08:22||manx||Additional Information Updated||View Revisions|
|2018-02-11 22:55||Saga Musix||Note Added: 0003415|
|2018-02-11 22:56||Saga Musix||Note Edited: 0003415||View Revisions|
|2018-02-12 08:23||manx||Note Added: 0003416|
|2018-02-12 12:51||manx||Note Added: 0003417|
|2018-02-12 16:25||Saga Musix||Note Added: 0003418|
|2018-02-16 21:37||Saga Musix||Additional Information Updated||View Revisions|
|2018-02-23 11:42||manx||Note Added: 0003434|
|2018-02-23 11:43||manx||Additional Information Updated||View Revisions|
|2018-02-23 11:44||manx||Note Added: 0003435|
|2018-02-23 11:45||manx||Note Added: 0003436|
|2018-02-23 11:49||Saga Musix||Note Added: 0003437|
|2018-02-23 12:14||manx||Status||assigned => resolved|
|2018-02-23 12:14||manx||Resolution||open => fixed|
|2018-02-23 12:14||manx||Note Added: 0003438|