Premise: I need to change the colors of the default CScrollBar defined in MFC (thumb + track + arrows), but after doing some research I realized that this isn't exactly an easy task.
Question: would it be better if I tried to draw OVER the existing scrollbar, or should I create a new scrollbar control from scratch?
If I limited myself to drawing on it, I would have the advantage of not having to manage all the messages that deal with the other features of the scrollbar (in addition to the drawing), but it is VERY complicated to find all the points where windows redraws the bar, since the scrollbar is not redrawn only in the OnPaint() method.
If I redo it from scratch, I would no longer have the problem of identifying all the points where the bar is redrawn ... but on the other hand I should reimplement all the scrollbar features from scratch.
I've already looked at this link:
https://www.codeproject.com/Articles/14724/Replace-a-Window-s-Internal-Scrollbar-with-a-custo
but the proposed method does not seem to work for newer versions of Windows (from Vista onwards).
Any advice is appreciated, thanks in advance.
We had exactly the same problem and your attempt to overdraw the original scrollbar was what we tried first. We dropped that attempt again due to some issues, which I don't remember in detail (not receiving all mouse or draw messages, flickering, ...). Our solution was some effort, but works now:
We implemented first a class CCustomScrollBar, which is NOT derived from CScrollBar, because the CScrollBar is just a wrapper around the Windows implementation and overwriting OnPaint() doesn't work perfect. And yes, all things must be implemented from scratch.
Second we implemented a template class CWndCustomScrollBar keeping two CCustomScrollBars and managing all around them as a standard window would do with its embedded scrollbars. The free client area then can be achieved via a method GetClientRectWithoutScrollBar() to work similar as a standard window would do.
Related
I think I understand the reasoning behind Wayland preventing windows from being manually positioned but there are a couple of instances in my Qt 5.15.2 application where I really need to have either some or absolute control over the position:
In the first instance the window is a pop-up. I'm using a QMainWindow so I can have it borderless with rounded corners, a coloured background and a transparency. I need it to pop-up when I hover over a certain element on my QGraphicsScene but want to ensure that when it appears it is close to the QGraphicsScene element in question but does not obscure it. Using a call to QMainWindow::move was perfect pre-Wayland and works fine on Windows too.
In the second instance my application has a number of windows which the user may open and close over time. The first time each one opens I don't care too much where it is positioned but if the user moves it before closing it then the next time the user opens it I want it to reappear where the user previously left it. Again, using the move() method of the various things that inherit from QWidget was perfect pre-Wayland.
Does anyone know of any work-arounds that would solve either of these problems under Qt on Wayland? It seems to me that neither is a particularly uncommon requirement and if Wayland won't let me set a specific position it might have a way of achieving something similar (e.g. a way of telling the compositor to position something near something else without obscuring it) and hopefully that maps onto something in the Qt API.
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 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 implemented my custom button inheriting from CButton and drawing it by using uxtheme.dll (DrawThemeBackground with BP_PUSHBUTTON).
Everything works fine but I have two statuses (Normal and Pressed) which Hot status is the same. It means when the user places the cursor over the button it is drawn alike regardless the button status (Pressed or not).
This is a bit confusing to the user and I would like to change the way the button is drawn in Pressed & Hot status. Does anybody know a way?
I have also thought about custumizing the whole drawing but the buttons use gradients, borders, shadows, etc. So it is not easy to achive the same look&feel drawing everything by myself. Is there a way to find the source code of the dll or know how to do it?
Thanks in advance.
Javier
Note: I think I could be able to achive what I want to do by using CMFCButton and overriding the OnDraw method. Let the control draw the button on OnDrawBorder and then drawing the inside button myself. But I need to know how the control draws the inside button when pressed. It is a gradient and I can't guess how it's done. Does anybody have a clue?
In answer to your second question, if you derive from CMFCButton instead of CButton you can override OnDraw() or OnDrawText() instead of the usual DrawItem(). That way the default button background will be drawn, and then your drawing code is executed.
The only way I know of to really tackle this is to use 'custom draw', rather than 'owner draw'. Custom draw came in with Windows 2000, but is only used by button controls with comctrl32 6.0 (so Windows XP onwards), isn't very clearly documented, and isn't something MFC goes out of its way to support.
Anyway, the good thing about custom draw is that it lets you hook in at various points in the drawing process, unlike owner draw, which makes you deal with the whole thing. Have a look in MSDN at the NM_CUSTOMDRAW notification message.
For the other part of your problem, detecting the 'hot' state, the easiest way to do this is to use WM_MOUSEMOVE messages and the TrackMouseEvent() function to track whether the mouse is over your button.
Unfortunately this is a bit of a vague answer: the amount of code you need to demonstrate a button that uses custom draw is a bit too much to type into these answer boxes! I do have a project that demonstrates such techniques, using a custom draw button (falling back to owner draw on older Windows versions) that adds a little arrow to the button. You can have a look at the source code by getting
Windows_UI_source.zip
Open it and have a look at the "DropArrowButton" class. The important bit is the OnCustomDraw() handler and its helper function DrawControl(): these get called at the various button drawing phases, and use UxTheme to draw the control appropriately.
I finally figured out how to achive what I want to do. It's pretty easy indeed.
I use two calls to DrawThemeBackground. The first one with PBS_PRESSED and the second one with state PBS_HOT. Then I make a ExcludeClipRect to avoid from drawing over the center of the button.
Something like this:
DrawThemeBackground( hTheme,
pCustomDraw->hdc,
BP_PUSHBUTTON,
PBS_PRESSED,
&pCustomDraw->rc,
NULL);
CDC *pDC = CDC::FromHandle(pCustomDraw->hdc);
CRect rectClient;
GetClientRect(rectClient);
CRect rectInternal = rectClient;
rectInternal.DeflateRect(4,4);
pDC->SelectClipRgn(NULL);
pDC->ExcludeClipRect(&rectInternal);
DrawThemeBackground( hTheme,
pCustomDraw->hdc,
BP_PUSHBUTTON,
PBS_HOT,
&pCustomDraw->rc,
NULL);
pDC->SelectClipRgn(NULL);
Of course this is not the whole code but I think is enough to make my point.
Thanks.
I'm looking for a really good dialog resizer class that will stretch and shrink individual items as needed as the screen is resized. Stephan Keil has a good one (DlgResizeHelper) which basically resizes everything by a set ratio, but I'm looking for something smarter.
For example:
Icons should not resize
Single-line text boxes should not be stretched vertically
Buttons should probably stay the same size
Basically I'm looking for something to look at all of the controls, figure out that a static text field is related to a control next/below it and anchor the two together, and resize large controls in a 'smart' way so it looks good.
Are there such frameworks out there? I've been working on one but something ready-made would probably be better.
FOLLOW UP: I'm looking at the suggested solutions. Many of them require you to go in an anchor each control on the dialog. I'm looking for something smart that will figure out what the anchors ought to be, with the ability to manually anchor if the guesses are wrong. Seems like it should be possible -- most humans would agree a static text field next to an edit field should be anchored together. Guess I'm almost looking for a little AI here :)
You can use wxWidgets. It completely replaces MFC, is multi-platform, and gives you a layout-based dialog mechanism.
I use ResizableLib (also does PropertySheets and Pages) off codeproject, IIRC. You set anchor points that determine how the dialog and controls resize or move as the dialog moves.
You can set up to 2 anchors per control, (left, right) so you can move them as the dialog moves, or resize them as it moves. Its very easy to understand, if difficult to get perfectly right :)
I've tried many and finally settled on http://www.codeproject.com/KB/dialog/layoutmgr.aspx. It doesn't do the 'intelligent' layouting that you suggest though. I've never seen that in any library, on any platform - I don't see how it would work without having lots of under the hood magic that'd have to be overridden half of the time anyway.
The Ultimate Toolbox MFC library (here on CodeProject) includes a layout manager. I haven't used it myself, but it looks like it does what you want.
You can look at Professional GUI we use their class library for resizing our dialog controls. I think that is part of their free version.
We use CResize class from CodeGuru to resize all controls automatically. You tell how you want each control to be resized and it does the job for you.
The resize paradigm is to specify how much each side of a control will move when the dialog is resized.
SetResize(IDC_EDIT1, 0, 0, 0.5, 1);
SetResize(IDC_EDIT2, 0.5, 0, 1, 1);
Very handy when you have a large number of dialog controls.
Source code
This is a free solution also from CodeProject
http://www.codeproject.com/KB/dialog/dlgresizearticle.aspx
It's just a set of simple macros that position controls as the dialog resizes.
Edit - following the OPs comments. I don't know of any general sizer support like QT/WX for MFC, it doesn't seem to be present in new frameworks like Winforms either.
It is in QT/WX because it is necessary for multiplatform where widgets may be a different size, which explains MS lack of it. But it is also vital for multi-language ports, eg. where the German for cancel is 30 characters long.