[Interest] QComboBox - rect of actual menu vs widget area

[Roland Hughes]

On 12/29/2018 4:00 AM, Frank Rueter wrote:
> I am trying to draw a simple busy indicator into a QCombobox while it's
> being populated with items.

Here are two thoughts which aren't direct answers but also don't involve 
the ugliness of overriding a paint method. We really shouldn't override 
paint methods. Both methods involve an animated GIF inside of a label. 
You can look at some code for this here: 
http://www.logikalsolutions.com/wordpress/information-technology/qt-and-usb-pt-2-2/

Method 1: show/hide interesting widget

Place a label with the animated GIF at the exact same spot as the combo 
box.

Hide the comboBox and show the label during your load then reverse the 
process when load is complete.

Method 2: show/hide busy indicator only

Place a label with the animated GIF in the exact spot you want the GIF 
to appear. Label will need to be without border or background unless 
perfectly sized for GIF.

Show the label and disable mouse events for ComboBox then hide the label 
when complete and re-enable mouse events on the comboBox


Toggling visible for mouse events can be a pain. It is easy to forget to 
turn them back on so I tend to use method 1. A cheat for method 2 is to 
add a label without border or background in the same size and location 
as the comboBox. Slap it over the comboBox before the label with the 
animated GIF appears. This has the effect of "hiding" the comboBox from 
the mouse when it has nothing in it.

A purist will demand using a separate UI file, creating a custom widget 
which contains the comboBox and label with animated GIF. This hides all 
of the logic for loading the comboBox and displaying the busy indicator. 
You just place the widget on some other UI file and have your program 
call loadData().

The widget then becomes responsible for loading the data and displaying 
of the busy indicator. For a very tiny application this is overkill. For 
something large this is well and good. The decision gets a bit iffier 
when the data is coming from a database because the main/parent 
application is the one keeping track of the connection name as well as 
the actual file name (for SQLite and other non-database databases). 
Custom widgets needing such things have to have methods which pass such 
things in. Done poorly this can really complicate construction.

Rule of thumb:

When one finds themselves saying "override the paint method" it is time 
to step back and contemplate where their design failed. As soon as we 
override the paint method we steal from ourselves any optimizations and 
enhancements the existing widget paint method provided under the hood. 
Microsoft conditioned a generation or so of developers to override the 
paint method for everything on their failed Windows platform. Now there 
should be little mystery as to why their license agreement includes the 
phrase:

"not for use in medical devices"



> -- 
> Roland Hughes, President
> Logikal Solutions
> (630)-205-1593  (cell)
> http://www.theminimumyouneedtoknow.com
> http://www.infiniteexposure.net
> http://www.johnsmith-book.com