I think you might have meant "good" rather than "god" ;-)
I am very pleased this approach has worked for you. It is potentially useful for me to know for my own work one day. Had I realized you had not tried the "delay" principle earlier, we would have got there quicker.
The actual implementation of the delay loop is "naughty". It will mean that your application is "running busily" (i.e. using CPU time, potentially blocking other applications) for most of 1 second. If an expert here looks at it, please don't shout at me! Like I said, I got it from elsewhere as "quick & dirty". For your purposes it's probably fine, and we achieved it without you having to do slots & signals which you were not keen on learning at this stage.
If you feel like you want to improve/experiment, in the same stackoverflow thread have a look at https://stackoverflow.com/a/3756341/489865, leveraging QWaitCondition, whose description sounds like it should have the same effect without the "busy blocking":
Actually I did try setting QTabWidget setAutoFillBackground(True) previously, but it didn't work.
Now I tried set VGroupBox setAutoFillBackground(True), then the color changed to light grey which is the exact default color I need.
It would be nice to say what self and event are. I'm guessing a QGraphicsItem and a parameter of QGraphicsSceneMouseEvent? Is that right?
If so then event.pos() and event.scenePos() are not exchangeable. The first one is cursor position in item's coordinates and the second one cursor position in scene coordinates. They are the same only when item is placed at (0,0). If item is moved they will differ. It's important to note that these values are what they were at the time the event took place, which might be different from the "current" values for item (this is a good thing). For example if you move your mouse fast and there are a lot of events generated the cursor position in these events will be a little behind the actual current position of the cursor before they "catch up".
As for self.scenePos() - this is the position of the item in the scene. This is the point relative to which the event.pos() is calculated. It is not necessary the top left of the bounding rect. It can be placed anywhere using 'setTransformOriginPoint()'. It is often set to the center of the item. For example if you have a bunch of draggable circles a center is probably more convenient than a top left corner. For vertical bars on a chart the origin might be placed at the middle bottom of a bar etc.
No, I didn't set these two flags ItemClipsToShape, ItemClipsChildrenToShape.
Then I tried setting only one flag ItemClipsToShape, and both of ItemClipsToShape, ItemClipsChildrenToShape. For each, it still check if the point is in the boundingrect() firstly, and then check the shape() which means if point is not in boundingrect(), it wouldn't bother to check shape().
So now my solution is still enlarging the boundingrect() area.
@joeQ As it turns out, I just tried the opposite. I had one newed Message Box for everything. In the place that had the funny location, I made a separate newed Message Box and it ended up in the correct place - the middle of its parent.
OK. I found it. I was being dumb! I have two flavors of Progress Dialogs. One is inside an App, and the other is standalone, meant to be called form a script. I was looking at the one in the App when I should have been looking at the other one. The standalone one doesn't have have a cancel slot.
difference between exec() and show(),
Only QDialog have exec() Qwidgets have show.
When you call show on a Dialog, it becomes visible but do not
wait for input.
MyDialog *dia=new MyDialog(this);
int a=0; // this code is run the moment dialog is shown on screen,
int a=0; // this code is run only after dialog is dismissed.
The version of dialog where u call show() could be called floating so when user click ok
it should emit signal that something should happen. ( to maiwindow )
The exec() version will report back the result ok/cancel/closed at once.
learn when to use QObject, QWidget, QFrame
QWidget is often used if making own widget. QFrame is used if you just need something to draw
a frame. If you use Designer you can check out the Widgets that are available.
QDialog is useful for any type of windows that pop ups up or open via a menu.
I have to set anything inside Register.
Yes, Register should be able to give the data back.
the widgets inside are private so you need a function to return the data.
You might also need to call http://doc.qt.io/qt-5/qdialog.html#accept
in your Register buttons clicked slot.
What do you expect to be printed exactly? The data is binary so any of the elements that can't be displayed will be printed as gibberish ... 0x01, 0x00 are non-printable characters, so you'd see (depending on the platform) squares or other strange symbols, this doesn't necessarily mean the data is corrupted, only that it's interpreted in a erroneous way.
Let me tone down this discussion by saying that the original reason for my question has disappeared. I misunderstood how QPrinter worked. I thought I would need the string versions of the QPrintDialog enums to pass on to lp. Turns out QPrinter does what I need to do automatically and I don't need to call lp. Thanks for the lively discussion though.