Win32: redirect messages with qInstallMessageHandler()

[djcj]

On Windows any console output isn't shown correctly since the app will not be linked as a console app.
Instead of trying to redirect the output to console I thought it makes more sense in that environment to use qInstallMessageHandler() and show the messages with MessageBoxA().

[Adam Reichold (adamreichold)]

Hello djcj,

I committed a modified version of your patch as trunk revision 2154. Since I am currently not even setup to build test Windows changes, I would be glad if you could check what is on trunk now to ensure that I did not mess up the functionality while making the necessary stylistic changes.

Regards,
Adam

[djcj (djcj)]

I will later build and check it. One thing however: right now it doesn't check for "--help" on Windows, only "/help" and "/?". I would add "--help" too mainly because the help output message mentiones it.

[Adam Reichold (adamreichold)]

Makes sense. Added in trunk revision 2156.

[djcj (djcj)]

Okay, so calling "qpdfview.exe --help" works as expected. But for some reason calling it with "/help" or "/?" makes it attempt to open a file with the name "/help" or "/?". This behavior is identical in Windows 11 and Wine. I don't know what that's about. But it's not that important to have /help and /? as command line arguments, it's just common to use them in the Windows world.

Other issues I have encountered and provided a patch for:

In synctex/synctex_parser_utils.c you need to explicitly call the PathFindFileNameA and PathFindExtensionA or else the macros PathFindFileName/PathFindExtension may be resolved to the wide character versions (which happened to me).

In main.cpp you must rename "QScopedPointer< QDBusInterface > interface(...)" from "interface" to something else, as it will apparently conflict with a type/struct/etc coming from one of the included Windows header files.

You may also want to initialize "const char* prefix" and "UINT icon" with an empty string and 0 to silence g++ warnings.

[djcj (djcj)]

Addendum: the issue with "/help" and "/?" not being recognized is that you have included that check inside the scope that checks for "--" prefixed arguments.

[Adam Reichold (adamreichold)]

Am 21.12.23 um 15:05 schrieb djcj:
> Okay, so calling "qpdfview.exe --help" works as expected. But for some
> reason calling it with "/help" or "/?" makes it attempt to open a file
> with the name "/help" or "/?". This behavior is identical in Windows 11
> and Wine. I don't know what that's about. But it's not that important to
> have /help and /? as command line arguments, it's just common to use
> them in the Windows world.

Indeed, the parser is structured so that options always have to begin
with "--".

> Other issues I have encountered and provided a patch for:
>
> In synctex/synctex_parser_utils.c you need to explicitly call the
> PathFindFileNameA and PathFindExtensionA or else the macros
> PathFindFileName/PathFindExtension may be resolved to the wide character
> versions (which happened to me).
>
> In main.cpp you must rename "QScopedPointer< QDBusInterface >
> interface(...)" from "interface" to something else, as it will
> apparently conflict with a type/struct/etc coming from one of the
> included Windows header files.
>
> You may also want to initialize "const char* prefix" and "UINT icon"
> with an empty string and 0 to silence g++ warnings.
>
> ** Patch added: "qpdfview-1-fixes.patch"
> https://bugs.launchpad.net/qpdfview/+bug/2044257/+attachment/5731697/+files/qpdfview-1-fixes.patch
>

Please check trunk revision 2160 which should contain all of these fixes.

[djcj (djcj)]

It works. But in parseCommandLineArguments() the passed arguments are redirected into qDebug() so you get a message on each start. I guess "case QtDebugMsg:" should simply return without displaying a message (unless a debug build was made?).
qDebug() is also used multiple times in database.cpp and pluginhandler.cpp.

[Adam Reichold (adamreichold)]

Ah no, this is just me forgetting my own debugging statements... Removed in trunk revision 2161.

[djcj (djcj)]

I've looked it up and it seems on Windows you need to explicitly connect a GUI application to a console if you want its output to be visible there. Here's a patch that does this. With that approach the behavior should be the same as on Linux.