Is it possible to resize the console in a windows console application to fullscreen size?
It is possible to do that in the preferences of the windows, after the console was opened, but I cannot figure out how to do it programmatically.
You can get a handle to the console window using GetConsoleWindow.
Once you have that, you should be able to resize it using SetWindowPos
You may also need to resize the buffer for the console using SetConsoleScreenBufferSize prior to resizing the window.
ETA:
Others have mentioned using SetConsoleDisplayMode to display the console in full-screen (non-windowed) mode. I'm not sure if this is really what you wanted or not though. I haven't seen any apps use non-windowed mode since the windows 98 days.
Related
I'm developing a 3D desktop application like this where I duplicate the desktop by creating planes in 3D space using each window's bitmap as texture and then passing mouse and keyboard input to them (background windows) via windows API.
This approach causes several issues and the main one is that some clicked windows generate new popup windows like menus that popup on top of 3D app and steal focus.
Is it possible to properly duplicate a desktop behavior inside another app like this - without losing focus and keeping 3D app on top?
Only workaround for this that I can think of is to have 3D app running on secondary monitor, let user work with regular desktop on primary monitor as usual and 3D app will just duplicate that and use windows hooks for any 3D app specific input.
Apparently IInspectable is right. No reliable way to do this without losing focus.
I'm writing a desktop. I already know the basics of Qt and GTK+ through Python but I don't understand how to display the finished Desktop. How do you make it the root window of a Window Manager, or is there a method for displaying the desktop I'm not familiar with?
You don't make it the root window. X has one root window which you can't change. There are a number of ways to do what you want
X Root window
The old way was that the desktop was just the standard X root window. Icons were just individual borderless windows.
Desktop Window
Now most systems open a large window, and mark it as being a desktop window. Most window managers then know never to raise it above any other windows. The X root window is still behind it, but it is hidden. This means you can do anything you want on this window, draw to it, include icons or widgets or anything else your toolkit can do.
If you are using Gtk+ then the relevant information is found in the GdkWindowTypeHint enum, specifically the GDK_WINDOW_TYPE_HINT_DESKTOP. The documentation can be found here: GdkWindow
Compositor
However, there is a newer way that desktops like Gnome3 or Unity use, which is called the Compositor Overlay Window. When a compositor is running there is an overlay window which covers all the windows on the system. It is then up to the compositor to draw the actual contents of the windows on this overlay. However, the overlay can draw whatever it wishes on this overlay window. For example, in Gnome3 when you enter the window selector and the windows arrange themselves into a grid the windows aren't really moving and shrinking, the compositor has just decided to draw them that way. In reality, the windows are still in the same position they were before, but hidden under this overlay.
This is a very advanced way to do things, and certainly not for the novice developer. You probably want to be focusing on the second method.
I'm using Qt 4.6.3, and ubuntu linux on an embedded target. I call
dlg->setWindowState(Qt::WindowFullScreen);
on my windows in my application (so I don't loose any real-estate on the touch screen to task bar and status panel on the top and bottom of the screen. This all works fine and as expected. The issue comes in when I want to popup the on screen keyboard to allow the user to input some data. I use
m_keyProc= new QProcess();
m_keyProc->start("onboard -s 640x120");
This pops up the keyboard but it is behind the full screen window. The onbaord keyboards preferences are set such that it is always on top, but that seems to actually mean "except for full screen windows". I guess that makes sense and probably meets most use cases, but I need it to be really on top.
Can I either A) Not be full screen mode (so the keyboard works) and programmatically hide the task bars? or B) Force the keyboard to be on top despite my full screen status?
Note: On windows we call
m_keyProc->start("C:\\Windows\\system32\\osk.exe");
and the osk keyboard is on top despite the full screen status. So, I'm guessing this is a difference in window mangers on the different operating systems. So do I need to set some flag on the window with the linux window manager?
Qt doesn't seem to have a way to bring other, non-Qt process in front. You may need to get the native, platform process ID from QProcess by calling QProcess::pid() and call the underlying OS API to do it.
I'm trying to create a fullscreen application using Win32 and OpenGL. I change the resolution using EnumDisplaySettings and ChangeDisplaySettings and the OpenGL functions work fine. On its WndProc I handle WM_ACTIVATEAPP and detect when the user switched focus to another window, then I minimize the application's window. When the window is maximized again, the window doesn't display properly at all. What could I include to make the application work even after minimizing?
From the question I cannot still say what you are missing and what you already have. Refer to the http://nehe.gamedev.net/. There is a section Opengl base code to setup a window in full screen and switch back to window mode. See if you can get something from there.
I've seen an application that simulates a fullscreen application by removing the title bar and the window borders. I've done some research and found getWindowLongPtr() for that.
Now my question: How can I find and identify the application and get the appropriate window handle? How can I distinguish multiple instances of the application (running from different locations on disc)?
Just to make "simulate" more precise. If you make an application go fullscreen and you click on a different monitor, it minimizes itself. If the application runs in a window and you click on a different monitor, the window is not changed. If you remove the borders of the window and position it on the left or right monitor, you can still work with the other monitor without minimizing the application. Still it looks like the application running fullscreen on one of the monitors.
As an example: you can set Eve (www.eveonline.com) to fullscreen and windowed mode. In fullscreenmode you can not click on a second monitor without Eve minimizing itself. In window mode you can. There are tools like evemover that allow you to setup your window on one monitor, looking like fullscreen, but being in window mode. That's what I want to archieve. Evemover actually provides some of it's source code, that's why I know that removing the border and setting the position is done using the Win32-API with setWindowLongPtr and setWindowPos.
Many applications use divergent and confusing applications of the phrase "fullscreen".
A fullscreen application simply - occupies the full screen area.
DirectX applications can request a fullscreen exclusive mode. The advantage of this mode to DirectX applications is, with exclusive access to the (full) screen they are then allowed to change the resolution, bit depth etc, as well as gain access to vertical sync synchronized hardware buffering where the screen surface is 'flipped' between display intervals so that 'tearing' does not occur.
Anyway, the windows desktop understands 'fullscreen windows' - windows that occupy the full area of a monitor and have no non client elements. When windows like this are created, things like desktop gadgets and task bars automatically hide themselves. Modern games have come to call this mode 'fullscreen windowed'.
Back to your question: 'FindWindow' is the API used to discover other applications windows. Getting the path to the application that created the window is much harder. GetWindowThreadProcessId can get you the process id of the owning process. OpenProcess will get you a handle that you can pass to QueryFullProcessImageName (implemented on Vista and above) to get the full path to the process.
I think you are refering to applications like window aggregators, that 'plug in' to the system and act from outside the application.
Look at the code for the freeware app PuttyCM (for aggregating Putty (SSH) shell windows as tabs). IIRC, it ensures that the Window pointer passed to the application has the flags already set.
On applications running from different places, you will probably need some way of identifying it - registry entries / install log etc.