I have an application which worked well so far.
Today I have updated my ubuntu to 18.04 and therefore reinstalled all software components, including Qt.
Now I experience a pretty wired behavior.
When I compile my application in debug build, everything is correct. When I switch to release build some combo boxes become invisible.
What is strange is, that events still work, the comboboxes are still there (but invisible).
I know this because I use an installEventFilter()
with if(event->type() == QEvent::Enter) which changes some other widgets if I hover the combo box with the mouse. Although the combo boxes are invisible the events still work when I hover the area where the combo box would be located.
Unfortunately, I do not know what makes this issue, so I cannot reproduce it in a minimal example.
My question is: Did anybody experience something like this before?
And: Where should I start to look for the error?
(I cannot debug it because everything is correct for debug builds)
By the way: I do not know if this is related but when I first tried to run the application I got an error that gl/gl.h was missing. After asking my friend google for help I found out that OpenGL was missing, so I installed it.
I would go and look for uninitalized variables when setting the properties of the combobox. Usually in debug even unitialized variables are set to some fixed value.
Or maybe you are setting properties in an assert that is not compiled in the release build? E.g. like this
Q_ASSERT(...)
that code in between the () will just be skipped during a release build.
Related
I am coding a C++ project using MFC in Visual Studio (v16.5.4). The dialog editor seems badly broken on my HiDPI monitor (Lenovo ThinkVision 2880x1800 at 175%). It works fine on two other computers with standard monitors.
The dialogs get resized apparently randomly, and controls do not move correctly when I try to edit them. When I try to align controls the dotted selection rectangle may move, but the control often does not (in the editor). Sometimes, re-opening the editor shows that the control has in fact moved. When I build the project, the final display layout cannot be predicted from what appears in the resource editor.
I reported this to Microsoft using Visual Studio feedback, but they closed the report, saying it was "By design"!!!! They posted a link describing a feature which disables HiDPI awareness, but the link was for the Windows Forms Designer, not the MFC resource editor - there is no equivalent feature in the latter that I could find.
Does anyone else have this problem, or know of a decent work-around? At the moment I am transferring to my other computer with the standard display whenever I need to edit a dialog, which is monumentally inefficient for quite a large project.
I know this is an older post, but I thought what I found might help someone. I experienced the same issue today. It just happens that I have one monitor setup for 125% and one setup for 100%. The MFC dialog editor alignment operations do not work correctly on the 125% monitor but work fine on the 100% monitor. It would appear Microsoft isn't properly handling DPI in the dialog editor.
I have some legacy code made with Borland C++ Builder 6 that I have to port from Windows XP embedded to Windows 10 IoT.
It all seems to run properly, except dialog forms which aren't drawn properly. When I call ShowModal on the forms to show them, they flash quickly and then seems to disappear. However they are not gone, instead they are just not drawn and the form behind the dialog is seen. The dialog form buttons can still be pressed (if we know where they are).
I have tried all possible redrawing, refresh, repaint and update functions I could find, but nothing seems to work.
To make matters worse, dialogs containing actual control elements (like one containing a set of TSpeedButton elements) the controls are redrawn when moving the mouse over them, but anything else are not redrawn.
I have tried to search for similar issues but can't find anything for this.
Could this be solved? Or do we have to update to a newer Embarcadero version of the IDE to be able to solve it (which is a lot or work and not really something we can do at the moment)?
The problem was the use of a Billenium Software (now defunct) package for "fancy" transitions.
The transition in question "zooms" a dialog open, and it just doesn't seem to work. Disabling this transition will solve the problem of the disappearing dialogs.
I still don't know if it's a problem with the components Windows 10 compatibility, or with its 64-bit system compatibility.
I recently updated the GTK3 lib I am using, both on windows and linux,
from version 3.20 to 3.22, and I noticed some bugs in my application (GTK3 + OpenGL using the GtkGLArea widget) appearing after the update.
The bug, namely the disappearance of window decoration appears after a precise, yet simple, succession of events:
1) screen shot before the bug:
2) Exporting an image from this window (using a framebuffer for off-screen rendering)
3) After saving, going back to the main window by closing the dialog box, note that the upper menu bar now appears like if de-activated (grey) but sill works:
4) ... and when re-sizing / hiding / showing again 'ie. configuring' the window the decoration disappear:
5) The menu bar still seems to be there and works fine:
Obviously I looked carefully to the code after the saving action, but what happens remain elusive to me and I do not know what to look for.
The program does not stop and keeps working fine.
There was absolutely no problem with GTK3 3.20, and the bug appears both on windows and Linux.
What can I do to correct this situation ?
In the Gtk-3 series there have been many changes to the CSS system. If you are not using the default Adwaita theme, then probably you have to search for an updated version of the theme you do have installed. It might even be possible that the Adwaita theme wasn't update correctly during your upgrade.
Anyway, nearly all appearance problems are due to changes in the CSS system - Gtk doesn't really occupy itself with the aesthetics anymore.
I have a UI written in Qt that makes extensive use of dock widgets, primarily so that end users can customize which which docks are available, and how they are arranged.
We recently upgraded to Qt 5.6.1, and the dock widgets can no longer be rearranged on Ubuntu, although they still work on windows and other OS's. When you try to move the docks, the rubber band still appears as usual showing the new location, but when dropped the dock just snaps back into whichever position it started in, which is always tabbed somehow.
After several hours of searching, I think the problem is related to QTBUG-54185, and I'm wondering if there is any way to work around the bug while we wait for the Qt 5.6.2 release which fixes it.
The bug is related to having the AnimatedDocks property disabled. QDockWidget rearranging still works, even in spite of the bug, for dock widgets which are animated.
The problem was that in the code, the main window was setting the dock options manually as
mainWindow->setDockOptions(AllowTabbedDocks);
Since DockOptions are OR'd, what is happening here is that the AnimatedDocks property, which is enabled by default, is being unintentionally disabled. The solution for me was to delete the offending line, since the default options are AllowedTabbedDocks|AnimatedDocks, which is actually what I wanted all along.
This is my first question in this community. I always search a lot when having problems and I always find an answer. But not in this one. Maybe I am not asking Google correctly.
Anyways this looks like a bug to me but I might get it wrong.
Using VS2012 (or 2013) I create the default Multiple documents MFC application. I do not write a single line of code. I compile and run. Then as a user I dock the properties window which by default is at the right to the output window as shown below .
Then I close the application and restart. The window is where it should be but with different width as shown below
If you dock the window to the right (in the view and not in another window) then there is no problem. The position and width are restored just fine. Also this only happens if the main window is maximized. The behaviour, if the main window is not, is as expected.
Do you think it is actually how Microsoft wanted to make this work or they missed that? Is there a workaround for this?
Again forgive me if this question has been asked before but really...
I couldn't find anything.
Appreciate any kind of help.