Win console #583
Win console #583
Conversation
| UINT oldCodePage; | ||
| bool shouldResetCodePage = false; | ||
| if (GetConsoleWindow() != NULL) { | ||
| if(AttachConsole(ATTACH_PARENT_PROCESS)) { |
There was a problem hiding this comment.
please pull all of this out into a helper function in util/console.h or similar to prevent duplication
|
Done! Looking forward to see if it builds. |
| // LOCALE_IDEFAULTANSICODEPAGE "1252" // ANSI Codepage used by Qt toLocal8Bit | ||
| // LOCALE_IDEFAULTCODEPAGE "850" // OEM Codepage Console | ||
|
|
||
| UINT m_oldCodePage; |
|
fixed |
|
Hey I'm back, sorry for the delay. These changes look good, but for some reason I don't have console output anymore on Windows 7. The only way I can see stdout and stderr is to pipe to a file. All the Qt logging is visible in stderr, so I personally don't think this is a problem. I don't see how this PR could have caused this change in behavior, but I don't know what else it could be. If I type "dist32\mixxx.exe" on the command prompt it behaves as if I had typed "start dist32\mixxx.exe". In other words, Mixxx seems disconnected from the console immediately, before the code even has a chance to run. Did something change with the build process or Qt configuration maybe? |
So It seams I have failed :-( I can confirm this on WinXp: No console when starting in cmd.exe. |
|
Ah, I see it now. This 304e5f6 change is most likely responsible. I will uncomment and try it. |
|
@default-kramer -- indeed -- that was part of the plan. Remove subsystem:console from mixxx-test.exe and see if the console changes made recently cause the console to work. |
|
The way the build is currently structured makes it hard to build mixxx.exe and mixxx-test.exe with different subsystem arguments. It's probably do-able though. |
|
Also, mixxx-test output works on the build server despite subsystem:windows: http://builds.mixxx.org/jenkins/job/1.12-release/architecture=i386,platform=windows/34/console |
|
When I switch back to subsystem:console, the console reappears as expected. But it always appears, even when Mixxx is not launched from a console. I think there is a way to conditionally hide it, although it may still appear in the taskbar which would probably not be acceptable. I don't think it is possible to use subsystem:windows and attach to the console that launched Mixxx. The console is not blocked, so I could be typing in another command. I don't think that Mixxx would be allowed to hijack a console that belongs to the user and start spewing output while the user is trying to enter another command. So I think the choice is between:
Would either or both of these be acceptable? |
@rryan: What if you start mixxx-test.exe inside cmd.exe? Do you see the output? @default-kramer Dos this example show a console output fromcmd.exe when compiled as subsystem windows? There is a problem anyway: we need to put the Console() call above the command line explanations to have them on the console. Maybe it fixes the problem at all? |
|
@daschuer I had the same thought and tried moving Console() to the very beginning of main() but it didn't work. However, the example you linked to does work! So I should be able to get it working now. |
|
Cool! Thank you for taking care. |
This Pull Request hopefully allows to build mixxx and mixxx-test with subsystem:Windows.
The console is created via custom code after main.
The build flag DEBUGCONSOLE was also removed since Mixxx for windows should now work almost similar as Linux.
Related Bug:
https://bugs.launchpad.net/mixxx/+bug/1453782
Since I cannot build on windows this PR is untested.