Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 2 years ago.
Improve this question
I am attempting to make an automation for a browser game on kongregate, minequest. I've created a code that is supposed to click a series of buttons however while the mouse moves, the mouse doesn't always successfully click. No errors are given and each time I run the code different clicks fail. I have tried adding more and more time between clicks to the point that I now have 1 second wait times, repeat the clicks at least twice, etc. to try to ensure a click happens but clicks still don't always happen.
I have windows 10, mouse pointer scheme is set to none, I am using google chrome as the browser.
Edit: FYI I have made other automations that work just same with the same browser, same computer, etc. I currently have gotten this code working by having it click 10 times instead of 1 but that shouldn't be necessary and I would like to understand why this phenomenon is happening.
I had a very similar problem, and it turned out that some programs didn't register my clicks because by default, Autoit only holds down the mouse click for 10ms, which wasn't long enough for it to register on some programs.
Setting
Opt("MouseClickDownDelay",50)
fixed it, by increasing the length of each click to 50 milliseconds.
Sometimes an application might not react on "click", but on "button status". MouseClick might not have enough time between "Press" and "Release" for those applications to notice that the button is "down". (Your description ("working one time out of two to ten") supports this oppinion). To give that application a proper "Button is down", a mousedown, sleep, mouseup sequence should work.
If you don't have trouble with a mouseclick "by hand", a sleep time of 100 - 200 ms should be fine.
Related
Where would the first focus be on when a modal window opens? Some say the focus order should be sequential, so the first tab stop should be on the close button and some say, it should be on the first logically actionable element.
According to me, it should be on the first actionable item. Let's say if a modal window is opened to Search something, then the focus should be on the search edit box.
What are your thoughts? Which is better and what are the reasons?
The answer is, it depends®.
In fact it's mostly a question of good sense. You should put the focus where the user is the most likely to do his first action in the modal. Therefore:
If you are prompting for input, the most logical is to put the focus on the first required field
If you are asking a yes-no or multiple choice question, the focus should go on the most probable or recommanded answer
Exception to the previous one: if you are asking a question about whether or not to proceed on a unrecoverable action such as "are you sure to delete ?", the focus should be set to the no button eventhough the most probable answer is yes, so that the user has a last chance to cancel something triggered by misstake
If the modal dialog is just showing a message, it's logical to put the focus on the OK or close button, since it's the only possible action
Putting the focus on the close button when something else is expected is kind of weird, especially for screen reader users, who don't necessarily know what the dialog is for immediately.
I always put it on the first heading or label, so blind users can confirm where they are after clicking the link or button which opened the modal. Then focus can move to the close button as the next item in sequence - if opening the modal was a mistake (happens often when you can't see the layout or with ambiguously labelled links) this makes it easy to correct.
Jumping to the first focusable item isn't technically wrong but gives poor usability for screenreader users while only saving one click for sighted keyboard users.
Background
I'm building an application which runs in the background, and where the mouse cursor is moved programmatically into a dialog when the dialog "pops up". I have done this using QCursor.setPos
Problem
The problem I'm having is that if the mouse button is pressed down when the user is interacting with something outside the application this might lead to unwanted things happening. For example if the user is changing the volume and the mouse is moved the volume might go to max or min
Question
Is there any way (in Qt) to do a mouseup programmatically?
If I do this before changing the position of the cursor it seems to me that there is less risk of problems (though there might be other problems resulting from this approach)
First I want to make clear that my problem is not a technical question. I want to talk about usability.
In my company we have a function to check if a scale works properly. We have the button you see bellow (1) to start a function named scaleCheck(). During the scale check the weight of the scale is set to 0 and then a specified weight is put on the scale automatically and when the weight matches the number set in a config file the scale is OK. So when you click on the button, it gets the white border (2) and when the check is finished the button turns normal again (3).
This is the automatic process, but not every customer has a scale which can put automatically a weight on it. So in this case the customer has to go to the scale an put a weight on it by his own. In our application the customer can configure, if he wants the process to be manual or automatic and the button will adjust to this. So when the configuration is set on manual we have to interrupt our function an wait for the customer until he is ready. Because we don't know how many time he will need, he has to click on the button again to tell the application that the process can continue. Therefore we changed the button a bit when we are in manual mode. As you can see below the button (1) changes the image, when the customer clicks the first time on it (2), to show that the weight has to be put on the scale. When he clicks the second time the process proceeds (3).
So this is the current state. The automatic mode works how the customers imagine it to be, but in the manual mode many people have problems with it and need a lot of time the recognize that they have to click on the same button again they clicked before.
And here is my question, is there a better way to show the customers that this button should be clicked again. Are there some people who have experiences with a similar kind of functionality? Or is there a better way to do it? I'm open for every idea which comes in.
We ended up with the opinion that it is not a intuitive solution to click twice on the button. We solved it by showing the user a message after the first click on the button, and accepting that message is count as the second click. With usability in mind this i by far a better solution and the customers can handle this situation much better.
I am doing work on Qt. i am not using android. It's just a desktop application running on windows/linux.how to know which component (placed on a widget or form ) is currently focused ?
i have onscreen keyboard which appears when a QLineEdit,QTextEdit or QPlainTextEdit get focused and hide when these lost focus.But when i switch focuse from one TextEdit(or lineEdit,PlainTextEdit) to Another TextEdit(or lineEdit,PlainTextEdit) my keyboard hide and again show.I just want to stop this
If you want to stop the keyboard from flickering when the widget it's coming from and the one it's going to are similar then you could perhaps implement a timer. I imagine you have the lost focus signals going to your code that is hiding the keyboard. Instead of really hiding it, you can start a timer like
QTimer::singleShot(500, this, SLOT(really_close_keyb()));
Within that really_close_keyb() slot you could implement code to check if the widget that currently has focus should have a keyboard or not, and if it should then you don't hide it.
With this your keyboard will be up for 1/2 sec after the user focuses out of a line edit, giving enough time to focus on another one without losing the keyboard. Adjust the timing to suit.
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 11 years ago.
Improve this question
Such a simple consept, yet so many ways to interpreit it.
I'm making a program (a game, to be spesific) using an event based library (Allegro). The library doens't have a spesific event for a mouse click, but in stead has event for button down and button up. While programming the basic menus, I was struck by a problem. What do I consider a click? The button down event? The button up event? The latter, if it happen shortly after button down? If so, from which point do I take the cursor position from?
There is no dragging functionality anywhere in the program, so all options seem equaly valid to me, with the exception of the most extreme cases perhaps (dragging the cursor long ways across the screen, for example). So my question is, are there any conventions to what to consider a click?
If you experiment with buttons in various programs, you'll probably find that the button triggers when you press and then release the mouse within it.
More specifically, when you press the mouse, the button switches to a "pressed" appearance, but if you drag the mouse outside the button, the button reverts to its normal appearance, and releasing the mouse then has no effect. There is probably also another state that the button is in when you hover the mouse over it.
For a user accustomed to modern interfaces, you really need to provide all three of these states - normal, hover, and press - in order to give them the feedback they expect for a pressable item.