This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
There is a bug in the current code which will cause that a PropertySheet will *render* property value containing html content instead of displaying it *literally*. So when a user starts to edit such a value (s)he will see another string to edit than it was displayed. E.g. Node.Property p = ... p.setValue("<html><b>test</b><html>"); User will see, in the property sheet or in the debugger view (local variables, watches), value *test* in bold instead of literally displayed html string <html><b>test</b><html>. The attached patch fill fix this. However because the current behaviour could be wanted and correct in some cases (maybe the form module) there will be a possibilty to provide "html-display value" which will be used as display value in the property sheet (it it is set). This value would be supplied by: FeatureDescriptor.setValue("htmlDisplayValue", "<html><em>My Display Value</em></html>"). Another but somehow related to this issue is how tooltips will be shown. Either displaying plain text of property value or htmlDisplayValue. If you have a strong opinion about this please add your comment. Otherwise some default solution will be provided. Note: Also I had some problem with HtmlRenderer (bug or bad usage) so current implementation could change, but not described functionality. To try how it works apply the attached simple patch and play with your code (I could also add a little "demo" if it is needed)
Created attachment 20647 [details] Simple patch (created with -w for easier reading)
i suggest to use the same approach for tooltips, i.e. add a "htmlTooltipValue" property where module developers can specify html-formated value to be displayed in tooltip. if no such value is specified then the tooltip management will take the raw text value (not the "htmlDisplayValue"), break it into multiple lines if it's too long, escape undisplayable characters and display it in tooltip.
Isn't PropertyEnv.getFeatureDescriptor() the property itself? In such case this would not be correct - "htmlDisplayValue" would be stored in the property - but it should be just property editor specific. Form the form editor point of view this is problem if the property editor is changed. So I think yu should at least reset the value to null always before passing the PropertyEnv to a property editor.
> Isn't PropertyEnv.getFeatureDescriptor() the property itself? In > such case this would not be correct - "htmlDisplayValue" would be > stored in the property Don't know what exactly do you mean by "property" - Node.Property, PropertyDescriptor, property in general ...? Maybe that in fact PropertyEnv.getFeatureDescriptor() always returns Node.Property (don't know all cases and all PropertySheet code so deeply). But javadoc to PropertyEnv.getFeatureDescriptor() says "...It is feature descriptor so one can plug in PropertyDescritor and also Node.Property...". So there probably could be cases when it returns PropertyDescriptor or FeatureDescriptor. So I think we should use property attribute instead of adding new member to Node.Property. > but it should be just property editor specific. Anybody can crate custom editor which will ignore the "htmlDisplayValue" at all. > Form the form editor point of view this is problem if the property > editor is changed. So I think yu should at least reset the value > to null always before passing the PropertyEnv to a property > editor. Can you describe use case or scenario where it is a problem. Do you mean changing editor in custom editor (when the user clicks ... and changes an editor)? I don't see any differences before and after applying the patch. Thanks for more detailed description.
> i suggest to use the same approach for tooltips, i.e. add a > "htmlTooltipValue" property where module developers can specify\ > html-formated value to be displayed in tooltip. I see two reasons why not to do it: 1. nobody really needs it (afaik) and the code will get complicated 2. the handling of htmlDisplayValue is done inside of (Inplace)StringEditor - it is not property sheet specific. This can be done as the editor is the one who paints the value, however (afaik) the tooltip is shown by the propertysheet itself and we would have to create a contract between the editor and the propertysheet to negotiate on the content (if PropertyEditor.getAsText() would not be enough - as is imho now). If my above described understanding is correct I would not try to solve the HTML tooltips right now.
Suggestions: Forget HtmlTooltipValue - tooltips will handle HTML fine as long as it contains <html> tags - HtmlRenderer is able to work without <html> tags because it needs to be fast, but tooltips are not displayed so often (and Jarda, the code is complicated anyway :-). Breaking of tooltips using HTML is already there (I assume that's what we're talking about). Maybe we need to add some intelligence to detect if there already is HTML markup in the tooltip? What problem are we trying to solve?
- when stringeditor displays an html formated value (e.g. bold+red), do we want to display tooltip using the same html? - the current tooltip code expects the value to be plain text and breaks long text into 80 chars lines (10 line max). the new code must also escape non-displayable characters (see issue 55153) my reasoning was that module developers know better what the value actually represents and may provide better html tooltip formating. but i agree it may be an overkill though. in this case i think the tooltip formatter should get the raw text value as its input and ignore any fancy html formating from the "htmlDisplayValue" property.
Answering to mkrauskopf 2005-03-06 23:16 PST My point is that if PropertyEnv.getFeatureDescriptor() returns the Node.Property then if one property editor sets "htmlDisplayValue" it is kept there and will be used always for that property (by the StringRenderer) no matter of the current property editor (which may change). > Can you describe use case or scenario where it is a problem. > Do you mean changing editor in custom editor (when the user > clicks ... and changes an editor)? Yes. > I don't see any differences before and after applying the patch. If one of the editors sets "htmlDisplayValue" then the value starts to be painted as html. If you change to another property editor (which may want to provide different text), the previous html value still will be painted. The other editor does nothing with html, but unless it resets the "htmlDisplayValue" (which is still in Node.Property), the StringRenderer will paint it.
So I was told, the StringRenderer is used only with StringInplaceEditor, not with the other property editors. In such case I'm ok with the change.
htmlDisplayValue - seems that nobody has any additionally comments. So thanks for review. I'm going to implement it. Regarding tooltips we will talk about the exact implementation with Standa personally. Probably I shouldn't notice them here since they are not in fact too much associated to the htmlDisplayValue problem - was my mystake to note it here. If there will be some bigger issues we will open new review following up this one.
Commited, fixed. Checking in openide/src/org/openide/explorer/propertysheet/RendererFactory.java; new revision: 1.17; previous revision: 1.16
Verified.