currently there are lots of places where manually macros UNICODE and _UNICODE are defined: http://blogs.msdn.com/b/oldnewthing/archive/2004/02/12/71851.aspx git grep DUNICODE git grep D_UNICODE we should rather define that globally in solenv/gbuild/com_MSC_defs.mk. also there is no point to ever calling the archaic so-called "ANSI" Win32 functions (end in *A); probably it's best to call the UCS-2 Unicode ones directly (end in *W). corresponding string literals can be written as L"foo" maybe once every function call is directly to a *W function the UNICODE _UNICODE can be removed altogether, but as a first step it's probably best to define that globally.
Hello, I would like to participate on this bug, is there any progress made by someone else (to cooperate work...)? Thanks for feedback
Please don't assign a bug to yourself unless you are very sure that you actually will be fixing it in a reasonable timeframe. If you just want to try, but don't know if you will succeed or not, it's enough to leave a comment. (The above is obviously just my personal opinion, not some "official" rule.)
(In reply to comment #2) > Please don't assign a bug to yourself unless you are very sure that you > actually will be fixing it in a reasonable timeframe. If you just want to > try, but don't know if you will succeed or not, it's enough to leave a > comment. > > (The above is obviously just my personal opinion, not some "official" rule.) Ok sorry for that, i changed it back. I will work on that...
maybe it would be better to move directly to removing the #ifdef UNICODE everywhere, e.g. look at this nonsense all over setup_native/source/win32/customactions/shellextensions/ #ifdef UNICODE #define _UNICODE #define _tstring wstring #else #define _tstring string #endif that requires other headers to be included in a particular order, etc. just call *W functions and use std::wstring.
Also, related to this, we should not use any of the <tchar.h> madness anywhere. No _TCHAR, TEXT(), _tcs*(). Just use wchar_t and the wcs*() functions directly if that is what is meant. (Or, char and str*() if not.)
Migrating Whiteboard tags to Keywords: (easyHack, difficultyBeginner, skillCpp, topicCleanup)
JanI is default CC for Easy Hacks (Add Jan; remove LibreOffice Dev List from CC) [NinjaEdit]
As a first step towards addressing this issue I have eliminated the TCHAR mess from one of the modules used in the Windows MSI installer. Built OK and the resulting installer worked correctly. If this style is acceptable to progress in LibreOffice I will do so. Please find patch at: https://gerrit.libreoffice.org/#/c/24707/
skswales committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=8a4dd6f45b12e7d44ad595bc0fadc37075061119 Work towards tdf#72606 EasyHack _tstring/TCHAR elimination It will be available in 5.2.0. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
More work towards _tstring/TCHAR elimination Quickstarter code in MSI Installer compiled UNICODE Used explicit A/W suffixes on functions for clarity Please find this patch at https://gerrit.libreoffice.org/25153
More work towards _tstring/TCHAR elimination Used explicit A/W suffixes on functions for clarity and consistency in sellang module of MSI Installer Please find this patch at https://gerrit.libreoffice.org/25167
skswales committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=163dcad72e03e214d842e74d1f71ed025cbdd870 Work towards tdf#72606 It will be available in 5.2.0. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
skswales committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=074bd09ee6f3113792b60ee721aabb731c5d7ace Work towards tdf#72606 EasyHack _tstring/TCHAR elimination It will be available in 5.2.0. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
skswales committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=68502698d29e577a7a451f1a796677128901cfe3 Work towards tdf#72606 EasyHack _tstring/TCHAR elimination It will be available in 5.2.0. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Work towards tdf#72606 EasyHack _tstring/TCHAR elimination setup_native/source/win32/customactions/shellextensions in MSI Installer compiled as UNICODE Functions suffixed with A/W (ANSI/Wide) as needed for clarity Please find patch at: https://gerrit.libreoffice.org/#/c/25556/
skswales committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=7fe92c766adf97bdeb4d844ffe6d0650a964572e Work towards tdf#72606 EasyHack _tstring/TCHAR elimination It will be available in 5.3.0. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
skswales committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=29e0b587df4e509558c22fa478992b07486828d1 Work towards tdf#72606 EasyHack _tstring/TCHAR elimination It will be available in 5.3.0. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Seems solved
there are still lots of TCHARs being used, see "git grep TCHAR" most of them are in "workben" and "test" directories that are not actually built currently but there are a bunch in desktop, dtrans, embedserv, etc.
skswales committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=a50cdeb70ec19369f42ed08abfd4a5301d05edb5 Work towards tdf#72606 EasyHack _tstring/TCHAR elimination It will be available in 5.3.0. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
skswales committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=6a17c118f312699ab26147148cd2e7844c41a777 Work towards tdf#72606 EasyHack _tstring/TCHAR elimination It will be available in 5.3.0. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Still a lot of .mk files to correct
Please be aware, that this easyhack is considered an important but large scale cosmetic change as described in https://wiki.documentfoundation.org/Development/LargeScaleChanges It was in decided by the ESC to close this kind of easyhacks, and send them directly as mail, to new contributors. https://lists.freedesktop.org/archives/libreoffice/2016-August/074920.html Please do not submit patches with many files !! This particular easyhack is kept open as an exception to the rule
This is certainly not a "large scale cosmetic change".
Lots of this has already been handled by Mike Kaganski (who was not aware there was an Easy Hack for it). What remains is not an Easy Hack any more, he says, so removing those keywords.
** Please read this message in its entirety before responding ** To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from http://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
Mike Kaganski has fixed it now with commit 558956dc811a1f0f07411e348f7081a467bbc3b5 "Drop UNICODE/_UNICODE defines"