Custom Query (301 matches)

The 'console' flag should generate a console application (that requires standard input/output streams and a text mode window attached to it).

The 'windows' flag should generate a PM application that doesn't have standard input/output or a text mode window attached.

Currently, qmake passes special flags to WLINK depending on whether 'console' ("SYSTEM os2v2") or 'windows' ("SYSTEM os2v2_pm") is in CONFIG but these flags are not understood by a standalone patched WLINK version we use because system configuration files are missing.

The Alt key is intercepted by PM and used to activate the native PM window menu bar or the system menu if there is no native menu bar.

This steals the Alt key press from Qt and therefore prevents it from activating the Qt menu bar in Qt applications; the system menu is always activated instead. This doesn't make sense and needs to be fixed. For the system menu, there is a de-facto standard Alt+Space key combination which should also do the same in Qt applications but single Alt press should be normally passed to Qt which will cause the Qt menu bar activation if there is one.

There is a common problem of searching for the right DLLs for the application being started in OS/2: by default, the OS/2 loader doesn't search for DLLs in the directory where the .exe is located (which is a very common and natural case) which requires to put the DLL to the system DLL location (badly bloating it) or craft a .cmd that sets a proper BEGINLIBPATH/ENDLIBPATH. Both ways suck.

I've got an idea to do DosSetExtLIBPATH() with the exe's path implicitly in QProcess before starting the application (and undo afterwards) to make this search location transparent both for the end user and for the Qt developer.

Unless I discover some bad side effects, I'll do it like that.