I have done a Windows form application in Qt and I have some QPushButton, QGroupBox and so on and the application is working great.
But when i leave the application to the next day, i see that all frames around buttons, groupboxes and all widgets that have frames dissapears. But the application still working as it should.
Here i have edited a picture how it looks.
Application sets some stylesheets on some widgets in other dialogs, and sets some widget enabled on and off.
But is there anyone that has got same problems? And maybe have an explaining why it happens?
Perhaps, your program leak GDI Objects.
A windows application can only use 9999 GDI Objects.
when your application leak too many GDI Objects, your application will looks look as your picture.
You can press Ctrl+Shift+Esc to see how many GDI Objects your application used.
Related
I've got application for applications sharing (over network). I need to highlight application's window when it is in sharing state. Currently I use GtkWidget to create border around the window to show that the window is shared. However there are a lot of problems with this approach (need to hide border when application is minimized, need to resize border when application has changed it's size, etc.).
So the question is there any way to show that the window is shared (highlight it somehow or make it flickering or something like that) using xlib (or gtk) API? I didn't find any useful info in the Internet, so I had to ask it here.
Thanks.
I was looking at how sometimes when you right click, the menu goes outside of the window.
Is this implemented with a separate window? If so, how can I get this functionality. I am trying to use GLFW, but I understand if it isn't possible.
Currently I am on windows, but I like keeping my options open, which is why GLFW would be preferable.
I noticed that GLUT has such a feature. If you are confused to what I am looking at then look at that.
Thanks for any help!!
Overlapping menus (in MS Windows) have to be implemented as a new top-level window, you would have a new OpenGL rendering context and draw the menu in that space - yes, it's a fair bit of work all for the edge-case of a menu overspilling the parent window,
However this isn't often a problem in OpenGL programming because if you're working on a full-screen game then the menu will always be displayed within the main window, and even if it isn't a full-screen a game your users really won't notice them as games tend to use different UI concepts like radial-menus which wouldn't overspill the parent window.
Or if you're working on a non-game title, chances are it isn't full-screen and is going to be an OpenGL rendering area within a larger application that is rendered using a native UI toolkit (e.g. 3ds Max, AutoCAD, etc), in which case no problem: just use native menus.
You can, of course, use native menus in an OpenGL application anyway, provided you do the necessary plumbing for native window messages.
I'm using Qt5 in Windows. I just created a simple little widgets project in Qt Creator. I have a QMainWindow with a text edit widget inside. I enabled vertical layout, so the text edit consumes the full size of the inside of the main window (which is what I want, I'm trying to create a small notepad app).
As I drag the bottom right corner of the main window during the preview (I click the green triangle in the bottom left) I'm seeing a slight delay in the child widget's resizing. It doesn't exactly resize with the parent window on the same render frame (it seems like it is 1-2 render frames behind).
I remember years ago dealing with render lag like this in old school Win32 API. I remember I had to do double-buffered rendering into an offscreen bitmap to fix it (or something along those lines; been a long time).
Is there a way to fix this "render lag" in Qt? I can only imagine this is specific to Windows and might not impact other platforms, although I have not tested. If I need to provide more information let me know.
It is likely a Windows problem, not Qt's. The more GUI-heavy your window is the more noticeable it is.
I investigated the same issue a while ago. We had a rather GUI-heavy window, with several widgets displaying 2D and 3D views of data. Resizing the window using lower-right corner resulted in a resize-redraw horror. Unfortunately it looks like the problem is not Qt related but rather the way that Windows handles redrawing a resized window. I was able to notice the problem even in the file explorer on Windows 7. Qt is indeed using double buffering by default (as mentioned in the comment by #Bim). I also tried explicitly triggering Qt's repaint events. This helped a little, but did not solve the problem. So after many efforts we just decided to live with it.
I have developed my Application with most of the Widgets in Qt Creator's Designer module.
I have hard coded the sizes of my widgets depending on how they appeared on my laptop. Yesterday when I ran the application on my Desktop (lower screen resolution than laptop) some of the Main Window widgets were not visible & on startup there was horizontal scrollbar & I had to scroll to see those widgets; which is not the case on my laptop.
I have 2 problems:
Is it possible to resize all of my widgets (even those which are added run time by code) by using some resize factor? Maybe at startup I will get the screen resolution of Hardware in which application is running & then create a ratio of that with resolution of my laptop. Is it possible to multiply this factor to all widgets without adding code for each widget?
How do I get the resolution of the Screen in which my Application is running?
PS: I would like to know the defacto method of solving this problem...
Thank You.
You could try a function like this:
resize(theDesktop->screenGeometry().width()*PERCENTAGE_OF_MONITOR_WIDTH_FOR_SCREEN, theDesktop->screenGeometry().height()*PERCENTAGE_OF_MONITOR_HEIGHT_FOR_SCREEN);
Resize is a member function of the QWidget class and the PERCENTAGE_OF_MONITOR variables would be whatever percentage of the monitor you want your application to take up.
theDesktop is of the type QDesktopWidget.
You should use Layouts to manage the size policy of your widgets.
Qt layouts automatically position and resize widgets when the amount of space
available for them changes, ensuring that they are consistently
arranged and that the user interface as a whole remains usable."
You could also check this question for more information regarding layout machanisms in Qt.
Qt website has got excelent documentation on the subject. You can start here for more information on working with layouts in Qt Designer.
I have a general question on how to develop an image viewer plugin with Firebreath. For that, I would like to incorporate a GUI framework, like wxwidget or Qt. The GUI would be used to to fire up some dialogs, adding a toolbar on top, or to open context menus with right clicking an image.
As far as I understand I have a hwnd handle and so I can draw onto a window. I also understand that I have various events I can react on, like mouse button clicks or keyboard strokes. But it fails me how I would add graphical menus, buttons, etc. I know I could use html around the window but that's not the route I like to take.
For instance, does it makes sense to render an user interface offline (in memory) onto an image and then keep somehow track of the state internally?
Has anyone done such thing? Or can anyone give me some insight on how to accomplish adding a user interface.
Assuming you only care about windows and assuming that you don't mind using a windowed plugin, which is the easiest (but no HTML elements can float over the plugin), it should be no different than creating a GUI in any other windows application.
You are given a window that shows up with the AttachedEvent; when DetachedEvent is fired you need to stop using the window. Many people create a child window inside that parent window and use that for all their actual real code which makes it a little easier to use one of those other abstractions, but that's basically all there is to it. I don't know specifically how you'd do it with QT or wxwidget but you'd create a child window of that HWND that you are given and have the abstraction do your thing for you.
As to whether or not it would be rendering things offscreen, etc, I have no idea; that would totally depend on the window system. There is no reason that I know of that you would need to do that, and most things just draw directly to the HWND, but there are a zillion different ways you could do it. It looks to me like what you really need is to understand how drawing in Windows actually works.
I hope that helps