I am not sure what the state of click is with the new version 0.3.0 but even with fastclick. On click event handlers are really slow to respond. Sometimes the first few clicks are just ignored.
Fastclick seems to ignore taps that the browser perceives to be a touchmove. See pull request for the needed changes for this to work https://github.com/Famous/famous/pull/421
Related
when
:p1_radio_button_1
:p1_radio_button_2
:p1_radio_button_3
change,
dynamic actions fired to set values on
:p1_score_1
:p1_score_2
:p1_score_3
with simple math such as (:p1_lov_1's return value) * (a constant from global page) /100
and these changes on :p1_score_x fires another DA to do some other simple calculations.
eventually I am expecting a weighted_score to be calculated.
**
mechanically, it works. but when I click radio buttons a couple of times one after another, calculation goes crazy.
I believe my approach is wrong. What would you suggest? Should I submit the page after each radio button clicks?
Thanks in advance.
APEX version 18.x
browser Firefox
OS windows
I think chained dynamic actions are not the best idea. I changed the behaviour a little:
placed a dummyButton
hide realButton on page load
redirected dummyButton to page inline dialog saying to end user "please click calcButton"
show realButton when calcButton clicked
hide dummyButton when calcButton clicked
hide realButton & show dummyButton if anything changes on radioButtons
I wasn't sure if I should delete the post or reply it. admins; please delete if it somehow against the community rules.
thank you very much
I'm trying to use SendMessage to post mouse clicks to a background window (Chrome), which works fine, but brings the window to front after every click. Is there any way to avoid that?
Before anyone says this is a duplicate question, please make sure that the other topic actually mentions not activating the target window, because I couldn't find any.
Update: aha, hiding the window does the trick, almost. It receives simulated mouse/keyboard events as intended, and doesn't show up on screen. However, I can just barely use my own mouse to navigate around the computer, and keyboard input is completely disrupted.
So my question is, how does sending messages to a window affect other applications? Since I'm not actually simulating mouse/keyboard events, shouldn't the other windows be completely oblivious to this?
Is it possibly related to the window calling SetCapture when it receives WM_LBUTTONDOWN? And how would I avoid that, other than hooking the API call (which would be very, very ugly for such a small task)?
The default handling provided by the system (via DefWindowProc) causes windows to come to the front (when clicked on) as a response to the WM_MOUSEACTIVATE message, not WM_LBUTTONDOWN.
The fact that Chrome comes to the front in response to WM_LBUTTONDOWN suggests that it's something Chrome is specifically doing, rather than default system behaviour that you might be able to prevent in some way.
The source code to Chrome is available; I suggest you have a look at it and see if it is indeed something Chrome is doing itself. If so, the only practical way you would be able to prevent it (short of compiling your own version of Chrome) is to inject code into Chrome's process and sub-class its main window procedure.
I'm working on a credential provider for windows 7 with cpp. I want to disable textboxes and submit button while the system is working in the background. For this I tried to use the code below:
_pCredProvCredentialEvents->SetFieldInteractiveState(this,SFI_EDIT_TEXT,CPFIS_DISABLED);
At here SFI_EDIT_TEXT represents the object that I want to change it's properties and CPFIS_DISABLED shows it's should be disabled (at least i assume that is). But I didn't get any useful result. Anyone can able to help?
There are a several situations, where using SetFieldInteractiveState won't work. For example, if user have pressed "Submit" button, your's provider GetSerialization function will be called, and no GUI changes will be done by LogonUI until you return from GetSerialization. I think changes of GUI are made only between calls of your provider's functions.
P.S. I know, that question was asked long time ago, but in future, maybe, my answer can help others.
I am working on a very big and complex application for Windows written in C++ and using MFC.
I am working on this bug, where if a user presses on a balloon tooltip, it won't close, only after a timeout.
The thing is that I got the NIN_BALLOONUSERCLICK event and managed to close the tooltip, but I can't seem to catch the event raised when the user presses on the "X" button in the upper right corner.
Can anyone help me? What event should I look for? I've spent around 3 days of searching the Internet, but no one seems to know of a way.
If you can tell me how to make the "X" close button disappear, that would be okay, too!
The reason you can't find any such event is because one does not exist. It is not possible to distinguish between the balloon being closed because the user clicked somewhere on it and the balloon being dismissed because the user clicked specifically on the close ("X") button.
More information can be found in this article on Raymond Chen's blog: Why don't notification icons get a message when the user clicks the "X" button?
Basically, the event doesn't exist to keep you from doing bad things, like annoying your users. There's absolutely no reason that you should need to do something different based on how the user dismissed the balloon notification.
Making the "X" button disappear is definitely the wrong choice. Asking for that makes it sound like you're exactly the developer that the Windows Shell team was trying to protect us from. Glad someone has our back as unsuspecting users of your application. Users like to be able to dismiss things. Usability studies have repeatedly indicate that it's extremely stressful and confusing for users when there is no "Cancel" button. You need to work within the constraints of sensible, user-friendly design.
NIN_BALLOONUSERCLICK is the right choice. The tooltip will be dismissed when the user clicks on it. The documentation explains all of the various notifications that are available in greater detail.
I'm getting started with Selenium IDE and trying to test a webapp that's full of modal dialogs (window.showModalDialog).
Recording the test seems to work (except there's nothing in the log when the dialog pops up) but they don't play back properly. The script actually opens the window (triggered by a button click), but then just waits indefinitely.
Any suggestions?
From the Selenium FAQ, Selenium apparently works with some types of dialogs but not others:
I can't interact with a popup dialog.
My test stops in its tracks!
You can, but only if the dialog is an
alert or confirmation dialog. Other
special dialogs can't be dismissed by
javascript, and thus currently cannot
be interacted with. These include the
"Save File", "Remember this Password"
(Firefox), and modal (IE) dialogs.
When they appear, Selenium can only
wring its hands in despair.
To solve this issue, you may use a
workaround (if one exists); otherwise
you may have to exclude the test from
your automated corpus. For the "Save
File" dialog in Firefox, a custom
template may be specified when running
via the RC that will always cause the
file to be downloaded to a specified
location, without querying the user
(see
http://forums.openqa.org/thread.jspa?messageID=31350).
The "Remember this Password" dialog
should not appear again after you've
chosen to remember it. Currently there
is not much that can be done about IE
modal dialogs.
I seem to remember someone working around this with an AutoHotKey script that dismissed the dialog.
I have been using Selenium IDE to test jQuery modals for quite sometime now, I never faced any problem. Here are the things I do to ensure that the test executes properly on playback:
execute the script at the slowest possible speed
when the modal opens, I use the waitForElementPresent command to verify the presence of at least one of the constituent elements on the page; argument being, if one element loads properly, it is safe to assume that all the elements and hence the modal window loaded up properly.
Hope this helps. If you want further help, you can share the code with me alongwith the error in execution that IDE throws out to you.
Modal window hacked:)
http://seleniumdeal.blogspot.com/2009/01/handling-modal-window-with-selenium.html
This is how I handle pop up alert in Selenium IDE
right click on the element (in this case your pop up window) there are some command you can choose. There's also a show all available commands whiche might be a help.
You should use AssertElementPreset and I guess the best locator in this case is CSS. So you can choose AssertElementPresent.
Or
you can use two command on Selenium IDE
selectWindow | null
verifyElementPresent | css=div.content
Hope this helps!