In my application user types his password in QLineEdit.
QLineEdit works in Password echo mode.
Application must clear password from memory when it is no longer needed.
Does QLineEdit make sure that it clears all its internal memory buffers before they are freed? I cannot found such information in documentation.
If QLineEdit does not clear its content then what is the simplest way to implement such behavior? I want to reuse QLineEdit functionality as much as possible and do not want to implement my own password edit control from scratch. Is it possible?
Note that even when calling setText({}) is not completely safe - the string might get written to swap space if your application is swapped out. The only way to prevent that is to allocate the memory for the internal string of the lineEdit yourself and call mlock() on it to prevent swapping. For that you need to write your own lineEdit.
In addition, the text is quite trivial to figure out when attaching a run-time introspection tool like Gammaray to your application, as it is a normal QObject property, and stored obfuscated in RAM.
Also, by looking at the implementation of QWidgetLineControl::internalSetText (see the code), it seems like the line edit text is made available for the accessibility interface, which is accessible to everyone unless accessibility support was not compiled into Qt.
So, depending on your security level, you do need your own implementation.
I think calling
QLineEdit::setText("");
will do the job. As Qt documentation says:
Setting this property clears the selection, clears the undo/redo
history, moves the cursor to the end of the line and resets the
modified property to false.
In opposite, calling QLineEdit::clear() will clear only text, however Undo/Redo stack will still contain the previous text.
Related
I am trying to fix a bug in a Qt app which I did not write. The window changes the background color of the entire window to red and puts up some buttons, dialog boxes, etc. When the escape key is pushed, the boxes and buttons go away, leaving an empty red screen. The Cancel button does the right thing in returning to the previous window. I think I need to somehow be notified of when the escape key is pushed, and then call the same function as the cancel pushbutton does. Hopefully, I can limit the scope of this special action to when the problem window is up. I am an experienced programmer but a complete Qt newbie. This app is purely C++. To my knowledge, it does not appear to use any QML. I am still searching through the Qt online documentation, but any suggestions / examples are appreciated.
This depends a lot on your specific Qt version and setup of your application. That said, I'll take a shot at helping. In the class where you're trying to intercept the escape key press, assuming it's inheriting QObject, simply override the virtual function eventFilter. Inside your overridden instance of eventFilter, check that the QEvent type is a QEvent::KeyPress, and then check whether the key of that KeyPress is the escape key, and handle as needed.
Be sure that you pass the event out of your function, else you'll see your overridden function eat all events. If you explicitly want the event to be "eaten", simply do not return it from your function. For specifics and examples, check out documentation of QObject::eventFilter().
I am really stuck up with a task relating to Qt GraphicsView. Any help or suggestions will be highly appreciated.
In my QGraphicsView application, I have a few editable QGraphicsTextItems that I have added to the scene. I need the following functionality:
Setting validator for float so that the user does not by mistake enter a character or new line in that text item.
Emitting a signal once the text is changed by the user.
Can anyone please suggest how I can implement this in my application? I have tried real hard but I am not able to find anything suitable. If there is any alternative or workaround, I'll be grateful to know.
Thanks!
QGraphicsTextItem does not support this ability, as I'm sure you have discovered. So you have a few options:
Reimplement focusOutEvent(QFocusEvent* event) and/or keyReleaseEvent(QKeyEvent* event) to detect when you validator needs to run. A QValidator can be created as a member of your text class, and queried either when focus is lost and/or a key is pressed (the enter key to signify completion, or on every letter). Then just create a custom signal for you when deem the editing to have finished or changed.
Use a GraphicsProxyWidget to hold a 'real' QLineEdit for text entry, just set it up with a validator as you would if placing in a traditional GUI form. You will need to 'forward' the editingFinished() or textEdited(const QString& text) signal from the QLineEdit to your QGraphicsTextItem, so you don't have to provide external access to the widget.
You could also use the internal QTextDocument of the QGraphicsTextItem, this is what actually holds and formats the text (access it with document()). However it doesn't support having a QValidator installed, so you would have to create a signal-slot loop whereby when the text is changed (signalled by contentsChanged()) it's received by the QGraphicsTextItem, validated, then either updated/cleared if it fails validation (which will update the QTextDocument, and trigger this process again) or ignored if it passes.
Neither is difficult to implement; the first requires more code but will give you more control over the visual appearance of the text box.
I would like to know what the established procedure is for initializing the controls within a Qt custom dialog box. In the code I am writing, the dialog would present a QListView containing directories from an object passed (by reference) to the dialog class during construction. When the dialog is displayed, I obviously want the list to display the directories currently configured in the object.
Where should this be done though? Perhaps in the overridden showEvent() method?
Background: I used to do a lot of MFC programming back in the day, and would have done this sort of stuff in the OnCreate method, or some such, once the window object had been created.
Thankfully Qt doesn't require you to do any hooking to find the moment to create things (unless you want to). If you look over the Qt examples for dialogs, most do all the constructing in the constructor:
http://doc.qt.io/archives/qt-4.7/examples-dialogs.html
The tab dialog example--for instance--doesn't do "on-demand" initializing of tabs. Although you could wire something up via the currentChanged signal:
http://doc.qt.io/archives/qt-4.7/qtabwidget.html#currentChanged
Wizard-style dialogs have initializePage and cleanupPage methods:
http://doc.qt.io/archives/qt-4.7/qwizardpage.html#initializePage
http://doc.qt.io/archives/qt-4.7/qwizardpage.html#cleanupPage
But by and large, you can just use the constructor. I guess the main exception would be if find yourself allocating the dialog at a much earlier time from when you actually display it (via exec), and you don't want to bear the performance burden for some part of that until it's actually shown. Such cases should be rare and probably the easiest thing to do is just add your own function that you call (like finalizeCreationBeforeExec).
Is there any way I can prevent the user from hitting the return key when entering text in a QPlainTextEdit widget? That is, even though I want to give the viewing space of multiple lines, I want that the if the user hits enter, a new line should not begin.
The reason for doing this is that I am adding a GUI layer on top of an existing command-line and if the user enters data using the return key, it might complicate stuff and I had really avoid changing the command line code.
Handle the key press event and filter out any return keys.
There isn't IIRC a 'allowed chars' validator for a qtextedit.
Although you can use QValidator with a QLineEdit.
See this example
ps. If you also have to deal with pasting in text with a CR, then you need to deal with the textchanged signal as well
Just wanting to know if anybody has seen an example of a telnet/chat or other console like FLEX application where you can use the same TextArea as input/ouput area.
I've been trying to modify the app at:
http://livedocs.adobe.com/flex/3/html/17_Networking_and_communications_8.html
but so far, computer says no.
All the implementations I've seen use a combination of TextInput and TextArea.
The challenge is that we'll be using this app to telnet into some old routers and we'll need to do a fair amount of copy/pasting. Based on what I've seen, it seems that I would need to point the mouse into the TextInput in order to be able to right click and paste, which is not very sleak.....
Your thoughts,
Fran
edit Just realized that I had trimmed out what was directly pertaining to the question: I was unable to find anything that used the TextArea for input and output; see the below suggestions if custom-component suggestions are ok.
The TextArea component only fires a change event whenever a user adds input. Whenever you set the text field programmatically, a change event does not fire--you could maybe use that as a way to know what is user input and console "responses" by looking for carriage-returns (\r).
I'm unsure if you have a requirement to maintain the user's input at the bottom-most line (like a console), even after the console responds with something like auto-complete. If that's the case, then something a bit more complex would have to come into play (such as remembering where the user's input started/ended) or the requirement of a single-component console needs to be reconsidered--sleek is nice, but not always necessary.