I am writing a DLL to be injected into a process which creates a SDL game window. I am able to create child windows and listen in on messages, but one thing I am having a difficult time doing and finding out how to do is stealing space that won't be used in drawing the game frame.
What I mean is, I want to give space to my windows in the same way the menu bar has space. When I SetMenu, the rest of the window scrunches down into the remaining space automatically. However, for a window created with CreateWindowEx, I can find no way of doing something similar.
I know there are a lot of unknown and potentially important factors here that would decide the best course of action, but is there any win32 function I haven't found that could help with this? They don't have to change in size often much. I just would like something like:
ReserveSpace(wnd, 0, 0, width, 20);
// Place CreateWindowEx-ed HWND there
(well, I don't expect something so simple).
Is this easily possible? I know "reserving" a rectangle of any size doesn't make sense, I would have to reserve a row or column if it is possible, but that is fine and expected. Any ideas?
Related
I'm asking this question ahead of time, since I haven't gotten around to attempting an actual, real implementation yet. Win32 (C++) is turning out to be a colossal pain to program. But, my question is this:
I want to make my application's window become fully transparent with a dotted perimeter when resizing the window. How would I accomplish this? Think of what happens in Windows 3/3.1 (I believe it was this version) when resizing a window. Everything goes transparent, with a dotted-outline where the mouse is moving, then it repaints the entire contents. That's what I'm trying to achieve.
A while ago, I tried handling the WM_(ENTER/EXIT)SIZEMOVE messages and make use of SetWindowLong() to set the WS_EX_TRANSPARENT extended style, but my window became (indefinitely) pass-through, and when the window's focus was killed, it could never again regain focus.
Do I need to handle other messages like WM_NCLBUTTON(DOWN/UP)? I have a boolean flag to tell me when to halt drawing during resizing, and the logic for determining when I'm resizing works perfectly, but I cannot get the visuals to work. I'm not sure which parts of the Win32 API to actually use. I've done some research, and uxtheme.lib/.h seems promising, but I'm not sure how that would work with WM_NCPAINT, which I have been using with (some) luck.
EDIT
I need to clarify something, in case anyone was confused or unsure of what I meant. What I meant by the Windows 3.1/3 resizing scenario is that once WM_ENTERSIZEMOVE has occurred, the window (controls, caption, frame) should be made entirely invisible, and the window's nonclient-region's perimeter should display a dotted-outline of sorts. Then, only until the resize has been finished, when WM_EXITSIZEMOVE has occurred should the entire window (controls, caption, frame) be fully redrawn, updated, and returned to its normal, functional state. Sorry for any miscommunication!
I found the answer... After so long, finally found it. Here's where I found it! http://www.catch22.net/tuts/win32/docking-toolbars-part-2# - Hope it helps anyone else possibly in my shoes!
And it turns out that the solution was rather simple. In fact, the core concept of what is explained is near-completely what I was thinking, yet I just had no idea how to implement it. The solution involves overriding the default WM_NCLBUTTONDOWN, WM_MOUSEMOVE, WM_LBUTTONUP (specifically when initiating a window movement) messages, and drawing a patterned rectangle which follows the position of the cursor. Then, afterwards, calling SetWindowPos or some other similar function to relocate the window.
Basically, block Windows from attempting to display anything graphics related until the resizing has been finished. Then, and only then, make Windows move the entire window in one huge, foul swoop.
Based on Remy's comment, there is a global option and corresponding registry setting for this, so perhaps try setting the registry setting when the move starts and restoring it when the move finishes.
Unfortunately this doesn't work as Windows appears only to pick up the setting on restart, broadcasting WM_SETTINGCHANGE also doesn't trigger it, which is a pity as doing something yourself that the OS already has an implementation of do is rather a poor state of affairs.
Is there any way to apply or have custom frames (images) around specific X windows?
For example, in xfwm4 and fvwm (window managers) it's possible to have a specific window decoration for a window with different images, one at the bottom, other at the top, etc. examples:
For xfwm4 and fvwm.
Obviously if it was that easy, I'd just use either of them, however, I do think that a singular program could handle it instead of needing to change the whole window manager.
I'm currently using dwm and there are ways to change the colour and thickness of border, and that's it. If I was better at C I could create a rule to draw images around specific X windows with specific WM_CLASS, but that's too much for me now, so any help is really appreciated.
An alternative solution would be to draw a single image (from a file) bigger than the X window behind it and make it to follow the X window position, and maybe the size as well (that's harder, so it's not really that necessary)
I started writing a C++ program to do that, but that may take too much time since C++ still a new tool to me and looking at how xfwm4 handles this.
I am currently working on a piece of code to circumvent the modal loops for moving and resizing Windows by effectively re-implementing DefWindowProc for the process.
The first snag I've hit is with MINMAXINFO. It seems that Windows fills this in with default values before sending the message along to the WindowProc, so simply sending the message to a window that doesn't override the values wouldn't do any good. Figuring that this wouldn't be as simple as giving it the desktop window size for the max and zeroes for the min, I checked how ReactOS does it in their source and.... well, I don't understand why they do the things they do in calculating it.
In particular, they choose to negate the WS_BORDER style when calling AdjustWindowRectEx. Their use of variables named "xinc" and "yinc" also seems unusual to me.
Basically, I'm hoping someone who has worked with the code (or MINMAXINFO more generally) can explain what I'm missing.ReactOS: WinPosGetMinMaxInfo
The ptMaxSize values in the MINMAXINFO structure are not the maximum size you can drag size to, but what the size will be if the window is actually maximized. When a window is maximized, the thick border is removed (since you no longer want the user to grab the border and try to resize it).
Make sure you read all the details in the explanation of the values for MINMAXINFO.
I want to create my own tiny windowless GUI system, for that I am using GDI+. I cannot post code here because it got huge(c++) but bellow is the main steps I am following...
Create a bitmap of size equal to the application window.
For all mouse and keyboard events update the custom control states (eg. if mouse is currently held over a particular control e.t.c.)
For WM_PAINT event paint the background to offscreen bitmap and then paint all the updated controls on top of it and finally copy entire offscreen image to the front buffer via Graphics::DrawImage(..) call.
For WM_SIZE/WM_SIZING delete the previous offscreen bitmap and create another one with new window size.
Also there are some checks to prevent repeated drawing of controls i.e. controls are drawn only when it needs repainting in other words when the state of a control is changed only then it is painted e.t.c.
The system is working fine but only with one exception...when window is being resizing something sort of tearing effect appears. Now what I mean by tearing effect I shall try to explain ...
On the sizing edge/border there is a flickering gap as I drag the border.It is as if my DrawImage() function returns immediately and while one swap operation is half done another image drawing starts up.
Now you may think that it is common artifact that happens in many other application for the fact that resizing backbuffer is not always as fast as resizing window are but in other applications I noticed in other applications that although there is a leg between window size and client area size as window grows in size nothing flickers near the edge (its usually just white background that shows up as thin uniform strips along the border).
Also the dynamic controls which move with window resize acts jerky during sizing.
At first it seemed to me that using a constant fullscreen size offscreen surface could minimize the artifact but when I tried it results are not that satisfactory. I also tried to call Sleep() during sizing so that the flipping is done completely before another flip starts but strangely even that won't worked for me!
I have heard that GDI on vista is not hardware accelerated, could that might be the problem?
Also I wonder how frameworks such as Qt renders windowless GUI so smoothly, even if you size a complex Qt GUI window very fast negligibly little artifact appears. As far as I know Qt can use opengl for GUI rendering but that is second option.
If I use directx then real time resizing is even harder, opengl on the other hand seems to be nice for resizing without any problem but I will loose all the 2d drawing capability of GDI+.
If any of you have done anything like this before please guide me. Also if you have any pointer that I should consider for custom user interface design then provide me the links.
Thanks!
I always wished to design interfaces like windows media player 11 but can someone tell me that there is a straight forward solution for a c++ programmer (I want to know how rather than use some existing framework etc.)? Subclassing, owner drawing, custom drawing nothing seems to give you such level of control, I dont know a way to draw semitransparent control with common controls, so I think this question deserves some special attention . Thanks again.
Could it be a WM_ERASEBKGND message that's causing it?
see this question: GDI+ double buffering in C++
Also, if you need fast response from your GUI I would advise against GDI+.
I have a number of applications which I cannot modify(no source), they are hard coded to draw at 0,0. Normally this is not a problem however a new project(kiosk) has come along where I need to draw a boarder around the outside of these applications. I am looking for a way to change display range from:
X: 0 to 1200
Y: 0 to 900
to something like:
X: -100 to 1100
Y: -100 to 800
I've seen a couple functions on MSDN like SetViewportExtEx, SetWorldTransform which fit the need however if I understand them correctly they don't do a system wide change. They are for the current process only.
I am programming in C++ but if there are settings in the registry/control panel/etc that would also work.
Has anyone else done anything like this before?
Edit 1: Window position is hard coded to 0,0
This might be overkill, but if it's something you really want to have complete control over, you could always use API hooking to intercept the Window creation by hooking CreateWindow, CreateWindowEx in the target process and altering the X Y coordinates before passing control back to the system.
Popular API hooking libraries include: Microsoft Detours, Madshi's madCodeHook, and the free, open source EasyHook.
Could you clarify what you mean by 'the applications are hard coded to draw at 0,0'? Does this mean that the position of their windows is set to 0,0, or do they have code to paint at 0,0?
Solution #1
One possible solution would be to use SetWindowPosition to simply move each of the applications to whatever position you desire.
All you would need to do is enumerate the list of HWNDS calling SetWindowPosition on each as necessary.
Solution #2
Set the working area of the desktop to be smaller. This should cause your applications to take up the working area, not the entire screen. You would then be free to put up any additional windows you need, manually position them, and draw your border.
In fact you might consider registering your border windows as 'app bars' which would automatically resize the working area.
The route I might take is making a shell application with a window and then setting the parent of the other using "SetParent"
for instance, in C# I did this...
var info = new ProcessStartInfo {FileName = "NotePad.exe", WindowStyle = ProcessWindowStyle.Normal};
var runProcess = Process.Start(info);
Thread.Sleep(1000); // ugly, but more just proving a point
SetParent(runProcess.MainWindowHandle, Handle);
and it hosted notepad in my forms window
So, Simply host the window, resize your host to the clients size + a bit, position the client in your host window where you want, and then draw around the outside.
easy peasy :)