@jdent said in what determines the order of the pushbuttons in a dialog?: QDialogButtonBox* buttonBox = new QDialogButtonBox; buttonBox->addButton(submitButton, QDialogButtonBox::AcceptRole); buttonBox->addButton(revertButton, QDialogButtonBox::ResetRole); buttonBox->addButton(closeButton, QDialogButtonBox::RejectRole); The thing is, these roles make life easier, because they automatically accept or reject your dialog when being clicked. But like @JonB said, nobody forces you to use a QDialogButtonBox in your dialog. It's nice to have, but if you don't like the OS default order (on some OS "OK" is left and "Cancel" right and on some it's reversed), you can put them in a regular layout and manually handle the accept() / reject() states.

@SGaist I finally solved the issue like this: submitButton->setAutoDefault(false); revertButton->setAutoDefault(false); closeButton->setDefault(true); Thank you all!!

Hi, The system style are free to ignore hints in order to stay coherent with the OS guide lines so you are likely hitting that. One possible way is to create a QProxyStyle.

Hi and welcome to devnet, You can mark your thread as solved either using the "Topic Tools" button or the three dotted menu beside the answer your deem correct :-) The title prefix was needed in a previous version of the forum.

@suslucoder said in Close the widget when push the button: want to close the widget when i clicked on Ok button. What widget (do you want to close)?

@JonB Thank you for interactions. Would you please show me an exact code of for example a PushButton and where to implement it. I am advanced python coder, I just need to see exact steps. Thank you very much.

Hi One reason can be the touch setup -- Can you please explain a little more on this? Well since it only happens sometimes, i guess its not that. I have seen something like it when touch was setup for gestures and you kinda moved the finger when you "clicked" it would then start the gesture and sort of eat the click. Could also be a bug in Qt4.8 that the later fixed with Grabmouse -- Is there any defect ID that you remember? That will add more waitage for the understanding. Sorry nope. it was a duck. It was due to calling a message box that would run event loop and button would not redraw before after. One of the other thought that I have is, if this is really a UI issue or this is being a side effect due to any other -problems such as CPU load, Memory full, etc. Do you think it is possible? Yes that is really possible if the target is low powered board and it's low on say ram then the same task might suddenly take much longer and the button will appear down. Have you tested with a button that does nothing and see if that can get stuck?