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
Related
I should design a dialog with size 640*480 ,which can be used on 800*600 resolution.
At present my dialog size is 411*292 ,look wise this itself looks good enough ,but actually I was
asked to design dialog with the size I mentioned above.I tried that also but that dialog is too biger
than my earlier dialog of 411*292 size.
while using in 800*600 resolution or my dialog seems to be bigger and not able to see some of my controls
This is size of my dialog,
IDD_DIALOG_MYPAGE DIALOGEX 0, 0, 411, 292
can anyone please let me know how to design a dialog with 640*480 (which should not be bigger).
And how can I make my application to fit to any resolution so that all the controls on the dialog should be visible.
Dialogs are scaled in Dialog Units and Dialog Units scale upon the current UI settings and depend upon the System font. So if the user selects a larger UI representation your Dialog will grow too.
Best advise 1 I could give: Size all you controls by youself. Pick a font you like. Set it to the Control, calculate the positions ofthe new controls and use SetWindowPos/MoveWindow.
Only in this case you have full Control.
You may also use a fixed font size in the Dialog resource, but alos this font scales upon the DPI untis selected for the Screen...
So best advise 2 I could give: Scale upon the DPI/UI Settings and Show the dialog n a size that the user wants too, thats what a normal dialog will do...
You're in for a world of pain. If I understand correctly, you're being asked to make a dialog that will always be 640*480 pixels. It seems like whoever is asking hasn't kept up with UI development since 1995. 'Pixels' are meaningless in 2014. First, the units in resource files are in 'DLUs', 'Dialog Length Units'. See e.g. http://blogs.msdn.com/b/oldnewthing/archive/2004/02/17/74811.aspx and support.microsoft.com/kb/125681 for some starters on how to convert one to the other. However, with high DPI displays these methods are insufficient. Now it doesn't just depend on the size of the system font any more, but also on the settings the user has selected for how big to display 'things' on various monitors, whether to differentiate between monitors at all, etc. See for a start http://msdn.microsoft.com/en-us/library/windows/desktop/dn469266%28v=vs.85%29.aspx . But beware, because there are updates to these API's - e.g. Win7, Win8 and Win8.1 all have new features in this regards.
All of this of course doesn't help you. It's not terribly hard to make a dialog that will fit on 640x480 and up; just make it as small as possible. But this part: "And how can I make my application to fit to any resolution so that all the controls on the dialog should be visible." is really difficult. Does 'any' mean 'also smaller than 640x480'? And does 'fit' mean that it should look 'native' also on higher resolutions? Should the dialog be resizable? You can either go with the simple and robust approach suggested by xMRi above, or you will have to ask whoever is writing your spec to be more clear about what they want, keeping in mind all the things I outlined above.
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.
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
When using a QListWidget in batched layout mode, whenever more items are added than the batch size, the list widget blinks for a short time when switching from the old list to the new list. This means, the list widget shows no items, and the scroll bar handle is set to a seemingly random size.
Have you ever encountered this, can this be resolved somehow? I'm using Qt 4.7.4. I should probably add that I'm not using any hidden items.
I had this issue also and spent hours combing through the sea that is Qt widget rendering. Ultimately, like you, I traced the problem back to the batch processing of the QListView. It appears, that when batch processing is enabled, Qt fires off an internal timer to perform incremental layout adjustments of the underlying scroll view. During these incremental layouts, when the scroll bar is visible, the update region is not computed correctly (it's too big and does not account for the regions occupied by the scroll widget(s) themselves). The result is a bad update region that subsequently finds its way into the viewport update which has the unfortunate side-effect of clearing the entire client area without rendering any of the ListViewItems.
Once the batch processing is complete, the final viewport update correctly computes the layout geometry (with the scroll bar) and produces a valid update region; the visible elements in the list are then redrawn.
The behavior worsens as the number of items in the list grows (relative to the batch size). For example, if your list grows from 500 to 50000 items and a batch size of 50, there is a proportionate increase in the number of "bad repaint" events which are triggered causing the view to visibly flicker even more. :(
These incremental (and failed) viewport updates also appear to be cause the apparent spazmodic behavior in the scrollbar handle position that you describe.
The root of this issue appears related to this "hack" that was added to
QListView::doItemsLayout() as commented here:
// showing the scroll bars will trigger a resize event,
// so we set the state to expanding to avoid
// triggering another layout
QAbstractItemView::State oldState = state();
setState(ExpandingState);
I suppose you could override QListView::doItemsLayout() and provide your own batch processing which handles scroll bars properly, but personally I'm too old and lazy to be cleaning up someone else's poo. Switching to SinglePass eliminated the problem entirely. Seamless flicker-free rendering and the scroll bar behavior you've come to expect and love. Yay.
I'm trying to implement some drag and drop functionality for a material system being developed at my work. Part of this system includes a 'Material Library' which acts as a repository, divided into groups, of saved materials on the user's hard drive.
As part of some UI polish, I was hoping to implement a 'highlight' type feature. When dragging and dropping, windows that you can legally drop a material onto will very subtly change color to improve feedback to the user that this is a valid action.
I am changing the bar with 'Basic Materials' (Just a CWnd with a CStatic) from having a medium gray background when unhighlighed to a blue background when hovered over. It all works well, the OnDragEnter and OnDragExit messages seem robust and set a flag indicating the highlight status. Then in OnCtrlColor I do this:
if (!m_bHighlighted) {
pDC->FillSolidRect(0, 0, m_SizeX, kGroupHeaderHeight, kBackgroundColour);
}
else {
pDC->FillSolidRect(0, 0, m_SizeX, kGroupHeaderHeight, kHighlightedBackgroundColour);
}
However, as you can see in the screenshot, the painting 'glitches' below the dragged object, leaving the original gray in place. It looks really ugly and basically spoils the whole effect.
Is there any way I can get around this?
Remote debugging is a godsend for debugging visual issues. It's a pain to set up, but having a VM ready for remote debugging will pay off for sure.
What I like to do is set a ton of breakpoints in my paint handling, as well as in the framework paint code itself. This allows you to effectively "freeze frame" the painting without borking it up by flipping into devenv. This way you can get the true picture of who's painting in what order, and where you've got the chance to break in a fill that rect the way you need to.
It almost looks like the CStatic doesn't know that it needs to repaint itself, so the background color of the draggable object is left behind. Maybe try to invalidate the CStatic, and see if that helps at all?
Thanks for the answers guys, ajryan, you seem to always come up with help for my questions so extra thanks.
Thankfully this time the answer was fairly straightforward....
ImageList_DragShowNolock(FALSE);
m_pDragDropTargetWnd->SendMessage(WM_USER_DRAG_DROP_OBJECT_DRAG_ENTER, (WPARAM)pDragDropObject, (LPARAM)(&dragDropPoint));
ImageList_DragShowNolock(TRUE);
This turns off the drawing of the dragged image, then sends a message to the window being entered to repaint in a highlighted state, then finally redraws the drag image over the top. Seems to have done the trick.