UPDATE3 - SOLVED with reservations, please see my solution below; leaving it open since the cause of the problem is unclear, and I don't know how robust the solution is.
UPDATE1: here's the short short version.
Currently, after .setEditText on a QComboBox, I get this:
so the next thing you type will overwrite 'Team '.
But the desired effect is this (unhighlighted / unselected), so that the next thing you type will be appended to 'Team ' instead of overwriting it:
Thanks for any help. The rambling details are below, which is the original post:
(this is all PyQt 5.4)
UPDATE2:
Apparently python doesn't think anything is actually selected:
self.entryForm.ui.teamField.lineEdit().setText("Team ")
print("selected text:"+self.entryForm.ui.teamField.lineEdit().selectedText())
prints "selected text:" and nothing else. To make sure that's working:
self.entryForm.ui.teamField.lineEdit().setText("Team ")
self.entryForm.ui.teamField.lineEdit().setSelection(0,4)
print("selected text:"+self.entryForm.ui.teamField.lineEdit().selectedText())
prints "selected text:Team"
So that might be why many of the methods that affect selection are not working as expected (.deselect(), .setSelection(5,5), etc, and even some of the other methods give unexpected behavior, i.e. cursorForward(False,1) or cursorBackward(False,1) and such.
Original post:
This is for a radio log GUI, so keyboard interactions must be minimal and intuitive. openNewEntryForm (below) is called as a slot from a pushbutton on the main application GUI window:
self.ui.pushButton.clicked.connect(self.openNewEntryDialog)
It can also be called using a keyPressEvent in the same class:
def keyPressEvent(self,event):
if type(event)==QKeyEvent:
print("QKeyEvent:"+str(event.key()))
if event.key()==Qt.Key_T:
self.openNewEntryDialog('t')
event.accept()
else:
event.ignore()
Here's the method in question:
def openNewEntryDialog(self,key=None):
self.entryDialog=newEntryDialog()
if key=='t':
self.entryDialog.ui.to_fromField.setCurrentIndex(1)
self.entryDialog.ui.teamField.setFocus()
self.entryDialog.ui.teamField.setEditText("Team ")
if self.entryDialog.exec_():
self.newEntry(self.entryDialog.getValues()) # adds the log entry
so, the intended key press sequence is (from the main application GUI window):
a single keyboard press of 't' will open the entryForm, set the to_fromField to index 1 (which happens to be "TO"), give focus to teamField (also a QComboBox), set its text to "Team " and set itself up so that the very next keypress will appear as the text following "Team " in teamField.
So, starting from the main app GUI again, the plan is that typing 't3' should open the new entry window, set the to_fromField to "TO", and set the teamField to "Team 3", ready for a keypress of the tab key to move on to the next field in the entryForm.
The problem is that the teamField.setEditText("Team ") call leaves all of the text highlighted/selected, so that a subsequent key press of '3' would replace "Team " with "3"; I'm looking for a way to unhighlight/unselect "Team " but leave the cursor active at the right of that string, so that the subsequent key press of '3' would make the entire string "Team 3".
Ideas? Thanks in advance.
You can access the line-edit of the combo box, and then remove the selection:
self.entryDialog.ui.teamField.setEditText("Team ")
self.entryDialog.ui.teamField.lineEdit().deselect()
UPDATE:
The above code is correct, but it seems that the dialog will then clobber it when it initialises the focus handling for its child widgets after it is shown. If a dialog is opened with exec(), it will start its own event-loop, and some events (including focus events) will only be processed after it is fully shown. This is why it may appear that some changes made to child widgets before the dialog is shown are being ignored.
One way to work around this is to use a single-shot timer to ensure the changes are only attempted after the dialog is shown.
So add a method to the entry dialog class something like this:
def resetUI(self, key):
if key == 't':
self.ui.to_fromField.setCurrentIndex(1)
self.ui.teamField.setFocus()
self.ui.teamField.setEditText('Team ')
QtCore.QTimer.singleShot(0, self.ui.teamField.lineEdit().deselect)
and then use it like this:
def openNewEntryDialog(self, key=None):
self.entryDialog = newEntryDialog()
self.entryDialog.resetUI(key)
if self.entryDialog.exec_():
self.newEntry(self.entryDialog.getValues())
SOLVED with reservations, see UPDATE3 in the original post.
So, with the initial text all highlighted, tests show that it didn't actually think anything was selected. This solution was just stumbled upon by trial and error, fiddling with setting and clearing focus, selecting text and trying deselect:
def openNewEntryDialog(self,key=None):
self.entryForm=newEntryDialog()
if key=='t':
self.entryForm.ui.to_fromField.setCurrentIndex(1)
self.entryForm.ui.teamField.lineEdit().setFocus()
self.entryForm.ui.teamField.lineEdit().setText("Team ")
self.entryForm.ui.teamField.lineEdit().setSelection(5,1)
Notice there are two spaces after 'Team' and the second one is intentionally selected. Then the very next keypress will overwrite that second space; that is basically the desired behavior.
Anyway it looks like something bizarro with the selection scheme; one way to look at this is that the highlight isn't really a selection, but, if you set a valid real selection then it will override the original highlighted 'pseudo-selection'. The original highlighting behaves like a selection in that a keypress will replace everything that's highlighted, but, not like a selection in that the selection methods reveal that there is no 'selection', see UPDATE2 in the original post.
Can anyone help explain this behavior? I'd like to build some more confidence in it before accepting this coincidental answer.
Thanks
Related
I'm trying to automate a many clicking process, just to narrow it to the user input.
I encountered problems in controlClicking interface elements, which seems not to be standard Windows GUI elements.
When pointing them with WinSpy they don't appear as separate buttons, but I can point the whole child Window which is drawn in the main program window.
As on pic1, I pointed the whole window and I can find each tab/button by it's text inside and on pic2 I can inspect the ClassNN of that element and it's ID.
As far as clicking other buttons in the main menu bar of the program works, a simple:
ControlClick, ClaTab_01000000H26, WindowName
doesn't work. I think during the day, and many possibilities I tried, I could ControlClick the above button by pointing it with its ID, but that ID changes every instance. I could confirm that tomorrow if it works by ID.
Of course I tried SetControlDelay -1 and ,NN option. But don't take that for granted, I can try any of your suggestions tomorrow.
Both tabs marked with purple color, are to find in the Windows->SiblingWindows tab. I really don't want using x,yCoords (that actually work), but I need the script to be as reliable as possible.
So my questions are:
Am I missing something or you have any suggestions how to click that elements?
Is it correct, that no matter how deep the child windows get (one has buttons to open another on top of it), all the time the WinName stays the same pointing to the main program ***.exe?
Could you provide an example from the web or yours, to find an element's ID by providing the text attached to the button (pic1-red line and also pic2 in "text")?
I also cannot maximize the child window. Double clicking it works, but I can't find the appropriate ClassNN of the window to call.
Could you provide an example, how to use the Messages tab? I assume, if I find the button as on the pictures, I could send a message with controlClick and see if there's a reaction?
1.Ugh. I found the solution, which is awesome, but a little frustrating that with a bit of luck I tried another aproach that's not that logical for a newbie like me:
instead:
ControlClick, ClaTab_01000000H6, ahk_class ClaWin01000000H_2,,,, NA
it's just
ControlFocus, ClaTab_01000000H6, ahk_class ClaWin01000000H_2,,,, NA
2._Yep. One child window creates another and another and another, but winTitle stays the same. In my case:
ahk_class ClaWin01000000H_2
3._Code below returns the handle/ID of the element you specify. Change ClaTab and ClaWin to your chouice.
ControlGet, OutputVar, hwnd,, ClaTab_01000000H1, ahk_class ClaWin01000000H_2
MsgBox, %OutputVar%`
Probably to be continued.
I highly recomend to both use
WinSpy https://www.autohotkey.com/boards/viewtopic.php?t=28220
SimpleSpy https://www.the-automator.com/downloads/simple-spy/
First one has lots of useful information and the window tab provides information of hidden buttons/windows. Second one in a more clear way indicates the parent window and its class.
I originally had code that set the focus to the first widget in a dialog, in the onInit method. But there were problems with it: if I pressed TAB, indeed focus moved to next control (wxTextCtrl), which got the blue 'focus' color, but the 'focus' color/highlight was not removed from previous focus widget. So now it looked like both first and second control had focus at the same time...
When cycling manually (by pressing TAB) full circle (till last control and then wrap around to the first), suddenly all worked well. That is, when moving focus from first control to next one, the first visually lost focus (blue color was removed) as it should. From now on, only one item had the focus color/highlight.
So instead of setting focus on the first control, I tried a different approach: I set the focus to the last control in the dialog, which is always the OK button. Next, I want to emulate programmatically that a TAB is pressed and received by the dialog. So I wrote this (inside Dialog::onInit):
m_buttonOK->SetFocus();
wxKeyEvent key;
key.SetEventObject(this);
key.SetEventType(wxEVT_CHAR);
key.m_keyCode=WXK_TAB;
ProcessWindowEvent(key);
Now the focus indeed moves away from the OK button, but it does not wrap around to the first control.
Only when I manually press TAB after the dialog opened, the first item gets focus.
Question: why does this wrapping around to set focus on first widget not work with the code shown above?
First of all, your initial problem is almost certainly related to not calling event.Skip() in one of your event handlers, see the note in wxFocusEvent documentation.
Second, you can't send wx events to the native windows, they don't know anything about it. In this particular case you can use wxWindow::Navigate() to do what you want, but generally speaking what you're doing simple can't, and won't, work reliably.
I was wondering if someone can help me figure out the solution to a problem I am having with my script.
To give you all context, I am trying to simulate a mouse hover on a menu. So when you put your mouse over "New Vendor", it will expand the menu with more options to choose from (in this case just "New Care Organization"). For test purposes, I want to select "New Care Organization".
Here's the visual of the menu:
When I put my mouse over "New Vendor", this is what I want to happen:
Here's what I have right now:
Browser("MyPage").Page("MyPage").WebElement("New Vendor").Click
Browser("MyPage").Page("MyPage").WebElement("Medical Care Organization").Click
For some reason, however, when I run this, "New Vendor" does not expand and therefore "New Care Organization" is not selected. It's as if it didn't even recognize my command to expand "New Vendor" and the test fails.
I thought I was doing this right, but can anyone explain and possibly give me correct code to fix this?
Much appreciated!
Option 1:
If clicking on "Medical Care Organization" opens a new page than it must Link and not WebElement. If you are using UFT, than you can spy that object.
If object spy is showing it as Link than you can simply use like:
Browser("MyPage").Page("MyPage").Link("Medical Care Organization").Click
Option 2:
If in normal case if you'll move your mouse manually on New Vendow and if its showing you Medical Care Organization than you use "FireEvent" "OnMouseOver".
Something like:
Browser("MyPage").Page("MyPage").WebElement("New Vendor").FireEvent "OnMouseOver"
And then you can click on "Medical Care Organization" object.
First problem you could have is the html script on this page might have a different element name to -
WebElement("Medical Care Organization")
You could search the Html code for this element and try using the exact name in your code
Mouse hover and position is not commonly used with VBScript you could use Ghost mouse freeware applications along side your script.
Or you could use keyboard commands with VBScript to navigate and select through your web page such as Tab and enter.
I have recently been asked if I could make a macro in Excel VBA that will allow a user to type in two numbers and have it automatically drop to the next row. The purpose of this is so they can type in grades for a test two numbers at a time without pressing enter since they aren't great at typing.
When I first heard this he mentioned it was Visual Basic, so I figured I'd just use a TextChanging or TextChanged event in the cell range and have it work off that. However, I haven't been able to find any such event or anything resembling it in the documentation thus far. The first thing that I came across was Workbook_Change, but that only changes after you press enter which is useless to me. Someone else mentioned there is such an event, but couldn't name it directly and I haven't been able to find what they were talking about.
If anyone has any information on if such an event exists or is possible I'd love to know.
The Excel version is 2007 as far as I'm aware.
This, in my opinion, requires a non-programming solution. I absolutely sympathize - it is tough to watch people get old - but you have to draw the line somewhere - for their sake and yours. The enter key is the most basic part of a computer. You could probably write a macro that would automatically hit enter on every even(or odd depending) keystroke in excel - but you're going to run into other problems like not being able to use delete normally. And what if you do want to put a string of text in a cell(like the student's name)? Perhaps it is time to find a non-programming solution. By that I mean someone should have a candid conversation with him about how he wants to solve the problem. Personally, I would offer to type the numbers in for him, as I am accustomed to the number pad - but it is probably better to be more direct and start to discuss retirement.
See this discussion about the limitations of cell edit mode in excel:
http://www.mrexcel.com/forum/excel-questions/524860-call-macro-every-keystroke.html
If you're really heart-set on a programming solution, I would recommend some kind of keystroke logging add-in.
Good Luck.
You could use the Worksheet_SelectionChange event. It is triggered without enter, but it would be triggered a lot.
You could however also create a special user-form for typing in the data, but this might be more work than necessary.
The main problem with using my suggested event is, you will need it as trigger and trigger it yourself, when selecting the next row, so disable event handling before changing the selection.
Edit:
This is a quick solution (paste this into the vba-code of the desired worksheet):
Private Const clngColumnRightToLastGrade = 5
Private Sub Worksheet_SelectionChange(ByVal Target As Range)
If Target.Column = clngColumnRightToLastGrade Then
Application.EnableEvents = False
'offset selection, one row down, two cols to left
Target.Offset(1, -2).Select
Application.EnableEvents = True
End If
End Sub
This will set you one row down and to column C, everytime your selection changes to column E (=5).
You don't have to use a constant of course, you could specify the column to sense in the workbook, so your user might modify it easier by himself.
To make this as an optional feature, you could extend it to autogenerated code. What I have in mind is like a Ribbon-Button, which opens a setupForm to configure, and a Ribbon-Button to activate the configuration, which would place this code in the configured sheet. But this might be a bit over the top.
In Excel 2003, (may be different in Excel2007 ?!) the WorkSheet_Change event is triggered every time the value of a cell is changed wether it is by pressing enter, delete, selecting an other cell after modifying a cell or even when a vba script changes the value of a cell.
I would do something like that:
Private Sub Worksheet_Change(ByVal Target As Range)
Dim RefRange As Range
Set RefRange = Intersect(ActiveSheet.Columns("??????????"), ActiveSheet.UsedRange)
If Not Intersect(Target, RefRange) Is Nothing Then
Target.Offset(0, 1).EntireColumn.Range("A1").Select
'Target.Offset(0, 1).EntireColumn.Range("A65536").End(xlUp).Offset(1,0).Select
End If
End Sub
I have the following set of controls.
Scenario 1:
If you select one of the first 3 radio buttons and click enter, focus will jump to the Passport Number text box. If the user selects "Other", the "Other, Please Specify" textbox is enabled and, for convenience, screen focus (the cursor is moved) to that textbox.
Scenario 2:
The "specify Other" text box is hidden until the user clicks on the Other Radio button. Upon doing so, the textbox is made visible and the cursor is placed in this textbox.
Which scenario do you feel is a better approach? Perhaps you have another variation? Please state your reasoning.
I would also appreciate it if you could make a generalized statement as to when hiding is better than disabling or vice versa, but I am also interested in this particular example.
Thanks.
Afetrthought: Perhaps, in the 2nd example, the "Please Specify" text would only appear after the user has selected the 'Other' radio button.
I find that changing the UI by hiding/showing controls can be quite jarring and confusing to the user. Go with option 1 and enable the textbox when the appropriate radio button is checked.
My initial impression is that number 1 is neater.
it allows for a clear design of the GUI (there wouldnt be inexplicable empty spaces in the input screen)
it makes the colon after the `(Please Specify)" request meaningful.
The only time I advocate hiding UI elements is when it improves the UI. If it's just 'different' rather than 'measurably better', don't do it.
Users may be put off by the fact that the "other" option seems to require that you specify something, yet the UI gives no clue that you can do that.
I would consider number 2... Hiding the text box will make it easier for the majority of people to run their eye down the page (each horizontal line creates a barrier for the eye). When someone selects 'other' a text box could fade in with the words 'please specify' in the box. The form will seem to respond to the users input.