I want to resize the frame window in a SDI application to a given dimension of the child view window (I want the frame to fit the dimensions of an image). Can anyone describe an (elegant) solution to finding the relation between the child view client size and the frame window size without actually resizing the window?
Currently I am using GetParentFrame()->MoveWindow(,,,) to resize the frame window. I already tried to observe the difference between GetParentWindow()->GetClientRect() and GetParentWindow()->GetWindowRect() but it does not help.
Have a look at CWnd::CalcWindowRect. It computes the size of the window required to hold a given client area. I've never used it so I don't know how it deals with toolbars, etc. but I think it can be a good starting point.
Related
I am rendering text with ID2D1HwndRenderTarget.
When there is a change of the UI window size, I want to prevent the stretch of the text being rendered - so it will be unchanged until I will directly make a rendering command.
On Direct2D documentation the behavior is described:
If EndDraw presents the buffer, this bitmap is stretched to cover the
surface where it is presented: the entire client area of the window
I know the ID2D1HwndRenderTarget::Resize method but I don't want to update the size immediately, just going to use it later on according to my program needs.
How can I ignore windows events to prevent this visual stretch?
You are already ignoring size change messages, and that's why surface size does not match client area size when presenting. You can try to offset this effect by setting target resolution according to "client area / current target size" factor, right before doing EndDraw(). I have no idea if that will help, or what will happen to uncovered window area outside of current target rectangle.
Hi stackoverflow community,
I am using the WMPHost Sample from the win 7 sdk.
What i want is that when i resize the outer window the windows media player(activex control) should not automatically adjust itself.Instead the video should be clipped.
Do i need to look into the way how activeX control is created or how the host window handles it?
Thank you.
You should look at how the host window handles resizing. Most likely it resizes its child window "to fit"; you may be able to simply remove that code to have your control clipped instead.
You should think about how to size that control first time: to fit its container, or to contain the full size of its content.
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 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+.
The current way that I found was to make a bitmap and paint it into a picturebox,
but there it is very slow when trying to scroll the panel (the picturebox is inside a scrollable panel).
Is there a better way to achieve this functionality?
Load the bitmap only when your picture box is created, then leave it in memory until the picture box is destroyed. Loading the bitmap every time OnPaint is called will destroy performance.
Also make sure you aren't re-painting your bitmap if you receive a WM_PAINT message and nothing has changed.
That image size, 1500x2000 will be slow. How about resizing it to 25% to show a preview and if a user wishes to see the whole image give them an alert it may take some time.