 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
Java Forum / GUI / December 2003Immutable text area idiom?
I have a custom component I'm assembling that I want to be able to be used for two purposes: reading and editing a particular object. When the component is in read-only mode, I'd like to update the widgets as necessary to look read-only. I'm not sure of the best way to do this. I know the method calls that I /could/ use, but none of them result in what I would think. Calling setEnabled() on a TextField, for example, isn't right, because that effectively disables the control, and the resulting look isn't right (it's gray, if I remember correctly, which is appropriate for a disabled component, but not for a writeable component that is in read-only mode). setEditable(false) on a TextArea effectively disables editing, but leaves the text area looking as though you /could/ edit things in it. I'm thinking that the answer is simple: just remove TextField components and replace them with JLabels, or muck with the UI colors and the setEditable() method. Is this how people generally approach this task? Cheers, Laird > I have a custom component I'm assembling that I want to be able to be > used for two purposes: reading and editing a particular object. When > the component is in read-only mode, I'd like to update the widgets as > necessary to look read-only. I'm not sure of the best way to do this. It's not clear whether you are mixing AWT and Swing components (don't). I'll assume you mean (J)TextFiled etc. when I ask.. Are you doing this using the Look-and-Feel that you are used to, or the default Metal L&F? -- Andrew Thompson * http://www.PhySci.org/ PhySci software suite * http://www.1point1C.org/ 1.1C - Superluminal! * http://www.AThompson.info/andrew/ personal site .. > Are you doing this using the Look-and-Feel that you > are used to, or the default Metal L&F? Alluding to the point I forgot to mention. What seems 'right' for you when a text control is disabled is probably (almost certainly) not how somebody using a different platform would expect to see it. >>Are you doing this using the Look-and-Feel that you >>are used to, or the default Metal L&F? I'd like to not care. (Also, incidentally, you are right; I am not mixing AWT and Swing components.) I'd like to do something easy, like: if (getReadOnly()) { this.setEditable(false); } ...but that doesn't look right on any L&F I try. Basically, all I'm trying to build is a simple property sheet. > What seems 'right' for you when a text control > is disabled is probably (almost certainly) not > how somebody using a different platform > would expect to see it. Right, but when the look and feel is geared towards a particular platform--e.g. Windows--then I'd expect /it/ to look correct on the platform for which it was designed. So is your recommendation, then, to simply do setEditable(false) (for example) and trust the L&F to get it right? I'm willing to live with that if that's the accepted idiom. Cheers, Laird ... > So is your recommendation, then, to simply do setEditable(false) (for > example) and trust the L&F to get it right? I'm willing to live with > that if that's the accepted idiom. 'Accepted idiom' I'm not so sure.. Well, what the hey, I'll start a trend. ;-) > ... > > So is your recommendation, then, to simply do setEditable(false) (for > > example) and trust the L&F to get it right? I'm willing to live with > > that if that's the accepted idiom. I just remembered, there are alternative L&F's you should have a play with before rolling your own. Check out the fine L&F's you can get from.. http://www.jgoodies.com/freeware/looksdemo/index.html Karsten (the author) brings a certain professionalism to L&F's that is quite slick. -- Andrew Thompson * http://www.PhySci.org/ PhySci software suite * http://www.1point1C.org/ 1.1C - Superluminal! * http://www.AThompson.info/andrew/ personal site [ snip ] > I just remembered, there are alternative L&F's > you should have a play with before rolling your > own. Check out the fine L&F's you can get from.. > http://www.jgoodies.com/freeware/looksdemo/index.html [ snip ] About alternative L&F's, take a look at www.javootoo.com. They have a list of about 17 different L&F's. Might be of some assistance. :: rob > ... > [quoted text clipped - 4 lines] > 'Accepted idiom' I'm not so sure.. > Well, what the hey, I'll start a trend. ;-) :-) Let me ask my question a different way, in case there's a different answer. A JLabel is optimized for the display of read-only information. You hand it a text string, it shows it. The Look and Feel people have presumably made a JLabel look a certain way to optimize what it's good at. A JTextField (for example) is optimized for the editing of simple textual information. The Look and Feel people have made it look a certain way to optimize what /it's/ good at. I'm building a component that at creation time will either be read-only or writeable. The read-only-ness of the component will not change over its lifetime. Is it "better" to: * Build the component using the most appropriate components (e.g. JLabels if it's read-only; JTextFields if it's not), or * Build the component using the most flexible components (e.g. JTextFields that are simply setEditable(false)ed when appropriate? From looking at some native windows applications, it looks like they tend to use label-like widgets when they're displaying read-only information, and text fields when it's editable--there are very few UIs I can think of that actually make use of a text area, for example, set to non-editable mode. Thanks, Laird .. > From looking at some native windows applications, it looks like they > tend to use label-like widgets when they're displaying read-only > information, and text fields when it's editable--there are very few UIs > I can think of that actually make use of a text area, for example, set > to non-editable mode. I cannot think of an instance where a component might be a text type field on one occasion and a label on another - can you provide a concrete example (assuming WinXP)? > I cannot think of an instance where a component > might be a text type field on one occasion and > a label on another - can you provide a concrete > example (assuming WinXP)? Hmm; perhaps you're right. I was under the impression that when a Word document, for example, was marked as read-only that the properties dialog box that came up would be uneditable but this appears not to be the case. I'll finish by trying to be clear (I'm having a hard time today being articulate; sorry about that) one more time. I have an object that sometimes I want to represent with a property sheet. Sometimes I want that property sheet to be displayed like the property sheet that you get when you right-click a file in Windows Explorer and select properties (note that you can't edit the property values for properties like "Type of file:", "Description", "Location", etc. and that there are no lines around the values (e.g. the value for, say, "Location:" is not a disabled or read-only text field but a label of some kind)). Other times I want to show that object with a property sheet that looks exactly the same except that this time you /can/ edit the property values. Choose File|Properties in any document in Microsoft Word for an example of this kind of property sheet. Note that the value fields are boxes in this case where you can type. I have two approaches. I can make two different components--one, the renderer or viewer, whose property values are displayed using JLabels, and one, the editor, whose property values are displayed using JTextFields. Or, I could make one component that either: * Decides to use JLabels for its property value fields when it's read-only and JTextFields for its property value fielsd when it's not read-only or * Decides to use JTextFields only, but marks them as being either editable or non-editable as appropriate When I do the latter, in the read-only case I end up with a property sheet that doesn't look right. The property values, not surprisingly, look like text fields that you should be able to edit, but, of course, because they've had setEditable(false) called on them, you can't edit them. On the other hand, I don't really want to duplicate code. Hopefully that gets across my problem. Let me know if that helps. Cheers, Laird > > I cannot think of an instance where a component > > might be a text type field on one occasion and > > a label on another - can you provide a concrete > > example (assuming WinXP)? > > Hmm; perhaps you're right. .... > I have an object that sometimes I want to represent with a property sheet. Go with TextFields if the fields can sometimes be edited. To the wider question, I would say it is a conceptual problem, yours. You are wanting to create non-editable fields that are somehow different to the way the user would expect to see non-editable fields. Now, just because the fields do not appear non-editable to you, does not necessarily go for the user. Ultimately, change the user's preferred way of doing things only under the most extreme circumstances. After all, you can do the your way, and the user can uninstall your software in preference to software that has a look and feel thay are used to and comfortable with, or software that allows them to choose from standard L&F's. -- Andrew Thompson * http://www.PhySci.org/ PhySci software suite * http://www.1point1C.org/ 1.1C - Superluminal! * http://www.AThompson.info/andrew/ personal site > After all, you can do the your way, and the > user can uninstall your software in preference > to software that has a look and feel thay are > used to and comfortable with, or software > that allows them to choose from standard L&F's. Hmm; I'm deliberately /not/ trying to do anything non-standard. My complaint is that the look-and-feels that ship with the JDK do not do things in standard ways. Oh well; for now I'll just use JTextFields in all cases; when the component is supposed to be read-only, I'll just set them to setEditable(false) even though this does not look right in any look and feel that ships with the JDK. Cheers, Laird > Hmm; I'm deliberately /not/ trying to do anything non-standard. My > complaint is that the look-and-feels that ship with the JDK do not do [quoted text clipped - 4 lines] > setEditable(false) even though this does not look right in any look and > feel that ships with the JDK. Even Microsoft don't do that consistently; by default, a disabled text box in a Visual C++ program goes grey... in a Visual Basic program, it remains white (assuming standard colours in Control Panel). I recommend not trying to fight the system, because it may work just fine on Linux or Solaris and not on Windows; trying to 'fix' how it behaves on Windows may have an undesirable effect on the other OSs. Just leave the L&F to do what it wants, and see what feedback you get from your users. They'll soon let you know if a change is warranted. THEN you can worry about it {:v)  Signature-- Jason Teagle jason@teagster.co.uk > To the wider question, I would say it is a conceptual problem, yours. > You are wanting to create non-editable fields that are somehow > different to the way the user would expect to see non-editable > fields. I'm not sure I agree with you here Andrew. It might be that you (or I) have misunderstood the OP. I'm not an OOP expert by any means but surely the following would be okay and meet the requirement? <CODE> import java.awt.GridLayout; import java.awt.event.*; import javax.swing.*; public class PrefThing extends JFrame { public PrefThing(String title) { super(title); addWindowListener(new WindowAdapter() { public void windowClosing(WindowEvent e) { System.exit(0); } }); } public void addSomething(boolean editable, String text, int param) { if(editable) getContentPane().add(new JTextField(text, param)); else getContentPane().add(new JLabel(text, param)); GridLayout gl = new GridLayout(getContentPane().getComponentCount(), 1); getContentPane().setLayout(gl); pack(); } public static void main(String[] args) { PrefThing pt = new PrefThing("Test"); pt.addSomething(true, "editable", 8); pt.addSomething(false, "uneditable", SwingConstants.LEFT); pt.addSomething(true, "another editable", 20); pt.show(); } } </CODE> Btw, am I correct in converting tabs to spaces for Usenet? I thought it would be best to have tabs so people can choose their own tab size. However, a couple of netiquette guides I checked said "use spaces". Signaturesam brightman (To reply by e-mail use spam instead of ham and lose the jam) > > To the wider question, I would say it is a conceptual problem, yours. > > You are wanting to create non-editable fields that are somehow [quoted text clipped - 4 lines] > have misunderstood the OP. I'm not an OOP expert by any means but surely > the following would be okay and meet the requirement? Code speaks a thousnad words eh, Sam? ;-) Well, I'm not convinced - try my variant.. http://www.physci.org/codes/display.jsp?fl=%2Ftest%2FEditableComponents%2FPr efThings.java If I was less lazy I'd do an applet as well, ..maybe later. -- Andrew Thompson * http://www.PhySci.org/ PhySci software suite * http://www.1point1C.org/ 1.1C - Superluminal! * http://www.AThompson.info/andrew/ personal site ... > > I'm not sure I agree with you here Andrew. ... > Well, I'm not convinced - try my variant.. http://www.physci.org/codes/display.jsp?fl=%2Ftest%2FEditableComponents%2FPr > efThings.java Now updated, tidied, JDoc'd.. > Now updated, tidied, JDoc'd.. Thanks, folks, for your input. One last question, that I hope should make it easier. When the property sheet is in edit mode, some of the value slots should be filled with JComboBoxes. Obviously (?) these JComboBoxes should not be displayed when the property sheet is in read-only mode (after all, the value has been selected already). In this case, does it make sense to build two separate components, one for read-only applications and one for editing, or is it "better" to use one component that decides at construction time to use JComboBoxes or JLabels? Thanks, Laird > > Now updated, tidied, JDoc'd.. > > Thanks, folks, for your input. > > One last question, that I hope should make it easier. Shheeesh! You really take some convincing Laird! >..When the property > sheet is in edit mode, some of the value slots should be filled with > JComboBoxes. Obviously (?) these JComboBoxes should not be displayed > when the property sheet is in read-only mode (after all, the value has > been selected already). All-bloody-right. http://www.physci.org/test/EditableComponents/ _Now_ has (freakin') ComboBoxes.. [ And a cute little launcher, see it straight off the net! ] > In this case, does it make sense to build two separate components, one > for read-only applications and one for editing, or is it "better" to use > one component that decides at construction time to use JComboBoxes or > JLabels? And I am _still_ not seeing that any 'special' situation exists that would require changing component types for editable/non-editable data. ;-) -- Andrew Thompson * http://www.PhySci.org/ PhySci software suite * http://www.1point1C.org/ 1.1C - Superluminal! * http://www.AThompson.info/andrew/ personal site > Shheeesh! You really take some > convincing Laird! Yes, I do. Slow and steady wins the race. Or the right to go home. I'll stop posting to this thread now. :-) It's pretty clear to me that it's really odd to have to /disable/ a control (versus setting it to non-editable) in order to semantically indicate read-only information. Labels it is. Cheers, Laird > > Shheeesh! You really take some > > convincing Laird! > > Yes, I do. Slow and steady wins the race. Or the right to go home. > > I'll stop posting to this thread now. :-) .... > Labels it is. (sighs) You can lead a horse to water.. ;-) > (sighs) You can lead a horse to water.. ;-) (I lied.) Look, I understand your points, and they are good ones. Boiled down, they are essentially "Don't try to outsmart the look and feel; it knows what it's doing." With this I agree entirely. This is not a look and feel issue, however. I don't have a problem with the way that a given component is being rendered in a particular look and feel. I don't have a problem with look and feel implementations period. I have a problem with exactly what components I should use to represent particular information. I have never seen a property sheet that displays information about a live object somewhere that uses /disabled/ components to show "enabled" information. Non-editable components? Sure. But that's different. If a component is disabled, that means you aren't really supposed to look at it, or it is not applicable in some other way. Those are NOT the semantics I wish my UI in this case to convey. I wish simply to convey that X is the current value for property Y, and nothing else. Again, I thank you for your obviously hard work on this subject. Cheers, Laird > > (sighs) You can lead a horse to water.. ;-) .... > Again, I thank you for your obviously hard work on this subject. You're welcome. ..And I got a cute little app launcher out of it anyway, so whichever way I cut it, it was a profitable experience.. :-) >>> To the wider question, I would say it is a conceptual problem, >>> yours. You are wanting to create non-editable fields that are [quoted text clipped - 10 lines] > http://www.physci.org/codes/display.jsp?fl=%2Ftest%2FEditableComponents%2FPr > efThings.java What were you not convinced about... the code (if so, what? :) or Laird's feelings on GUI design? I'm thinking from the rest of this thread that you're still not convinced about what it conveys to the user. In that case, we'll have to differ. Generally I would think first of showing them disabled but wouldn't object to a UI that made labels instead, provided the circumstances were appropriate. In the wrong circumstances, the user could be led to believe that a particular property *could not* be edited and subsequently "put up" with the problem when they did want to edit it. Perhaps this property was in fact editable when they wanted it to be but they assumed it wasn't. Obviously, this is undesirable. Signaturesam brightman (To reply by e-mail use spam instead of ham and lose the jam) ... > >>> ...You are wanting to create non-editable fields that are > >>> somehow different to the way the user would expect to see > >>> non-editable fields. > >> > >> I'm not sure I agree with you here Andrew. ... > What were you not convinced about... the code (if so, what? :) or > Laird's feelings on GUI design? Hi Sam! Yes, it is more the concept itself I don't get. ..I look back throught this thread to realise that nobody within it has changed their position or opinion one iota. Gee, ..I wonder if that has ever happened before in the course of human history? ;-) > .... > [quoted text clipped - 17 lines] > Gee, ..I wonder if that has ever happened > before in the course of human history? ;-) Yeah, it is possible that it has happened before... I'm trying to concede that it might not be the best idea in some circumstances but with the proviso that there's no reason to think that you'd *never* want to do it. However, Laird seems to be indicating that I've misunderstood anyway... oh well. Signaturesam brightman (To reply by e-mail use spam instead of ham and lose the jam) > Generally I would think first of showing them disabled but wouldn't > object to a UI that made labels instead, provided the circumstances were [quoted text clipped - 3 lines] > Perhaps this property was in fact editable when they wanted it to be but > they assumed it wasn't. Obviously, this is undesirable. Right. I think there may be confusion about what I'm trying to do. I'm most certainly /not/ trying to build one component that can switch at will between read-only states and editable states. That is, for the life of the component instance, it will /either/ be an editor (with, say, combo boxes displaying choices) /or/ a...a...reader (with, say, labels displaying the current value). Just as, for example, the file properties dialog box that comes up on Windows when you right click a file icon doesn't show you a disabled text box to display the file's location, even though conceivably you could edit that somewhere else or in another component. So I'm trying to decide whether it is better to build /two/ component classes--one whose sole job in life is to display information (in which case I think you would agree that it should use labels), and one whose sole job in life is to edit information. If I /were/ to write only /one/ class to handle these /two/ cases, /then/ I was wondering if there were some way to accomplish it without having to switch the types of widgets involved. Since a truly /disabled/ component of any type is by its very nature not intended to be interacted with by the user, it seemed funny to me to recommend that as a solution for displaying information. Cheers, Laird > Right. I think there may be confusion about what I'm trying to do. I'm > most certainly /not/ trying to build one component that can switch at [quoted text clipped - 6 lines] > location, even though conceivably you could edit that somewhere else or > in another component. I didn't think you wanted it to switch states "on the fly". I thought the file properties example was a good one, provided one thing was true. I got the impression that there may be certain external conditions that would merit the properties page coming up with, say, "Location" being editable. I thought this would be okay in some contexts but not in other ones; the problem being that the user may "learn" that "Location" can't be changed and then assume they couldn't do what they wanted in future. > So I'm trying to decide whether it is better to build /two/ component > classes--one whose sole job in life is to display information (in which > case I think you would agree that it should use labels), and one whose > sole job in life is to edit information. If the above is not true then I don't get why you don't just use a JLabel as a label and a JTextField as a text field :) > If I /were/ to write only /one/ class to handle these /two/ cases, > /then/ I was wondering if there were some way to accomplish it without > having to switch the types of widgets involved. Since a truly > /disabled/ component of any type is by its very nature not intended to > be interacted with by the user, it seemed funny to me to recommend that > as a solution for displaying information. If I'm still not getting the right idea and you want to do this then maybe something like overriding methods in JTextField to change the way the uneditable state is drawn or, possibly better, write your own class to do *exactly* what you want. Signaturesam brightman (To reply by e-mail use spam instead of ham and lose the jam) > If I'm still not getting the right idea and you want to do this then > maybe something like overriding methods in JTextField to change the way > the uneditable state is drawn or, possibly better, write your own class > to do *exactly* what you want. Thanks. When I'm done with this, I'll be happy to post what I've done. Hopefully it will speak for itself. :-) Cheers, Laird ... > > ..possibly better, write your own class > > to do *exactly* what you want. > > Thanks. When I'm done with this, I'll be happy to post what I've done. Great Laird, I might add a short example to the same page where I have been doing my UI - for the sake of comparison. It is so much easier when noobs can _see_ the effects of UI's.. -- Andrew Thompson * http://www.PhySci.org/ PhySci software suite * http://www.1point1C.org/ 1.1C - Superluminal! * http://www.AThompson.info/andrew/ personal site Free MagazinesGet these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...
|
Reply to this Message
|
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2009 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.