1

I am using a JTextField, wherein I am filtering input coming in via REGEXs and notifying the user (background color changes) and then pushing the updates out over a socket (character by character, not a 'Hit enter when you're done' kind of behavior, by spec)

The issue is, since there's no guaranteed order of DocumentListener notification, I cannot put both the transmission of the update and the validation of the update on the same kind of listener. Is there any guaranteed order of notification amongst different kinds of Listeners (KeyListener vs DocumentListener vs ... ) with a JTextField?

I can find no helpful documentation about between different kinds of Listeners, only (it seems) within a single kind of Listener (such as a DocumentListener)

Thanks!

EDIT 1 Validation - REGEX validation does not permit me to disallow any text coming in since additional characters may make an 'invalid' string 'valid'.

Separation of Behavior - By design, I cannot merge the two behaviors into one listener, they are being set up at different times in the code flow and that cannot be changed. It's a protocol design issue that's not up for debate. I can't really go into more useful detail without just explaining the whole thing. The salient point is they are just separated into two listeners. I need to make the transmission step happen after the validation step, so I need to know if there is a CONCRETE definition of Listener KIND notification. By Kind I mean KeyListener vs DocumentListener vs UndoableEditListener. I know within each kind of listener no order is guaranteed.

However, is it guaranteed that DocumentListeners are all notified before UndoableEditListeners or vice versa? Or are all different kinds of listeners just notified in no particular order whatsoever.

EDIT 2

Sorry, it seems as we are getting lost in the weeds hardcore.

At this moment, all I am trying to figure out is:

Is there a Java-language guarantee as to the order in which different classes of Listeners (such as: Key, Document, UndoableEdit) on a JTextField are notified?

mKorbel
  • 109,525
  • 20
  • 134
  • 319
Aaron Marcus
  • 153
  • 2
  • 13
  • after you edit, please to see linked post in comment to HFOE, can it help you??? btw do you store Undo-Redo in separate array programatically or??? – mKorbel Jan 29 '14 at 19:28
  • such as: Key, Document, UndoableEdit) on a JTextField are notified?, yes there is one option --> never to use KeyListener for JTextComponents, milion times asked and explained here very well, incl. impact to java.swing.text APIs – mKorbel Jan 29 '14 at 19:39
  • I am not trying to use them. That is not my question. I get that I should never use KeyListeners. What I want to know is: are they notified programmatically BEFORE DocumentListeners or AFTER DocumentListeners? Or are they intermingled WITH DocumentListeners? Is there a general order for all the different kinds of Listeners on a JTextField? – Aaron Marcus Jan 29 '14 at 19:41
  • everything depends of (do you want to something) 1. char by char or 2. after validation is done a) with success only, b) without exceptions c) all possible events success, fail, exception – mKorbel Jan 29 '14 at 20:02
  • note 1. DocumentListener is listener for firing all event outside from Document (can't be able to modify own Document), 2. but DocumetFilter can to modify Document and firing all event everywhere, as you want to... – mKorbel Jan 29 '14 at 20:03
  • Can we take a step back from trying to diagnose my software for a second? I really do think given all the details of it, this is the correct way, I just really need to know if there is a guaranteed order of Listener notification across different kinds of Listeners (NOT multiple listeners of the same kind) – Aaron Marcus Jan 29 '14 at 20:04
  • sorry we are volunteers here and by default we don't want to diagnose anything isn't clear from description or SSCCE, MCVE, we don't plant and grow guessing here – mKorbel Jan 29 '14 at 20:06
  • I just want to know what the order is of Listener notification. It's not a code issue. I cannot find the answer in Java documentation. Here is my clear description. JTextField can have many different KINDS of Listeners attached to it (Document, Key, UndoableEdit). When JTextField is modified by a user typing characters into it. Is it guaranteed that one of those kinds of Listeners will be notified before the others? If so, what is that order? – Aaron Marcus Jan 29 '14 at 20:11
  • again if changes going outside of JTextField (Document) then to use DocumentListener, if you want to modify, filtering, anything with Document (model for JTextComponents) then to use DocumentFilter, there no issue to use both, but no ordering is guarantee, both (or all) are executed, trouble came from LowLevel Listeners (mentioned KeyListener) because can to consume() event, then rest of Listeners isn't notifyed, because there isn't accelerator, everything can be/is consumed by LowLevel Listener – mKorbel Jan 29 '14 at 20:18
  • Do you know where in the Java documentation it says that there is no guaranteed order? – Aaron Marcus Jan 29 '14 at 20:23
  • not it doesn't exist, bad experiencies from questions (in SSCCE, MCVE form) here, there everywhere +1 for effort, out of this thread, much luck – mKorbel Jan 29 '14 at 20:27

1 Answers1

2

I'm not 100% sure of exactly what your problem is, but it sounds like you really want to use a DocumentFilter, not a DocumentListener. The filter gets changes to the document before they have been submitted to the JTextField view, and so allows for decent filtering of input. I am 100% sure however that you don't want to use a KeyListener.

Edit
You state in comment:

I have need of separating the two behaviors (filtering/notifying user and transmission) as two separate listeners.

But again, why? Why two listeners? Are you trying to use two DocumentFilters?

Since I need the update to happen after a filter/validation I can't use the same kinds of listeners.

By "update" do you mean transmission? Or do you mean updating the text displayed in the JTextField?

I am still not sure why a DocumentFilter won't work for you. As noted above, it allows you to validate input before it gets displayed in the JTextField. Wouldn't this solve pretty much any "order" problems?

Edit 2

I can't prevent text input because I am using REGEXs for filtering. So, it's possible that a string of text is invalid, but could become valid, so I don't want to disallow the character since there's no way with the REGEX system in Java to determine if additional characters could validate the string. So I have to permit it, but 'validate' it (give it an OK or NOT OK).

OK, understood. So you do not want to not allow invalid input, but just not transmit it until it's valid, correct?

Because of some infrastructure design (fault it or not, I can't change it) I cannot combine the two behaviors of validation and transmission (which is out through a standard socket connection to another machine)

This is where I'm confused. Can you describe this limitation in greater detail? How exactly are you transmitting it in such a way that you can't do so from within the listener. This is of critical importance to this question (at least as far as I am concerned).

To finish from prior comment, the transmission needs to be only when the content is valid, so the validation has to happen before the potential transmission

So I'm guessing that your current program work-flow in pseudocode goes something like this:

Inside of listener
   get latest text 
   Check if text is valid or not
   if it is valid, then transmit text 
   notify user that valid text has been sent
   ? reset text field
end of listener

Is this correct? And again, of paramount importance to me is the restriction described above.

Edit 3
You state:

Is there a Java-language guarantee as to the order in which different classes of Listeners (such as: Key, Document, UndoableEdit) on a JTextField are notified?

Again as I've stated in comment, one can state without hesitation that a DocumentFilter definitely acts before a DocumentListener acts. As for multiples of the same listener -- that as you know is undefined. As for the order between multiple other listeners, you may need to look at the source code to find out. Again, please let us know the details about your restriction, the source of your absolute need to use more than one listener.

Hovercraft Full Of Eels
  • 283,665
  • 25
  • 256
  • 373
  • @AaronMarcus: I'm not 100% clear why a DocumentListener isn't working for you. – Hovercraft Full Of Eels Jan 29 '14 at 18:48
  • It is working just fine. However, since I can't rely on the order of a particular DocumentListener being notified, I am having issues. I have need of separating the two behaviors (filtering/notifying user and transmission) as two separate listeners. Since I need the update to happen after a filter/validation I can't use the same kinds of listeners. – Aaron Marcus Jan 29 '14 at 18:54
  • I can't prevent text input because I am using REGEXs for filtering. So, it's possible that a string of text is invalid, but could become valid, so I don't want to disallow the character since there's no way with the REGEX system in Java to determine if additional characters could validate the string. So I have to permit it, but 'validate' it (give it an OK or NOT OK). Because of some infrastructure design (fault it or not, I can't change it) I cannot combine the two behaviors of validation and transmission (which is out through a standard socket connection to another machine) – Aaron Marcus Jan 29 '14 at 19:03
  • To finish from prior comment, the transmission needs to be only when the content is valid, so the validation has to happen before the potential transmission – Aaron Marcus Jan 29 '14 at 19:07
  • @AaronMarcus: again thanks for the update. Please see next iteration of my answer. Consider posting some of your clarification remarks above as an edit to your original question so that the question is a complete clear and succinct whole. Luck! – Hovercraft Full Of Eels Jan 29 '14 at 19:16
  • 1
    @Aaron Marcus Swing code doesn't guarantee ordering of listener, nor ordering of events fired from one listener, this logics is implemented in EDT or RepaintManager exclusivelly, you have to firing 1. one listener 2. or simple semaphore with ordering Events programatically, 3. or implement [EventHandler](http://stackoverflow.com/a/9007348/714968) (required excelent knowleges about Java Essential classes and Swing), as aside your question missing touch point, goal, expectations (very good described in answer, comments by HFOE:-) – mKorbel Jan 29 '14 at 19:21
  • 1
    @Hovercraft Full Of Eels +1 btw :-) [why complicating simple things](http://stackoverflow.com/questions/7318622/regex-determine-matrix-from-string) – mKorbel Jan 29 '14 at 19:25
  • @mKorbel So you are saying across all different kinds of Listeners (Key, Document, UndoableEdit) there is no order at all, as in it could update a KeyListener, then a DocumentListener, then another KeyListener, then an UndoableEditListener? – Aaron Marcus Jan 29 '14 at 19:27
  • 2
    @AaronMarcus: No, you cannot predict what multiple of the same kind of listeners will do, but you *can* state without hesitation that a DocumentFilter definitely acts ***before*** a DocumentListener acts. As for the other listeners, you may need to look at the source code to find out. – Hovercraft Full Of Eels Jan 29 '14 at 19:30
  • @Aaron Marcus KeyListener is LowLevel Listener, then can to consume() all Key Events, you lost this event. and event is flushed to EDT, note you have to redispatch() this/those event(s), maybe this is way to... – mKorbel Jan 29 '14 at 19:32
  • @AaronMarcus: No, avoid KeyListeners if at all possible. For one, using them prevents getting updates if the text component is modified in any other way, such as by copy and paste, or by programmatic edits. – Hovercraft Full Of Eels Jan 29 '14 at 19:33
  • I am not using KeyListeners. I am only referencing them because they are a kind of Listener. – Aaron Marcus Jan 29 '14 at 19:37
  • I know that you cannot predict what multiples of the SAME KIND of Listener will do, but what about of DIFFERENT KINDS of Listeners? – Aaron Marcus Jan 29 '14 at 19:39
  • @AaronMarcus: see Edit 3. – Hovercraft Full Of Eels Jan 29 '14 at 20:17