I have a really weird problem, one of the windows in my app (let's call it "Window A") is consistently placing itself (or being put) behind the window that brings it out ("Window B"). Even if I click on Window A, Window B immediately comes forward again.
There's nothing obvious in the code as to why this might be happening. I can write a windowActivated() or windowDeactivated(), but by the time they're called the information on who actually switched the windows is of course long gone.
How can I get to the point where those events are fired?
I've found what was causing the bug and thought I'd post it here in case it's of use to others. I never found an answer to my original question, and I still think it may well have shown me where the bug was coming from. It certainly was non-obvious.
It turns out that if you have a custom focus traversal policy (Container.setFocusTraversalPolicy(FocusTraversalPolicy)) and its getFirstComponent() passes back a component which is not focusable[*], then whenever the window is brought to the front either programmatically or by the user, it will be sent back one step in the z-order hierarchy.
I found the problem by good old brute force: the offending window is part of an inheritance hierarchy like so:
AbstractSuperclass
/ \
/ \
BuggyWindow NonBuggyWindow
I made a ToyWindow class to also descend from AbstractSuperclass. It didn't have the bug. I laboriously copied in code from BuggyWindow until the bug exhibited. That was in a long method which is called when the window is first displayed; by successive deletion I arrived at the offending block of code, where a number of widgets have their isEditable() and isEnabled() set to false. Since other windows have all their widgets disabled (in View mode), there was obviously more to it than that. Then I remembered the custom focus traversal policy.
I wrote a toy program with the important elements, and was able to reliably trigger the bug. I added checks for focusability to all of the methods in my custom focus traversal policy. Bug go bye-bye.
Thanks to those who responded and I do apologise for the lack of information. I didn't want to waste people's time by shoving huge amounts of code at you. It meant you didn't get what you're used to here, and that was unfortunate.
[*] I'm taking non-focusable as !(isFocusable() && isEnabled()) since I couldn't quickly get sufficient information to understand exactly when a component might be focusable but not enabled (or the other way around), and it was good enough for my purposes. (Oh, how I wish the JRE would have comments better than e.g. "isFocusable() returns whether this component can be focussed"..."isEnabled() returns whether this component is enabled" -- ##&$!!!)
Related
some one suggested this but i am not able to implement it can any one can help me by providing the desired code in kotlin..
Another solution can be to call
UsageStatsManager.queryEvents
with the start of the day as first parameter and the current time as end parameter and then filter the results to check just the
UsageEvents.Event.SCREEN_INTERACTIVE UsageEvents.Event.SCREEN_NON_INTERACTIVE
events
take the timestamp of each of them and sum all the time passed between each
SCREEN_INTERACTIVE -> SCREEN_NON_INTERACTIVE
events, this would easily show how much time the screen was interactive, so screen on and the touch enabled.
There is a possibility that you'll have a SCREEN_INTERACTIVE event that doesn't have any related SCREEN_NON_INTERACTIVE, this is when the
UsageEvents.Event.DEVICE_SHUTDOWN
event happen, luckily this event is in the same list returned by the queryEvents method
remember also to declare and make the user to allow the android.permission.PACKAGE_USAGE_STATS permission as stated here
ps. i haven't used this yet but looking at the documentation it's the right thing to use, probably the one used by the android settings pps. look also to the other events in the same package, they might be helpful to what you want to accomplish
I am using Selenium and Java to write a test. I use ExpectedConditions.elementToBeClickable to click on web elements, but sometimes they are covered by others and as you know ExpectedConditions.elementToBeClickable only checks if the element is enabled and visible, so is there any method to check if it's covered or not?
by the way I do not want to use codes like:
try{
//click on the element
}
catch(Exception e)
{//it's covered
}
I am looking for something like:
blabla.isCovered();
because sometimes for example I want to check of a whole window is covered or not.
If you don't want to use that sort of code, perhaps you should add additional logic to your checkifClickable method than just enabled and visible. Although, I am betting your real question is more along the lines of "How can I check for these conditions prohibiting me from clicking that may be not be apparent from information provided by the DOM".
This is something that makes Automation more difficult than people realize, because you must have detailed knowledge of the site. Is it an element that pops up due to logic or a condition? Then the solution is to close it. Is it a resolution of rendering issue? Then resize window. There is no real cure-all method, you have to tweak the automation logic to suit the site you are working for.
Are you not wanting to click at all and know previously?
If you specifically just don't want to use Try, then implement an assertion that a property changed after you clicked and then set a bool.
Is it normal that the default behavior for code completion when editing Java is the following?
If I import a package, after typing the first ., any key I press results in the first item in the list being selected
Sometimes while typing keywords like public and protected, NetBeans will make some wild leaps and insert private after just a p or pu are typed!
In general, it tends to make some big guesses in terms of autocompletion, guesses that are not supported by my previous input at all.
I feel like this cannot be the desired behavior for every user. Is there a way to make the code completion not autocomplete anything, or at least make it way less eager?
Edit: To be clear, I do not want to have to disable the sometimes-useful "Autopopup Window." I want the window to eagerly appear with tips and suggestions for methods, syntax, whatnot - I just don't want NetBeans to try to guess what I want, because it is wrong 90 - 100% of the time.
Which version of Netbeans are you using because that doesn't seem to be the behaviour I am seeing in 7.1.
AutoCompletion popups don't appear until I hit Ctrl+Space.
If I type "p" and then hit Ctrl + Space, the popup shows "private", "protected" and "public". I can either keep typing (and the list gets smaller as possible matches are removed) or use the cursors to select the word I want and hit Enter.
If there is only one logical option e.g. I start typing "pu" and then hit Ctrl+Space, then Netbeans inserts "public" automatically (though this can be turned off).
Code templates are a different story, I have them set to be activated using Shift+Space. As far as I know, templates don't show any popups. Anyone who likes pain can consider changing the activation key to just Space :P
I definitely share your complaints, especially re: 1. A quick google search reveals ways to turn off autocomplete:
AutoComplete drives me crazy. I’ve always hated it – I feel like it
slows my computer down and sometimes it even seems to derail me in the
middle of typing something because the window comes up and somehow
snags focus. I turn it off under Options, Editor, General (uncheck
Auto Popup Completion Window).
Item 2) sounds more like the "code template" feature rather than the auto-completion.
If that gets in your way, you have two options:
change the key that "triggers" the code-template expansion (e.g. from "Space" to "Tab"
remove all two-stroke templates (or any other abbreviation that you would rather not have)
Both can be done under "Tools -> Options -> Editor -> Code Templates"
While registering to a website, it has 2 fields. Email and email confirmation.
The thing is, people are copying what they're writing on first field and pasting on the other field.
I'd like to disable it, is it possible?
<h:inputText id="email" value="#{registerBean.email}" maxlength="60" />
One of the most important things to track in UI design (if you care about a consistent user interface) is all of the nuances which people come to expect.
If you disable the "copy" hot key sequence, then many people will feel frustration because your interface doesn't conform with the nuances that hold for the rest of the operating system. While I understand why you might want to do this, that's not going to convince people that your code isn't broken. After all "Ctrl+c" works every where else.
Once you deviate from enforcing expected UI control nuances, then you need to indicate where the nuance is permitted and where it is denied. That's the DEFINITION of an inconsistent user interface. As the user isn't going to have you there to explain the "why" when the UI does something that they don't expect, they will invariably consider it a bug. If they did have you there telling them why they couldn't do something allowed in every other part of their operating system, they will invariable consider you overzealous in enforcing something stupid which everyone else allows.
The solution is to use a better solution. Enforce what is already expected to reduce the learning curve, or select something (OpenID has been mentioned) that sidesteps the objectionable task(s).
This page suggests the following solution:
<script language="javascript">
function onKeyDown() {
// current pressed key
var pressedKey = String.fromCharCode(event.keyCode).toLowerCase();
if (event.ctrlKey && (pressedKey == "c" || pressedKey == "v")) {
// disable key press porcessing
event.returnValue = false;
}
} // onKeyDown
</script>
I should add though, that in general it is impossible for a webpage to tell the client browser to "disable cut and paste".
Btw, I never use Ctrl+C for copying text. I'm on XWindows so simply selecting the text will copy it. If I'm on a windows system I usually do Ctrl+Insert
I'm thinking that this question is pretty similar to yours: Disable pasting text into HTML form
My summary of the answers: You can, but it's messy and it's poor UI design. They also have some good suggestions for better UI design.
Please don't do that. I hate having to copy my email address, and if I actually had to type it twice, I would just leave unless I was being forced to make an account for some reason.
I like eclipse save actions feature, but I can't get rid of one little annoying thing. I use sorting members and methods on save.
The good thing is, eclipse moves member/method to correct position, alphabetically.
The bad thing is, when I am writing method and save it, eclipse moves method but not current caret position. So basically, I press CTRL+S and end somehwere at completely other place then I was before, so I have to scroll up/down to find new location of my method.
Is there some kind of workaround?
I am using Eclipse 3.6 Helios atm.
It sounds like a bug, try submitting it to eclipse at this site.
As a workaround - but not the best one, you can use Ctrl-O to find the method.
2 more workaround options:
Set a //TODO return here in the line that you want to return to, then you can filter the task view by a specific todo.
Put breakpoint before saving.
Generally I prefer not to use options like this, since when working with other poeple in a large scale project, it can cause a lot of noise. I mean that if you make a change to an existing file, then save it and then the format happen. next step you will commit this file to the repository. when someone or even you try to look at the diff of the change, it will be cluttered with all the formatting and sorting. So I prefer doing it as an independent change.