I want to change the color of the background of the grid.
What i tried is
MyGrid.DisplayLayout.Appearance.BackColor = Color.White;
But its not working, it stays with the same color as before.
Ive checked in the debugger and the object has the correct value on that property, the problem is for some reason the grid is not being correctly painted.
Ive also tried calling the ResetDisplayLayout() function, to confirm if the color that was being painted was the default one and it was.
Thanks in advance.
Under Properties for your grid, create an event for InitializeLayout and put it there:
private void MyGrid_InitializeLayout(object sender, InitializeLayoutEventArgs e)
{
MyGrid.DisplayLayout.Appearance.BackColor = Color.White;
}
Try one of the following:
1) In your grid properties set UseAppStyling to false
2) Add a new appearance to the DisplayLayout.Appearances collection, then in code set the grid to use that Appearance
Option two would be the best bet, as otherwise you'll lose any other standard settings, which might make this grid look different to the others in your project.
Are you using a style library? We are, and I need to do one of the above to make the system override the default styles defined in that library. Even if you're not, it may well be that there is a default style library in effect.
Related
I am working on a project that presents live data acquired in real-time using the QCustomPlot plug-in for Qt. The display has a black background color, and the multiple channels of data are colored differently. When taking a screenshot, we would like to make it printer-friendly, so the background is white and all data is black. I am thinking of a solution like this:
Change all colors the way I want by manipulating the pointers for the graphical objects
Grab the screenshot using QWidget::grab() to get a QPixmap
Change all the colors back to normal
This did not work at first, because the system could not change the colors in time for the screenshot to be taken. So I used a QApplication::processEvents(), and it all worked on my Mac.
However, it does not work on a Windows 7 (which is required). Any ideas what to do?
Code:
QSting fileLocation = "...";
toggleColors(false); //function to toggle the colors
QApplication::processEvents();
QPixmap shot = grab();
toggleColors(true);
shot.save(fileLocation, "png");
Again. It works on Mac, but not Windows.
Update 1. Content of toggleColors include:
if(enable)
ui->plot->setBackground(QBrush(Qt::black));
else
ui->plot->setBackground(QBrush(Qt::white));
ui->plot->repaint();
I also tried with ui->plot->update() instead.
I am not sure what is the problem on Windows specifically, but I recommend you calling QWidget::update() on the given widget. That forces the next update to re-render itself.
On the other hand, I'm not sure why toggleColors() didn't somehow cause that to happen.
Also, ensure that QWidget::setUpdatesEnabled(bool) wasn't set to "false."
It appears the problem lies with QCustomPlot. It was solved by performing a ui->plot->replot() which is specific to QCustomPlot and not QWidget.
I want to create a slider which contain a different slider handle and i want to paint it according to slider handle position in the slider.
You could use QProxyStyle to ovrride drawComplexControl method - you will have to draw entire control on your own, as there is no separate flags in QStyle::ControlElement for parts of QSlider.
maybe you should look at this: http://doc.qt.io/qt-4.8/stylesheet-examples.html#customizing-qslider
If I understand you correctly, you want a slider that changes not only its position but also its appearance as you slide, right? For example, a mix of QDial and QSlider, ie. a slider with a turning knob.
If so, you will need to subclass either QSlider or QAbstractSlider (or QDial) and do the painting in your own paintEvent(). Note, however, that you will loose all style-awareness unless you care about that yourself (and that is an interesting topic in itself, see http://doc.qt.io/qt-4.8/style-reference.html for more info).
The Qt demos and examples, or the QSlider/QDial source code itself may serve as examples on how to overload a paintEvent().
I'm having all sorts of size problems with Qt. I am creating my own widgets and using different layouts (generally, I need my own to make them work properly without spending hours on the "powerful" default layouts... which don't lay things out as intended.)
Once I'm done with a widget and its layout though, it doesn't work right. The size is never getting set properly unless I call widget->resize(1, 1); which finally forces a "resize" and makes the widget look correct (i.e. recompute the geometry.) Even the updateGeometry() call has no effect.
This is a dreadful problem when the resize() needs to be called on the parent widget (yuck!) and from what I'm reading should not be necessary were the layouts properly programmed.
Is there a sample that works and is not several thousand of lines long, or does Qt require several thousand lines to make anything work perfectly, even the simplest widget?
What are the minimal functions to be called to make a widget & its layout work at once?
Thank you.
Alexis
P.S. I tried to implement the sizeHint(), minimumSize(), maximumSize(), others that I'm missing? I was hoping that would be enough. Obviously, I also implement the setGeometry() on the layout to resize the children appropriately.
--- addition 1
There is a sample image with a layout that clearly isn't available as is in Qt. The positioning, functions, and colors of the different keys is XML driven and works for any keyboard in the world.
(note, this sample doesn't show the Enter key displayed on two rows and wider below than at the top; more or less, not doable at all with the regular layouts; of course, it works with my version.)
--- clarification
I'm not too sure how to describe the problem better. I was thinking to write a test widget next to see how I can reproduce the problem and then post that and eventually fix it. 8-)
The default layout function that the internal Qt layouts make use of require a lot of coding. I would like to avoid having to copy/paste all of that because for maintenance, it makes it close to impossible.
--- today's findings
As I needed to tweak one of the widgets, I decided to add a VBoxLayout and make it work.
I actually found the problem... One of the widgets in my tree is a QScrollArea and that sizeHint() returns (-1, -1). Not exactly what I'd expect but... whatever you put inside that widget has better know how to compute its width and height or else... it fails.
Looking at the code closely, I could actually compute the width by using the widest width found. Once I used that, the widget would appear (and it actually resizes itself as things change in the list, kinda cool.)
This being said, my earlier comment about having a tree of widgets that auto-resize themselves stands. From the root up to the parents of the leaves in your tree, all of those widgets will need a valid layout. Once I added one in the top widget it resized itself and its children properly (well... in my case up to the QScrollArea, the rest required a bottom to top resizing. Funny how that works!)
--- ah! ha! moment (or: what you find reading the implementation code!)
Today I bumped in another problem which just needed the correct call... I just couldn't find anything worth it in the documentation.
All the objects have a layout now, but a certain parent would not resize properly. Plain simple.
I had a call to the parent as following:
// changes to the children are changing the geometry
parentWidget()->updateGeometry();
Yeah. The docs says that's what you have to do. Nothing happens at all with that call. No idea what it's supposed to do, I did not look at that function. It never did anything for me anyway.
So... I looked at the layout to try to understand how it would send the info up/down. I did not see much except for one interesting comment:
// will trigger resize
This is said of the SetFixedSize mode. To reach that function you need to make the layout for update. Ah! Yes... the layout, not the parent widget... let's try that instead:
parentWidget()->layout()->update();
And voila! It resizes correctly in all cases I have. Quite incredible that the widget updateGeometry() doesn't trigger the same effect...
Although it's possible to do what you want it sounds like the problems you are having are because you're using Qt in a way that it's not meant to be used. Why do you need separate widgets for each key represented on the keyboard?
I see two options, both of which are better in some way:
Use QGraphicsScene and QGraphicsView.
A single custom widget that uses custom drawing to display the keyboard (and likely uses hover for hints).
The first option is probably better. Your keys could then be represented by QGraphicsSimpleTextItem's or even a QGraphicsSvgItem. It also provides a number of standard layouts or you could choose to write your own layout. By default you can use the keyPressEvent or mouseReleaseEvent to respond to user interactions.
I'd highly recommend you take a look at the QGraphicsView examples to get an idea what you can do.
If you go the second route you'll need to record the different key locations so you can respond accordingly as the user moves the mouse around, clicks, etc.
This won't help you with your immediate issue but I wanted to show you a keyboard I made using standard layouts and buttons. It's not perfect and it still won't help you with an enter key that spans two rows but it's not bad. It's resizable too by resizing the window, although I'm not sure if that will be apparent from the images below as SO may be scaling them. (you can view the actual images by opening them in their own tab)
Anyway, this was done using only Qt Designer with no manual coding. It consists of a top level vertical layout with 5 horizontal layouts in it. The buttons are then inserted into one of the 5 horizontal layouts. The size of the keys can be controlled by setting the horizontal and vertical size policies to "ignored" for most of the buttons and then horizontal "minimum" for buttons that you want to be wider. Things can be tweaked by setting min and max size restrictions to buttons. When resized, the buttons will not maintain their relative proportions though, that would probably take some custom programming.
The styling in your example could be approximated pretty well using css style sheets and background images. Still not a minor effort but you should be able to get most of the way there without custom layouts and buttons.
I have a form that contains just a single PictureBox. I have a method that resizes the box to a given size, but the form stays the default 300x300. How do I resize the form to fit the box inside it? Surely there must be a better way than adding hardcoded title bar and margin widths to the PictureBox dimensions.
As far as I know, you can do so by enabling AutoSize (make it true), also keep an eye on the AutoSizeMode (perhaps it's better to set it to GrowAndShrink).
Hope that's useful.
The simple solution is to set the PictureBox::Dock property to Fill and change the form's ClientSize property. Which helps you get to the more efficient solution, no need to burn up a control when you can simply override the form's OnPaint() method and call e->Graphics->DrawImage().
Changing the form's AutoSize property to True works too. Set AutoSizeMode to GrowAndShrink to allow it to get smaller. And a MinimumSize would be advisable.
Beware that it is very unusual for programs to automatically change their window sizes. I can't think of a single program I commonly use that does this. The right way is to leave it up to the user to size and position the windows. Setting the AutoScroll property to True is now the right thing to do.
I've got a QWidget that contains several QLineEdits. When I tell the parent QWidget to change its background color
dynamically, I'd like the children (i.e. QLineEdits) to inherit this modification.
Is there an easy (read: one function call) to do this?
If nothing pops up, I think I'll just loop through the children of the QWidget, but when doing this properly I expect to end up with a recursive function with a lot of overhead, that's why I'm asking.
EDITs in Bold face.
Generally speaking you don't need to worry about "overhead" in dialogs. Unless you're doing some sort of massive draw operation, UI applications simply don't need a lot of optimizations. Digging down to all children and changing their background is a relatively fast operation compared to the Qt system itself actually doing the change.
That said, I'd assume there is a way to get what you want but I don't know what it is. My bet is that it will do exactly what you would anyway.
How are you going about telling it to "change color" btw? Qt doesn't seem to have operations to do that. You can assign a background role or change the pallete. As to the latter:
http://doc.qt.nokia.com/4.7/qwidget.html#palette-prop
If you set the background color using a style sheet assigned to that widget and don't specify any selectors in the CSS, all child widgets will inherit any properties that apply to them.
I found it useful to use a selector that allowed me to target specific widgets for a certain style.
QWidget[objectName|="special_color"]
{
color: rgb(255, 255, 255);
}
If I used this in a style sheet assigned to a container widget, it would apply the specified color to any child widgets whose name started with "special_color" like "special_colorEditBox1" no matter how they are nested or contained.