I have a wxpython application, and I'm using both a toolbar and a wx.glcanvas.GLCanvas sub-window to draw my client area content. The toolbar is vertically just above the GLCanvas. When I roll over a tool and the tool tip pops up, it often (but not always) gets overdrawn by the GLCanvas, so the part of the tooltip that extends into the canvas area gets whited out by the all-white canvas rect. As I say, it doesn't happen all the time -- sometimes the tooltip shows over the canvas area just fine. I assume the difference is just in whether wxpython (or Windows?) happens to decide to sent me a paint message to repaint the canvas while the tooltip is shown. But even if the canvas is repainted, you'd think it could just respect its z order and repaint under the tooltip. But I realize opengl canvases might be special in not playing nice with the window z order.
Any suggestions for a solution or work-around? I was hoping to be able to tell the tooltips to show above the tools instead of below them, but there doesn't appear to be a way to set that.
Related
Working with widgets, c++ and Linux
need something kind of:
this
but no borders and custom title.
Search for a few days, but nothing.
For now, there is a widget with setWindowFlags(Qt::FramelessWindowHint); and a peace of qss for semitransparent background. How can I blur it? Is is possible at all?
I do not think this can be done with Qt. Blurring can be done using https://doc.qt.io/qt-5/qgraphicsblureffect.html but it is only limited to the widgets painted by Qt. Which the underlying background is not, even if you manage to make your widgets transparent or semitransparent. Painting the background is always the business of the operating system (or window manager) and not the business of your application Qt.
You can certainly try to do some extreme hacking like grabbing the active screen before your window is displayed (see How to capture the current screen image using Qt?) then getting certain rectangle content of the image, which corresponds to the background of your window, then paint it blurred to the background of your application and then update it everytime you move or resize your window... But anyway, even if you manage this, this background will be static and not dynamic.
I recommend that you abandon the idea of blurry background and leave this function to the window manager and the operating system.
I'm upgrading an old MFC app to support 4K monitors. According to what information I can find, CPropertySheetEx 'implements Wizard97 style functionality'. It's a dialog with Previous and Next buttons and a banner.
Now MFC has done a poor job of scaling this dialog and I'm not sure what control I have over it.
4K is usually 200% scaling. The banner height is unchanged at 59 pixels (so is too small on a 4K monitor). The rest of the dialog seems to have scaled to about 150% (width, height).
I've tried SetWindowPos on the banner. This doesn't resize it and causes other dialog issues.
There's this note in the code, which makes me think the banner is dynamically constructed with the property sheet.
// If the page has a header, we need to paint the area above the border.
// By inspection (Spy++), the border is a static control with ID 0x3027
CWnd* pTopBorder = GetDlgItem(0x3027);
Any suggestions or guides would be appreciated.
The app is DPI aware. Many MFC components scale properly (some need some work)
Question - How can I get CPropertyPageEX dialogs to support scaling?
Here's an image ![Scaling Issue]https://imgur.com/a/Ww8SLnU
Edit -
The icon and the text in the banner can be resized and repositioned, only the height of the banner seems stuck at 50 pixels.
CPropertyPageEx is defined as CPropertyPage in MFC 11. It's derived directly from CWnd.
Having a look at the sources for CPropertyPage (atlmfc\src\mfc\dlgprop.cpp) there's no constructor where it creates buttons or banners (so I may be looking in the wrong place).
A PropertySheet seems to consist of
a graphic (user supplied),
a horizontal bar (static control),
a dialog resource from the Property Page currently displayed
another horizontal bar
a series of buttons (Prev , Next etc)
Have a look at my high def screenshot https://imgur.com/a/yR97H96
The dialog and controls have rescaled
The vertical position of the horizontal bar and the property page are both unchanged from the unscaled version, leading to the ugly overlap you can see.
.
I want to make my own scrollbars for a custom drawn plot, like this image, what would be the best way to go?
Scrollbars should:
Only be visible when mouse hover over it (with fade in/out)
Be a part of the x/y axis of the plot, like in the picture
Not have any arrow buttons, just the thumb Thinner than the normal scrollbars
Would you suggest to:
Create everything from scratch, handling paging, scrollwheel etc.
Try to inherit CScrollBar and do my own drawing?
From what I've read, it's not very easy to customize scrollbars in MFC, for example here)
First off, these have to be scrollbar (or other) controls, not window scrollbars (used for scrolling a window).
Second, the statement "it's not very easy to customize scrollbars in MFC", is only partially true. MFC is a "thin wrapper" of Windows API, so you should better refer to the documentation of the Windows scrollbar control.
Then there is the CScrollBar class, but took a short look, and indeed, it does not really offer anything more than the Windows scrollbar does. As for the sample in the link you posted is a new (custom) control (painting everything on its own), i.e. literally "from scratch", not inheriting anything from CScrollBar.
So, you have to look into the Windows scrollbar control, and what it offers. Did take a look, and saw few things. Unfortunately there seems to be no owner-draw functionality. You can process the WM_CTLCOLORSCROLLBAR message, but this only allows you to change colors.
And according to the documentation the background color only. This appears to be the only possible customization, apart from the SBM_ENABLE_ARROWS message, which can hide the arrows. And no fading effect. If these are enough to you, you could try the Windows/MFC scrollbar, otherwise try writing your own.
I wanted to develop a widget container (still on python 2.7 and gtk2), which would be placed in a scrolled window, and could be freely moved and resized in the window, such that: click & drag within the widget would move it inside the window; and when widget's corners / edges are visible in the window, it would expose drag handles for resizing - otherwise, if it is bigger than the window area, it would scale up and down (zoom in and out) on middle-click.
Of course, I want to keep the amount of custom coding of this widget to a minimum, so I though looking into what's available in gtk2 first. It turns out, the only element exposing resize drag handles is gtk.Window - and at that, only if it is a main (or root) window; otherwise, if a window is placed inside a widget, its size is apparently set by the widget, and so there are no drag handles (not menus, titlebars etc). I was wandering why this is - and it seems it is due to multiple document interface (MDI) being considered evil by gtk developers, see e.g. Re: [gtk-list] Resizing widgets with a mouse or Does GTK support MDI? - Linux/BSD whirlpool.net.au.
Just to demonstrate the behavior that I want, I used a PyQt4 code from Python PyQt/PySide QMdiArea subwindows scroll not working in TabbedView - Stack Overflow, since as it turns out, Qt does have an MDI area. So here's the gist of it - if a corner is visible, a resize drag handle appears, and resize drag action can be started:
When you thus drag the corner outside of the window - the scrollbars automatically indicate the new size/position of the inner widget (note the window got also moved a bit in this screenshot below, that was manual and unintended):
Again, I don't really need a window (as in titlebars, menus) - just a widget container that would behave in this way, so I could put e.g. a table (e.g. TreeView) or an image in it, as the situation demands - and at least not worry about recalculating the "outer" scrollbars (naturally, I'd expect I'd have to code the rest of my custom behavior myself). Also, I just need a single widget placed in a window like that for now (so no "multiple document"s).
While Qt seems to offer this in a way, I don't have the possibility right now to get into it to the level of doing something like this; and the same goes for WxWindows (see e.g. wxPython-users - How to resize Widgets? - possible, but as there is no code there, I cannot see if geometry calculation coding is required or not).
So I was wondering - is there a widget I may have missed, that would implement the above behavior, and that I could take as a base for customization? If not, what options do I have to implement something like the above on gtk2 (eventually with Python)?
I'm not sure this would work, but I suggest looking into GtkOffscreenWindow; put the inner widget into that, and render it to a GtkDrawingArea inside a GtkScrolledWindow. This would probably make the scrollbars behave properly depending on the size of the drawing area.
What you won't get:
window titlebars, you'll have to render those yourself because GTK doesn't know about them, they're part of the window manager. (Note, the inner window in the Qt example has a different titlebar than the outer window - I suspect this is the same thing.)
drag handles to resize the window, you'll have to code those yourself, as you expected.
You might also want to look at how the Glade GUI designer does this.
Let's say that I have an application frame, and I want to show a popup QCalendarWidget over on the right side of the frame. Normally, QT will clip the edges of the QCalendarWidget, cutting it in half and not displaying the rest, as it would be over the right side border.
Is there a way to work around this limitation without resorting to implementing a QDialog?
I want the widget to be visible outside the bounds of it's container.
If you'd show your Calendar, let's say, after a button click, as QDateTimeEditor does, it's contents will not be clipped, cause it do not belong to frame. It will be just a widget, that shows in a dialog manner. And maybe you should even place it in QDialog, that is modal and provides some convenience methods, rather then simple QWidget.
Btw, why don't you want to use QDatetimeEditor?