I just remembered that there is a bug preventing TextArea from being subclassed. https://issues.apache.org/jira/browse/PIVOT-690
See the thread listed in the ticket's comments for more info and a quick and dirty workaround. http://apache-pivot-developers.417237.n3.nabble.com/TextAreaSkin-tp2068356p2125940.html Chris On 25 February 2011 05:46, Chris Bartlett <[email protected]> wrote: > Bill, > > I don't have a lot of time to reply right now, but can reply further if > required a bit later. > > The bottom of this tutorial page describes event propagation in Pivot, > although it is fairly brief. > http://pivot.apache.org/tutorials/component-and-container.html > > ComponentKeyListeners for Pivot Components will generally be added to the > Component's skin upon creation. > So for TextArea, the ComponentKeyListeners will be in > org.apache.pivot.wtk.skin.TextAreaSkin (rather than TerraTextAreaSkin). > You will see TextAreaSkin#keyPressed(Component, int, KeyLocation) has the > logic to process the ENTER key. > > The problem comes when you try to add your own ComponentKeyListeners to try > to override this logic. > If you just add your listener to a standard TextArea, it will be processed > after any other listeners which were added before it. This means that the > TextAreaSkin#keyPressed(...) code will already have run before your code > gets a chance to do anything. > > For any given class, all of the listeners (ComponentKeyListeners or other > kinds) added at a particular hierarchy will be executed in the order they > were added to the class. If you want to override some logic in a listener, I > think you will need to create subclass, add your listener to that, and > ensure that you consume the event. When the event has been consumed it will > no longer propagate up or down the hierarchy, and therefore can block the > execution of other listeners. > > I really struggled with this when I was new to Pivot, but once I got used > to creating subclasses as and when I needed them, it pretty much all came > together. > > Chris > > > > On 25 February 2011 05:20, Bill van Melle <[email protected]>wrote: > >> There are two text input controls (that I know of), TextInput and >> TextArea. TextInput accepts a single line of text, but it is also only a >> single line on the screen, with no provision for wrapping text instead of >> clumsily horizontally scrolling. TextArea happily wraps text, but it also >> accepts the Enter key to insert newlines into the content. >> >> What I'm looking for is a control that accepts only a single line of >> input, but wraps. It should not accept the Enter key, but instead allow that >> key to close a dialog. I tried using a TextArea to which I added >> a ComponentKeyListener with this override: >> >> public boolean keyTyped(Component component, char character) { >> if (character == Keyboard.KeyCode.ENTER) { >> close(true); >> return true; >> } >> return false; >> } >> >> That only partly works -- it closes the dialog when the Enter key is >> pressed, but it also inserts a newline into the TextArea. I guess that's >> the downside of no guaranteed ordering of listeners. However, even if I >> move that logic to the keyPressed method instead, it doesn't help. >> >> Am I missing something? I can, of course, post-process the input to >> remove the newline, but that seems crufty. >> >> (FWIW, the WPF control corresponding to both of these controls, TextBox, >> lets me do this by setting attributes AcceptsReturn=False and >> TextWrapping="Wrap".) >> > >
