> On 24 Feb 2026, at 21:23, Scott Bloom <[email protected]> wrote: > > Just an FYI, I am going to file a bug, so I did create a simple demo > Its available at > https://github.com/towel42-com/SpinBoxPosBug > Scott
Hi Scott, Your code makes the assumption that the layout of the dialog has calculated the positions and moved all widgets by the time your zero-timer fires. There is no guarantee for that. The layout is activated as part of making the dialog visible, resulting also in the dialog’s own size to be calculated. At that point, the widgets that are managed by the layout are moved. A reimplementation of showEvent() for your dialog might be the right time for you to check the widget geometries. Although if you know the kind of layout you have, then it might ultimately be better use that layout’s structured information (like QFormLayout::itemAt) to determine the relative order of the widgets inside. As for internal widgets: in addition to checking for internal naming, QWidget::focusProxy might be useful for telling you which widgets to ignore. Spin boxes act as the focus proxy for their internal line edits, so that clicking into the line edit gives focus to the spin box widget (and the spin box then forwards key events to the edit widget). So widgets that have a focus proxy can probably be ignored from your tab order process, as Qt should take care of that implicitly. Volker > From: Interest <[email protected]> On Behalf Of Scott Bloom > Sent: Tuesday, February 24, 2026 11:52 > To: Axel Spoerl <[email protected]>; [email protected] > Subject: Re: [Interest] QAbstrctSpinBox position issues > Thanks for the reply. > This doesn’t appear to be a window manager issue at all. The reason I say > this, first its on windows, however second the numbers are consistently wrong > in the same way. > While I agree, when it’s a designer based widget, fixing it correctly in the > ui file is utopic 😊 it doesn’t help the case when it’s a code based widget or > hybrid case. > Meaning, when I explicitly instantiate the input widgets not using C++. It > becomes especially difficult if dealing with a multi-language system where > some of the languages supported are Right to Left, forcing you to lay things > out differently. > I cant remove the qt_* widgets because at least with QDateEdit it has the > correct position sometimes. > The code I have works really well, Ive been happy with the results. I have > found a couple caveats, such as it has to be called during the initial > showEvent (so all positions are correct), but otherwise its easy to use and > simple > Take a look at > https://github.com/towel42-com/T42-Utils/blob/trunk/AutoTabStop.cpp > Scott > From: Interest <[email protected]> On Behalf Of Axel Spoerl > via Interest > Sent: Tuesday, February 24, 2026 09:58 > To: [email protected] > Subject: Re: [Interest] QAbstrctSpinBox position issues > Hi Scott, > Thanks for reaching out! > Flaky positions at application startup sounds like a Linux windowmanager, > applying decorations which asynchronously change the (size and) position of > the widget. > Windows and macOS are not affected, because of their synchronous nature. > The fact that the expected position flips between the spin box and it's > internal line edit, seems rather random. > The "fix all that were forgotten" function is a band aid. It sounds scary to > me, to put band aid over band aid, by e.g. excluding "qt_*" object names or > processing events on Linux a resize / move event is consumed. > My personal recommendation is to set the correct tab order where it belongs, > or construct the widgets in the right sequence, even if that's a bit more > work in the first place. > It's super satisfying to fix an issue by eliminating the root cause 🙂 > Cheers > Axel > From: Interest <[email protected]> on behalf of Scott Bloom > <[email protected]> > Sent: Tuesday, 24 February 2026 18:13 > To: [email protected] <[email protected]> > Subject: [Interest] QAbstrctSpinBox position issues > Using Qt 6.8, I have a dialog that “others” (read customer spec) has been > changing a ton. Ive missed a couple of “set the tab order correctly” > when the layout was changed. So I wrote a simple function to automate the > tab order > Essentially, it finds all the children of the widget, sorts by y position > then x position, then sets the tab order appropriately. > Ive hit a snag, that makes no sense. > For QAbstractSpinBox derived classes (QDateEdit in particular, but it > appears to be for all spin box classes) there are two positions. > > First is the pos reported QAbstractSpinBox::pos, and then there is a hidden > internal QLineEdit called “qt_spin_box_lineedit” which has a totally > different position reported. > The issue is sometimes the Spin Box’s position is correct, other times the > line edit’s is. > > I realize this is an internal widget, so there is likely zero public > documentation. But looking through the code, I can not find any rhyme or > reason why the locations are so different. > The work around, is beyond a hack. I wound up forcing the widget to require > each input to have a buddy label. This allows me to determine the Y > location (note the X is fine) by > • Checking if it has a buddy label, if so use its Y > • Checking if the widget has an internal widget, if so use its Y > • Finally use the actual Y position of the widget > Any thoughts on this? I realize I’m missing a sample, I can create one and > will if I wind up filing a bug on this, for now Im just wondering if anyone > has seen this before and has any thoughts. > Scott > Confidential > _______________________________________________ > Interest mailing list > [email protected] > https://lists.qt-project.org/listinfo/interest _______________________________________________ Interest mailing list [email protected] https://lists.qt-project.org/listinfo/interest
