So, I'm working with swing and I need to find a clean (non-CPU-hogging-way) to introduce a delay on a text field. Basically, users will enter a number into this field and the keyReleased() event checks that the input fits a few parameters and then assigns the value to a data storage element in the program. If the data is invalid, it displays a message. Since the routine is called every time they type a letter (unless they type VERY fast), the input process becomes quite annoying (as in general one or two characters of data are not going to fit the allowed parameters).
I've tried setting up a timer object and a timer task for it, however it doesn't seem to work very well (because it delays the thread the program is running on). The option to just wait until the data reaches a certain length is also not possible since (as state before) the input can vary in length.
Anyone got any ideas? Thanks!
I've done stuff like this fairly frequently, and I have two suggestions.
The standard way of dealing with this is to use the InputVerifier class. This however only operates when the input component loses focus - it's designed to prevent the user navigating out of an input field when it's invalid, but it doesn't check until then.
The other way I've done this is to check validity on every keystroke, but not to bring up a message when it's invalid. Instead use a color to indicate validity - e.g. color it red when its invalid and black when valid. This isn't nearly as intrusive as the message. You can use a tooltip to give more detailed feedback.
You can also combine these methods.
Write a custom DocumentFilter. Read the section from the Swing tutorial on Text Component Features for more information.
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 got customized JComboBox which has the ability of autocomplete. It has attached KeyListener where I call HttpClient.send(request) and it returns some result array which I show in dropdown of combo box. For example, user starts typing "a" and the dropown offers all the results which starts with the letter a. The issue is I would like to wait like 2 seconds after the last character is written (so it won't send request after every key input), otherwise the app is laggy (response takes some time). I was thinking about using Runnable interface:
save time of last key press (using System.currentTimeMillis) into last variable
wait for 2 seconds
check if the value in last is still the same
if true, send request
The idea is if in those 2 seconds user types another character, the value of variable last is updated. Is this bad approach? Is it even doable? I got literally zero experience with multithreading. Can you give me an advice if I should do it this way or if there is some easier way?
I recommend to use kotlin coroutines ,
you can save your request in coroutine and cancel it when user type another letter
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" -- ##&$!!!)
I have a java swing application which has a form that I populate by scanning a barcode containing tab (or $I) delimited data as keyboard input through a USB connection. Intermittently, the form's text fields are incorrectly populated such that it appears the tab is processed too late. For example, if the data set in the barcode is something like 'abc$Idef', the expected output would be 'abc' in the 1st text field and 'def' in the 2nd text field. What we see sometimes instead is 'abcde' in the 1st text field and 'f' in the 2nd or even all data in the 1st text field and nothing in the 2nd.
I have seen this issue manifest at different frequencies across different days. Today could be good and I only see it happen 1 out of every 150 attempts. Yesterday it could have been poor, happening 1 out of 10 attempts. The scanner is at or near default factory settings with the exception of me toggling the parameter to implement tab vs $I delimiter. I have also attempted slowing down the transmission speed, and while that does appear to decrease the frequency of events, it does not eliminate them and the the slowed speed is not ideal for user workflow and so, reset it to full speed.
I am doubtful that the issue lies within the scanner however. in the application, I've attempted to disable all text field validations and data backups to essentially remove any custom code which might cause some delay, but the intermittent issue still exists. Currently the application is running on a WinXPSP3 using JRE 1.5.0_18. The scanner is a Symbol model ds6707. I could use some guidance in investigating this issue further to determine where the problem may lie.
Consider reading the stream on a separate thread and posting completed units on the EventQueue. This will ensure that events arrive "Sequentially…In the same order as they are enqueued." SwingWorker is convenient for this, as the process() method executes "asynchronously on the Event Dispatch Thread."
I have a textfield and if I want to write something to the field, it will show me the list of possible options regarding to that letter and I think this is called an auto complete.
Could someone give me an idea or a sample on how to do it?
Thanks..
Take a combo box and listen to all changes in the textfield. On every event, read the actual content and query your source list for possible matches. Then use the result to populate the associated list.
You may want to start autocompletion once the user has entered two or three letters, otherwise the list may get too long..
look here is AutoCompleteComboBox / JFextField, and there are two classes one for JComboBox, second for JTextField, notice auto-complete functionality requires both classes for that
I feeling generous as you really should google ...
As the user types, you'd need to query your DB with a like '<userInput>%' and return the results into a pulldown. You probably want to wait for a pause in the user's typing so as not to hammer your DB.
In the absence of a database, a data structure that would work well for this is called a Trie as you can traverse it past the initial input and present all the subsequent words.