<?xml version="1.0" encoding="UTF-8"?><rss xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:atom="http://www.w3.org/2005/Atom" version="2.0"><channel><title><![CDATA[QLineEdit in modal QDialog: cannot enter text.]]></title><description><![CDATA[<p dir="auto">Using Qt 5.12.0, we have a modal <code>QDialog</code> window with three <code>QLineEdit</code>s.  Right<br />
after the modal dialog is shown, it is not possible to enter text in the<br />
<code>QLineEdit</code>s.  We also have code to bring up a virtual keyboard when<br />
right-clicking the line edit.  It is not a virtual keyboard as described in<br />
<a href="http://doc.qt.io/qt-5/qtvirtualkeyboard-index.html" target="_blank" rel="noopener noreferrer nofollow ugc">http://doc.qt.io/qt-5/qtvirtualkeyboard-index.html</a>, but rather a custom widget<br />
derived from <code>QWidget</code>.  If we bring up the virtual keyboard widget and then<br />
close it again, we <em>can</em> enter text in the <code>QLineEdit</code>.  So the opening and<br />
closing of the virtual keyboard widget seems to magically 'fix' the state of<br />
the line edit so that we can enter text.</p>
<p dir="auto">We observed a difference in behavior between the 'can enter text' and 'cannot<br />
enter text' situation. That difference occurs in the Qt 5.12.0 source file<br />
<code>qguiapplication.cpp</code> in the function</p>
<pre><code>void QGuiApplicationPrivate::processKeyEvent(QWindowSystemInterfacePrivate::KeyEvent *e)
{
    ....

    // only deliver key events when we have a window, and no modal window is blocking this window

    if (window &amp;&amp; !window-&gt;d_func()-&gt;blockedByModalWindow)
        QGuiApplication::sendSpontaneousEvent(window, &amp;ev);

    ....
}
</code></pre>
<p dir="auto">In the bad case (where the user <em>can not</em> enter text) we noticed that<br />
<code>window-&gt;d_func()-&gt;blockedByModalWindow</code> is <em>true</em> so that<br />
<code>QGuiApplication::sendSpontaneousEvent(window, &amp;ev)</code> <em>is not</em> called.</p>
<p dir="auto">In the good case (where the user <em>can</em> enter text) we noticed that<br />
<code>window-&gt;d_func()-&gt;blockedByModalWindow</code> is <em>false</em> so that<br />
<code>QGuiApplication::sendSpontaneousEvent(window, &amp;ev)</code> <em>is</em> called.</p>
<p dir="auto">I've found two Stackoverflow posts related to a similar problem, but for an older version of Qt:</p>
<p dir="auto"><a href="https://stackoverflow.com/questions/2180070/qdialog-doesnt-accept-text-input-if-modal" target="_blank" rel="noopener noreferrer nofollow ugc">https://stackoverflow.com/questions/2180070/qdialog-doesnt-accept-text-input-if-modal</a> (Qt 4.6 on Windows)<br />
<a href="https://stackoverflow.com/questions/7136760/qt-qdialog-issue-qlineedit-will-not-take-input" target="_blank" rel="noopener noreferrer nofollow ugc">https://stackoverflow.com/questions/7136760/qt-qdialog-issue-qlineedit-will-not-take-input</a> (Qt 4.7.3)</p>
<p dir="auto">My questions are:</p>
<ol>
<li>
<p dir="auto">Does anyone know if the behavior I am describing is related to a bug in Qt 5.12.0?</p>
</li>
<li>
<p dir="auto">Since <code>window-&gt;d_func()-&gt;blockedByModalWindow</code> is true in the 'cannot enter<br />
text' case, we <em>think</em> that the <code>QDialog</code> with the <code>QLineEdit</code> <em>is</em> blocked by<br />
<em>some</em> other modal window, but we cannot figure out which one.  What could be a<br />
possible strategy to find out what other modal window is blocking our <code>QDialog</code><br />
and line edit?</p>
</li>
</ol>
]]></description><link>https://forum.qt.io/topic/98540/qlineedit-in-modal-qdialog-cannot-enter-text</link><generator>RSS for Node</generator><lastBuildDate>Thu, 09 Apr 2026 15:00:21 GMT</lastBuildDate><atom:link href="https://forum.qt.io/topic/98540.rss" rel="self" type="application/rss+xml"/><pubDate>Tue, 15 Jan 2019 09:20:49 GMT</pubDate><ttl>60</ttl><item><title><![CDATA[Reply to QLineEdit in modal QDialog: cannot enter text. on Tue, 15 Jan 2019 10:43:53 GMT]]></title><description><![CDATA[<p dir="auto"><a class="plugin-mentions-user plugin-mentions-a" href="/user/bart_vandewoestyne">@<bdi>Bart_Vandewoestyne</bdi></a> said in <a href="/post/504815">QLineEdit in modal QDialog: cannot enter text.</a>:</p>
<blockquote>
<p dir="auto">So apparently, somewhere between Qt 4.8.7 and Qt 5.11.3 there is a change in behavior for the QWidget::grabKeyboard() method in combination with modality</p>
</blockquote>
<p dir="auto"><code>grabKeyboard</code> is the ultimate <em>"modality"</em> and is very invasive. If you're using it (regularly) it <em><strong>probably</strong></em> means you are doing something you shouldn't be.</p>
<blockquote>
<p dir="auto">(or we were doing something wrong and were just lucky in 4.8.7)?</p>
</blockquote>
<p dir="auto">It is possible. No way to tell beside boiling it down to an MRE which can be dissected.</p>
]]></description><link>https://forum.qt.io/post/504816</link><guid isPermaLink="true">https://forum.qt.io/post/504816</guid><dc:creator><![CDATA[kshegunov]]></dc:creator><pubDate>Tue, 15 Jan 2019 10:43:53 GMT</pubDate></item><item><title><![CDATA[Reply to QLineEdit in modal QDialog: cannot enter text. on Tue, 15 Jan 2019 10:37:50 GMT]]></title><description><![CDATA[<p dir="auto">We were able to track down the problem.  The person who solved the issue used the following commit message:</p>
<pre><code>This seems to be a conflict between grabKeyboard() and showModal(). Previously we did widget-&gt;grabKeyboard() before moving
the widget to a new (modal) QDialog. This made the keyevents go to the wrong window in Qt 5. By moving widget-&gt;grabKeyboard() 
after adding the widget to the modal QDialog, everything seems to be OK.
</code></pre>
<p dir="auto">Before, we were using Qt 4.8.7 and this problem did not occur.  It was only until after our switch to Qt 5.11.3 (and later 5.12.0) that this problem occurred.  So apparently, somewhere between Qt 4.8.7 and Qt 5.11.3 there is a change in behavior for the <code>QWidget::grabKeyboard()</code> method in combination with modality (or we were doing something wrong and were just lucky in 4.8.7)?</p>
]]></description><link>https://forum.qt.io/post/504815</link><guid isPermaLink="true">https://forum.qt.io/post/504815</guid><dc:creator><![CDATA[Bart_Vandewoestyne]]></dc:creator><pubDate>Tue, 15 Jan 2019 10:37:50 GMT</pubDate></item><item><title><![CDATA[Reply to QLineEdit in modal QDialog: cannot enter text. on Tue, 15 Jan 2019 10:30:11 GMT]]></title><description><![CDATA[<p dir="auto">Two things captured my interest:</p>
<ol>
<li>The flags in the first case:</li>
</ol>
<pre><code>windowFlags: {i=-2013204479 }
</code></pre>
<p dir="auto">Is very suspicious, as the high-order bit is set only for a very specific flags. Not to mention that value sets a whole lot of bits that I don't believe should be set.</p>
<ol start="2">
<li>The modality:<br />
First case:</li>
</ol>
<pre><code>modality: NonModal (0)
</code></pre>
<p dir="auto">Second case:</p>
<pre><code>modality: ApplicationModal (2)
</code></pre>
<p dir="auto">Ideas:</p>
<ol>
<li>Check if the object is correct in the first case, and if there's some flag manipulation done on it, it may be wrong.</li>
<li>Check why the discrepancy between case 1 and 2 between the modality. It suggests that the focus was captured by another widget/window in the first case (as you suspected).</li>
</ol>
]]></description><link>https://forum.qt.io/post/504812</link><guid isPermaLink="true">https://forum.qt.io/post/504812</guid><dc:creator><![CDATA[kshegunov]]></dc:creator><pubDate>Tue, 15 Jan 2019 10:30:11 GMT</pubDate></item><item><title><![CDATA[Reply to QLineEdit in modal QDialog: cannot enter text. on Tue, 15 Jan 2019 10:01:16 GMT]]></title><description><![CDATA[<p dir="auto">I was not able to trim this down to a complete minimal example yet (other priorities and the code is quite 'complicated'), but while debugging, we found out that our conclusion about 'the <code>QDialog</code> being blocked by a modal window' might be incorrect.  When hitting the breakpoint mentioned in my first post, the function <code>window-&gt;d_func()</code> seems to return our application window in the case where the user cannot enter text (note that <code>blockedByModalWindow</code> is <code>true</code>):</p>
<pre><code>window-&gt;d_func()
0x083bfd20 {...}
    [QWidgetWindowPrivate]: {...}
    QObjectPrivate: {extraData=0x082a9448 {userData={ size = 0 } propertyNames={ size = 0 } propertyValues={ size = 0 } ...} ...}
    surfaceType: RasterGLSurface (2)
    windowFlags: {i=-2013204479 }
    parentWindow: 0x00000000 &lt;NULL&gt;
    platformWindow: 0x02313ad0 {m_data={flags={i=134279169 } geometry={ x = 0, y = 0, width = 1920, height = 1080 } fullFrameMargins=...} ...}
    visible: true
    visibilityOnDestroy: false
    exposed: true
    requestedFormat: {d=0x023b0998 {ref={...} opts={i=0 } redBufferSize=-1 ...} }
    windowTitle: Our Super Duper Cool Application
    windowIcon: {d=0x02344598 {engine=0x0236bdb8 {pixmaps={ size = 1 } } ref={...} serialNum=1 ...} }
    geometry: { x = 0, y = 0, width = 1920, height = 1080 }
    windowState: {i=4 }
    visibility: FullScreen (5)
    resizeEventPending: false
    receivedExpose: true
    positionPolicy: WindowFrameExclusive (1)
    positionAutomatic: true
    contentOrientation: PrimaryOrientation (0)
    opacity: 1.0000000000000000
    mask: {d=0x02e244f4 {Qt5Guid.dll!QRegion::QRegionData QRegion::shared_empty} {ref={atomic={_q_value=-1 } } ...} }
    minimumSize: { width = 1023, height = 841 }
    maximumSize: { width = 16777215, height = 16777215 }
    baseSize: { width = 0, height = 0 }
    sizeIncrement: { width = 0, height = 0 }
    modality: NonModal (0)
    blockedByModalWindow: true
    updateRequestPending: false
    transientParent: guarded pointer to subclass of QObject of type "QWindow"
    topLevelScreen: guarded pointer to subclass of QObject of type "QScreen"
    cursor: {d=0x023129c8 {ref={...} cshape=ArrowCursor (0) bm=0x00000000 &lt;NULL&gt; ...} }
    hasCursor: true
    compositing: false
    lastComposeTime: {t1=-9223372036854775808 t2=-9223372036854775808 }
</code></pre>
<p dir="auto">while in the case where the user <em>can</em> enter text, we have our dialog window when we hit the mentioned breakpoint (note that <code>blockedByModalWindow</code>) is <code>false</code>:</p>
<pre><code>window-&gt;d_func()
0x0899a4b8 {...}
    [QWidgetWindowPrivate]: {...}
    QObjectPrivate: {extraData=0x0885a168 {userData={ size = 0 } propertyNames={ size = 0 } propertyValues={ size = 0 } ...} ...}
    surfaceType: RasterGLSurface (2)
    windowFlags: {i=2051 }
    parentWindow: 0x00000000 &lt;NULL&gt;
    platformWindow: 0x08916888 {m_data={flags={i=2051 } geometry={ x = 785, y = 400, width = 350, height = 280 } fullFrameMargins=...} ...}
    visible: true
    visibilityOnDestroy: false
    exposed: true
    requestedFormat: {d=0x0237a348 {ref={...} opts={i=0 } redBufferSize=-1 ...} }
    windowIcon: {d=0x02344598 {engine=0x0236bdb8 {pixmaps={ size = 1 } } ref={...} serialNum=1 ...} }
    geometry: { x = 785, y = 400, width = 350, height = 280 }
    windowState: {i=0 }
    visibility: Windowed (2)
    resizeEventPending: false
    receivedExpose: true
    positionPolicy: WindowFrameInclusive (0)
    positionAutomatic: false
    contentOrientation: PrimaryOrientation (0)
    opacity: 1.0000000000000000
    mask: {d=0x02e244f4 {Qt5Guid.dll!QRegion::QRegionData QRegion::shared_empty} {ref={atomic={_q_value=-1 } } ...} }
    minimumSize: { width = 350, height = 280 }
    maximumSize: { width = 16777215, height = 16777215 }
    baseSize: { width = 0, height = 0 }
    sizeIncrement: { width = 0, height = 0 }
    modality: ApplicationModal (2)
    blockedByModalWindow: false
    updateRequestPending: false
    transientParent: guarded pointer to subclass of QObject of type "QWindow"
    topLevelScreen: guarded pointer to subclass of QObject of type "QScreen"
    cursor: {d=0x02312568 {ref={...} cshape=IBeamCursor (4) bm=0x00000000 &lt;NULL&gt; ...} }
    hasCursor: true
    compositing: false
    lastComposeTime: {t1=-9223372036854775808 t2=-9223372036854775808 }
</code></pre>
<p dir="auto">For now, this is all I can say.  I'm still in debugging modus :-)  Any suggestions welcome!</p>
]]></description><link>https://forum.qt.io/post/504807</link><guid isPermaLink="true">https://forum.qt.io/post/504807</guid><dc:creator><![CDATA[Bart_Vandewoestyne]]></dc:creator><pubDate>Tue, 15 Jan 2019 10:01:16 GMT</pubDate></item><item><title><![CDATA[Reply to QLineEdit in modal QDialog: cannot enter text. on Tue, 15 Jan 2019 09:31:18 GMT]]></title><description><![CDATA[<p dir="auto">Can you post <a href="https://stackoverflow.com/help/mcve" target="_blank" rel="noopener noreferrer nofollow ugc">minimal complete example</a>?</p>
<p dir="auto">My gut feeling is that you parented the linedits wrong but with no code is just guessing.</p>
]]></description><link>https://forum.qt.io/post/504793</link><guid isPermaLink="true">https://forum.qt.io/post/504793</guid><dc:creator><![CDATA[VRonin]]></dc:creator><pubDate>Tue, 15 Jan 2019 09:31:18 GMT</pubDate></item></channel></rss>