<div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr">Il giorno lun 18 feb 2019 alle ore 05:31 John F Sturtz <<a href="mailto:john@sturtz.org">john@sturtz.org</a>> ha scritto:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div id="gmail-m_1375032271662792423__MailbirdStyleContent" style="font-size:12pt;font-family:Candara;color:rgb(0,0,0)"><span style="color:rgb(54,96,146)">
Wow! Thank you so much for all this information. In spite of the time I have spent with PyQt, it is clear I still have much to learn. :-/</span></div></blockquote><div><br></div><div>You'll never end to learn ;-)</div><div>I still learn things from day to day (also by replying to this mailing list, as in this case).<br>While I'm still "stuck" with Python 2.7 and PyQt4 (which are <i>very</i> old) for my most important project, I realize that there are dozens of things I still do not know yet, even with products that old. And that's good :-)</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div id="gmail-m_1375032271662792423__MailbirdStyleContent" style="font-size:12pt;font-family:Candara;color:rgb(0,0,0)"><blockquote class="gmail-m_1375032271662792423history_container" type="cite" style="border-left-style:solid;border-width:1px;margin-top:20px;margin-left:0px;padding-left:10px;min-width:500px"><div style="font-family:Arial,Helvetica,sans-serif"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div class="gmail_quote"><div><span style="font-size:12pt">A much more "elegant" way to do so would be to request the actual view from the parent argument of createEditor(); keep in mind, though, that the parent of the editor is the viewport of the view (since an item view is a QAbstractScrollArea and its contents are in an embedded "scrollable" QWidget), so the reference to the view is the parent() of the parent argument of createEditor() method, actually.</span><br></div></div></div></div></div></div></div></div></div></div></div></div></div></div></blockquote><div><span style="font-size:12pt;font-family:Candara;color:rgb(0,0,0)"><b><span style="color:rgb(59,89,152)"></span></b><span style="color:rgb(59,89,152)">This is great! I was looking for a way to get a reference to the view from the delegate, but I hadn't been able to find one. Didn't look quite hard enough ...<br></span></span></div></div></blockquote><div><br></div><div>That's neat, isn't it? It took me a while to understand that, since the parent didn't seem to be a "real" and "usable" widget until I actually realized the QAbstractScrollArea inheritance of item views, and I'm still not quite sure that it's the best (and "programmatically correct") way to handle this, but I think that it's a better and more coherent way to achieve that in most cases.</div><div>Obviously, if you really know what you're doing (and, most importantly, what you might be doing in the future), setting a "virtual" parent view while init-ing the delegate is fine enough.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div id="gmail-m_1375032271662792423__MailbirdStyleContent" style="font-size:12pt;font-family:Candara"><blockquote class="gmail-m_1375032271662792423history_container" type="cite" style="color:rgb(0,0,0);border-left-style:solid;border-width:1px;margin-top:20px;margin-left:0px;padding-left:10px;min-width:500px"><div style="font-family:Arial,Helvetica,sans-serif"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div class="gmail_quote"><div><span style="font-size:12pt">PS: in your code, you've been using model.setData() inside the setEditorData() method of the itemDelegate, which not only doesn't makes not much sense, but might also result in an infinite recursion.</span><br></div></div></div></div></div></div></div></div></div></div></div></div></div></div></blockquote><div style="color:rgb(0,0,0)"><span style="color:rgb(59,89,152)">This is a fallout of the following peculiar fact: My actual intention is to use a <span style="font-family:"Courier New"">QLabel</span> as the delegate editor widget, and not a <span style="font-family:"Courier New"">QLineEdit</span>. I know that seems weird, but it gives me more precise control over the editing that occurs. (Basically, I respond to keyboard input, modify the <span style="font-family:"Courier New"">QLabel</span>'s text, then redisplay it. In the attached example, I changed the <span style="font-family:"Courier New"">QLineEdit</span> back to a <span style="font-family:"Courier New"">QLabel</span>, so you can see what I mean).</span></div></div></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div id="gmail-m_1375032271662792423__MailbirdStyleContent" style="font-size:12pt;font-family:Candara"><div style="color:rgb(0,0,0)"><span style="color:rgb(59,89,152)"></span></div><div><font color="#3b5998">[...]</font><span style="font-family:Arial,Helvetica,sans-serif;font-size:small"> </span></div></div></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div id="gmail-m_1375032271662792423__MailbirdStyleContent" style="font-size:12pt;font-family:Candara"><div style="color:rgb(0,0,0)"><span style="color:rgb(59,89,152)">There is one thing in the current version that still puzzles me: In the most recent round of messing around, I decided to subclass <span style="font-family:"Courier New"">QLabel</span>, and then use an object of the subclass as the editor widget rather than an actual <span style="font-family:"Courier New"">QLabel</span>. And I decided to move keypress handling from <span style="font-family:"Courier New"">eventFilter()</span> in the delegate to <span style="font-family:"Courier New"">keyPressEvent()</span> in the editor widget subclass. In the process, it seemed to change the way Tab is handled.</span><span style="font-family:Arial,Helvetica,sans-serif;font-size:small;color:rgb(34,34,34)"> </span></div></div></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div id="gmail-m_1375032271662792423__MailbirdStyleContent" style="font-size:12pt;font-family:Candara"><div style="color:rgb(0,0,0)"><span style="color:rgb(59,89,152)">[...]</span><span style="font-family:Arial,Helvetica,sans-serif;font-size:small;color:rgb(34,34,34)"> </span></div></div></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div id="gmail-m_1375032271662792423__MailbirdStyleContent" style="font-size:12pt;font-family:Candara"><div style="color:rgb(0,0,0)"><span style="color:rgb(59,89,152)">The latter is the default behavior for the Tab character, I believe. But the former is actually what I want. So it works the way I'd wish when I handle keyboard input in the delegate. But I'm not doing anything with Tab character in either case, so it seems strange to me that in one case I'm getting one behavior, and in the other case another.</span></div></div></blockquote><div><br></div><div>I'm not quite sure I'm following you on that.</div><div>I think I can understand your "precise control" needs, but if you can better explain what your needs are, we might help with that.</div><div>Using a QLabel for editing is not suggested, not only because it's not its purpose, but also because it doesn't provide sufficient editing cababilities and aidings, from both programming and UX perspectives (and I'm usually mostly focused on the latter).<br>Let me explain on that.</div><div>A label doesn't show the editing cursor (you might object that for simple editings it doesn't matter that much, but <i>knowing</i> where you're typing is a huge feedback) and it doesn't provide any selection nor clipboard implementation. From the user point of view that's not good, as its usage is not intuitive: while the user can "learn" how it works from its behavior, it's usage doesn't justify the change of behavior between similar and common [table/editing] user interfaces.<br>From a GUI programming perspective, it's also a problem whenever "common" keyboard shortcuts come in place. If I type a valid value in the editing cell and then use any keyboard navigation shortcut (arrows, page up/down, home/end, and further modifier combinations) I'd expect to "move" the editing cursor, while in you implementation it results in submitting the value and changing focus to another cell in the view (since the value is considered valid), according to the QKeySequence class implementation of QKeyEvents of an item view. So, you'll need to catch *all* those cases in the eventFilter() according to those listed in <a href="https://doc.qt.io/archives/qt-4.8/qabstractitemview.html#details">https://doc.qt.io/archives/qt-4.8/qabstractitemview.html#details</a> , including possible multiple cell selection scenarios, since you're returning False to all "unrecognized" cases of keyboard events - thus letting the parent object (the item view, its container layout/widget, etc) handle those events.</div><div>That said, it might be better to keep the default QLineEdit editor. You can then set your custom QValidator to the editor in the createEditor() or even implement your own editor. Since it seems you're requiring numeric values (as it looks from the regex you use in the validate() method) you can even return a custom inherited QSpinBox, and implement its own validate(), fixup() and/or textFromValue() methods according to your needs. I know it might look a bit more complicated to program with, but you'll eventually realize that it's a better solution once you understand how they behave and how all this can actually help both you and your users.</div><div><br></div><div>Finally, if you are really aware about those issues, and you really want to "escape" tab keypresses only, just add an <font face="monospace, monospace">elif key == QtCore.Qt.Key_Tab </font>statement to your eventFiler() and check for the QtCore.Qt.ShiftModifier.</div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div id="gmail-m_1375032271662792423__MailbirdStyleContent" style="font-size:12pt;font-family:Candara"><div style="color:rgb(0,0,0)"><span style="color:rgb(59,89,152);font-size:12pt">In any event, I think I'm making progress. Thanks again for the help! I really appreciate it.</span></div></div></blockquote><div><br></div><div>Glad to be of any help :-)</div><div><br></div><div>Cheers,</div><div>Maurizio</div><div><br></div></div>-- <br><div dir="ltr" class="gmail_signature">È difficile avere una convinzione precisa quando si parla delle ragioni del cuore. - "Sostiene Pereira", Antonio Tabucchi<br><a href="http://www.jidesk.net" target="_blank">http://www.jidesk.net</a></div></div></div></div></div></div>