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.
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.
I'm trying to make a text reader/pseudo-command-line a la man, but I'm having difficulty making the text scroll the way I'd like it to. At first I was having trouble getting new text to appear while scrolling, but eventually I found that pads would fix that for me, and I'm currently integrating them.
My question is, how can I get text to wrap within the pad? My program currently automatically refreshes when it is resized, so defining the pad to have as many columns as the terminal wouldn't fix everything. Can I get the pad to automatically resize itself as needed when my terminal receives a KEY_RESIZE? Not just the displayed size, but the size of the pad as well, such that text is pushed down a row due to the end of the pad. Additionally, will resizing it still keep the text, moving it down rows if necessary, or will I need to refresh the content of the pad?
Unfortunately, I'm having trouble finding resources with these details, and the documentation in ncurses doesn't elaborate on the behavior of resizing a pad.
Thanks a lot!
Edit after answered: ncurses doesn't do this, so I'm going to try instead making some arrays of strings, one to store the text from the file (broken at \n), and another for the line wrapping (refreshed on KEY_RESIZE, with each string having a max length of the terminal rows), parts of which are printed to the body window based on scrolling position and such. I'm making this edit so anyone else seeing this problem in the future can see what my solution is. I haven't done this yet, so I'll edit this again if it fails. Thanks again to Stack Overflow for helping with this!
ncurses will not do what you intend in this case:
A pad is like a window, true, and addch will wrap -- but the viewport which you are using to display data in the pad is not a window, and wrapping at the right side of the pad is not necessarily related to that viewport.
Once the text has wrapped, ncurses will not remember what that was, and re-wrap text if you resize the window (or pad).
A pad is mainly useful when you want to display just part of a window, e.g., if the screen is not large enough for the text you want to display.
If you want to resize and re-wrap, your program should allow for rewriting all of the text in the window (to lay it out as you intend) and not rely on ncurses to decide how to re-wrap text.
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?
My objective is to have a CToolBar derivative which has a single control on it (a CMFCShellTreeCtrl).
Something like:
class CFileTreeBar : public CToolBar
Whenever it is asked to compute its size, I want to respond that it is either a fixed minimum, or the size of the client area of the dock bar to which it is docked. In other words, it should consume the entire height of the dock bar + a fixed width (this is being docked on the left - exactly as Explorer lays out its folder tree on the left).
Hence, in CFileTreeBar::CalcFixedLayout it responds with height based on GetParent()->GetWindowRect(rect), and a width of 250pix.
Then in OnSize, the CFileTreeBar resizes its CMFCShellTreeCtrl to consume our client rect (maximizes our only control).
This works beautifully for when the control bar is initially displayed. And it works great when resizing the window by dragging a corner. The CaclFixedLayout returns a different value from its previous value (because the window size changed) and so it computes that it should consume the entire vertical space and eventually I get an WM_SIZE message telling my control bar to resize, which causes me to update the size of the CMFCShellTreeCtrl.
Where I am struggling is when hitting "maximize" button on the CFrameWnd. In this case, for reasons I don't really understand, the CalcFixedLayout is called but the dock bar has its old size (it hasn't been updated to the new sized based on being maximized yet). This causes my code to respond that the size should be the same as it was previously - which causes MFC frame work to not issue a resize (we're already the size we claim we need to be).
Hence, a moment later the dock bar is expanded to consume the whole vertical space, but my control bar and its underlying shell tree are not resized - but left behind with the stale size.
The problem happens also when going from maximized to restored. At that point the call to CalcFixedLayout indicates that we should be as tall as the maximized window (its current size), and now the frame work kicks off the resizing code which ends up making us larger than the dock bar (once it is resized down to restored size), and we disappear below the bottom of the dock bar (clipped by it's maximum vertical extent).
Questions
Is there a good tutorial or white paper showing the overview of how dockbars and control bars are supposed to interact in MFC? i.e. a complete description of how this frame work is supposed to hang together properly? Understanding how these pieces fit together and are intended to work coherently would go a long way towards avoiding hacking it to work, allowing me to write something round to fit the round hole, so to speak.
Is there an example project similar to this that anyone is aware of? Having to figure this junk out is incredibly time consuming - if there is an example somewhere which does this, then that would be great...
Dockable and resizable toolbar is quite complicated to code, there is one in codeproject which is quite good. You can study the source code to see how the author do it.
http://www.codeproject.com/Articles/6/CSizingControlBar-a-resizable-control-bar
I have a CDHTMLDialog running in IE that has a fixed size that I chose, and runs in a fixed window to match this size.
My problem is that the user can zoom on it (by ctrl-mousewheel) causing my html to be larger or smaller than the window which looks awkward and adds annoying scrollbars. Also, the user might use ctrl-+ or ctrl-- to change the html size, which also causes my CDHTMLDialog to become larger or smaller (though only on navigation after changing size).
Anyone maybe has an idea on how to prevent all zooms on the CDHTMLDialog, including wheel and ctrl-+?
Found it :)
Upon document complete I run the following:
CComVariant vZoom = 100;
m_pBrowserApp->ExecWB(OLECMDID_OPTICAL_ZOOM, OLECMDEXECOPT_DODEFAULT,&vZoom, NULL);
Which resets zoom in my DHTMLDialog to 100%.
Source: Here