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.

Bug 76522 - tagged property editor has many problems inside TTV
Summary: tagged property editor has many problems inside TTV
Status: VERIFIED WONTFIX
Alias: None
Product: platform
Classification: Unclassified
Component: Outline&TreeTable (show other bugs)
Version: 6.x
Hardware: Sun All
: P3 blocker (vote)
Assignee: Jiri Rechtacek
URL:
Keywords:
Depends on: 33281
Blocks:
  Show dependency tree
 
Reported: 2006-05-17 23:35 UTC by ivan
Modified: 2009-11-02 11:00 UTC (History)
0 users

See Also:
Issue Type: DEFECT
Exception Reporter:


Attachments
a demo module demonstrating combo box editor behavior (11.51 KB, application/x-compressed)
2006-08-23 16:15 UTC, Stanislav Aubrecht
Details
proposed fix (hack) (6.74 KB, patch)
2006-10-27 17:30 UTC, Stanislav Aubrecht
Details | Diff
a better fix (1.34 KB, patch)
2006-11-16 15:33 UTC, Stanislav Aubrecht
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description ivan 2006-05-17 23:35:03 UTC
Consider the NewBuggyEditor property editor appended.
It has getTags() returning some values.
Install it as the property editor for some String-valued property.

It has the following problems:

1) If env.getFeatureDescriptor().setValue("canEditAsText", Boolean.TRUE);
   Then when you click on the menu triangle, it seems to get into
   a fight over the focus with the text editor and the text editor wins
   causing the menu to go away.
   a) This happens in the TTV but not in the Properties window.
   b) This happens if the cell containing this editor doesn't already
      contain focus. For example, after the first failed attempt, if you
      click on the triangle again you get the menu.
   c) If you do succeed in utilizing the menu (see (b)) once a selection
      is reflected the cell stays in editing mode and a further TAB is
      required to get out of editing mode.
   d) Switching back to older deprecated EnhancedPropertyEditor interface
      makes no difference.
   
   e) We export our property editors to the TTV via the debuggercore 
      modelview interface, so there's a slight chance it plays a role
      but it's hard for me to ascertain that.

   We use this for the breakpoint count-limit property which we desire
   to accept both text/numeric input and a small set of pre-canned 
   actions via the menu, hence the combination of tags and editable text.
   After enabling/disabling, this is the most frequent user activity
   with breakpoints so this is important. 

2) If canEditAsText is set to FALSE the menu behaves. This isn't a workaround
   for us. However there are still issues here, namely that the down triangle 
   is rendered in (disabled?) light blue as opposed to black, even though
   it is actually active and works. The light blue becomes invisible against
   the table row-selection feedback color which is the same.
   Incidentally the Properties windows selection color seems to be hard-coded
   to the older Swing ~lavender, but the light-blue trinagle is pretty much
   invisible there as well.

3) The triangle control does not respond if the TopComponent containing
   it isn't active. One has to select the TC first.
   This is in contrast to all other controls like the Boolean check-box and
   the String "edit" button: [...]
Comment 1 ivan 2006-05-17 23:37:05 UTC
    private static class NewBuggyEditor extends PropertyEditorSupport
                                     implements ExPropertyEditor {
        private String text = "<initial>";

        public String[] getTags() {
            String [] tags = {"A", "B", "C"};
            return tags;
        }

        public void setAsText(String newText) {
            System.out.println("BuggyEditor.setAsText(" + newText + ")");
            setValue(newText);
        }

        public String getAsText() {
            if (text == null)
                return "<null>";
            else
                return text;
        }

        public void setValue(Object newValue) {
            if (newValue == null)
                text = null;
            else
                text = newValue.toString();
        }

        public Object getValue() {
            return text;
        }

        // interface ExPropertyEditor
        public void attachEnv(PropertyEnv env) {
            env.getFeatureDescriptor().setValue("canEditAsText", Boolean.TRUE);
        }
    }
Comment 2 Jiri Rechtacek 2006-05-22 15:56:43 UTC
I guess it's more likely problem TTV then PE. If I'm wrong reassign back. Thanks

Ivan, what version of NetBeans you do speak about? NB5.5 or dev version?
Comment 3 ivan 2006-05-23 19:49:50 UTC
This seem to be broken all the way back to 4.X.
Comment 4 ivan 2006-08-17 03:32:41 UTC
Could someone please take a look at this?

Comment 5 Stanislav Aubrecht 2006-08-18 11:14:25 UTC
i'm working on this however there are other p2 issues that need to be fixed for
release55 at the moment
Comment 6 ivan 2006-08-18 20:15:29 UTC
Thanks.
Do you have a readily reproducible testcase?
Comment 7 Stanislav Aubrecht 2006-08-22 10:49:57 UTC
well, i don't have a junit test case but i wrote a simple module with a
treetableview where i can reproduce the described behavior.
so far i noticed that the problem is not limited to tagged property editor only.
even the plain in-place text editor behaves incorrectly in ttv when compared to
property shee.
Comment 8 Stanislav Aubrecht 2006-08-23 16:15:55 UTC
Created attachment 33204 [details]
a demo module demonstrating combo box editor behavior
Comment 9 Stanislav Aubrecht 2006-08-23 16:18:53 UTC
ivan, can you pls test the attached module and compare the combo box editor
behavior with the one in debugger's treetableview?
i found out that the debugger view behaves a bit differently, e.g. Enter key
updates the edited value and stops editing, while in my module (plain ttv) it
leaves the editor active.
the ttv code is a horrible mess and i don't want to spend days looking for
issues that are actually elsewhere...
Comment 10 ivan 2006-08-23 21:33:50 UTC
1) Module open causes an NPE. Do I need to use NB 5.5 or trunk?
2) I don't understand what this module is or you want me to 
   do with it.
   Is it a reproducible testcase?
   Is it a fix?
   If you suspect that debuggercore is getting in the way how
   would verifying this make a difference.
Comment 11 Stanislav Aubrecht 2006-08-24 10:31:42 UTC
i developed the module against trunk but it should run fine with 5.5 after
fixing some dependencies (sources are attached).
the module is not a fix. it opens a topcomponent with a treetable view showing
three nodes with a plain in-place string editor and your "buggy" combo box
editor. i need you to confirm that the combo box behavior is the same as the one
you're experiencing in your enhanced debugger ui. if the behavior isn't the same
then it's up to the debugger team to evaluate this issue as i have now way of
reproducing it.
Comment 12 ivan 2006-09-01 21:15:37 UTC
sorry for the delay.
Problem (1) (See original description) still fails in this testcase.
Problem (3) doesn't happen in this testcase but that could be related to
the TC being in the editor mode among other things.
Comment 13 ivan 2006-10-13 21:59:37 UTC
I'd like to get this working for SSX3 if possible.
Comment 14 Stanislav Aubrecht 2006-10-27 17:30:15 UTC
Created attachment 35604 [details]
proposed fix (hack)
Comment 15 Stanislav Aubrecht 2006-10-27 17:32:10 UTC
i've attached a patch that fixes problems #1 and #2 but i don't like it that
much. it's a big hack.

i wasn't able to reproduce problem #3 - perhaps it is debugger related.


ivan, can you pls try the attached patch and let me know if it is working for
you? i can also email you a complete jar if you want.
Comment 16 ivan 2006-10-30 20:59:11 UTC
Can I apply this patch to a 5.5 base?
Comment 17 _ rkubacki 2006-10-31 08:55:25 UTC
I guess you want this for MARS so release55_mars branch will be what you are
looking for. release55 is closed now except for localizations AFAIK.
Comment 18 Stanislav Aubrecht 2006-10-31 10:41:49 UTC
yes, the patch is applicable to 55 branches as well
Comment 19 ivan 2006-10-31 20:24:25 UTC
Hmmm ... I applied the patch to the folder org.openide.explorere.propertysheet
First I got a popup saying patch not applicable.
Then I got a popup saying patch partially applied.

???? what good a partially applied patch?
I can't undo this either can I?

Comment 20 Stanislav Aubrecht 2006-11-01 09:29:54 UTC
sure you can undo the patch: cvs - revert modifications
i can email you patched jar if you have problems with the patch.
Comment 21 David Simonek 2006-11-08 11:28:54 UTC
I reviewed the patch-hack and unfortunately it's not ready for integration. It
uses classes from Win plaf, so it will neither compile or work on Unixes. It
seems that soem focus fix deep in TTV will be needed. However, due to the
asynchronous nature of focus events, I imagine this could be very hard to fix.
Comment 22 Stanislav Aubrecht 2006-11-13 13:11:35 UTC
i'll try to tackle the problem this week again but from a different direction.
however i cannot guarantee i'll be able to find a usable fix.
imho the issue could be degraded to P3 as it is not a serious bug.
Comment 23 Stanislav Aubrecht 2006-11-15 10:24:19 UTC
fixed part 2) of the bug description in trunk:
Checking in RendererFactory.java;
/cvs/openide/explorer/src/org/openide/explorer/propertysheet/RendererFactory.java,v
 <--  RendererFactory.java
new revision: 1.10; previous revision: 1.9
done
Checking in EditorPropertyDisplayer.java;
/cvs/openide/explorer/src/org/openide/explorer/propertysheet/EditorPropertyDisplayer.java,v
 <--  EditorPropertyDisplayer.java
new revision: 1.4; previous revision: 1.3
done

and in release55_mars branch
Checking in EditorPropertyDisplayer.java;
/cvs/openide/explorer/src/org/openide/explorer/propertysheet/EditorPropertyDisplayer.java,v
 <--  EditorPropertyDisplayer.java
new revision: 1.1.42.1.18.1; previous revision: 1.1.42.1
done
Checking in RendererFactory.java;
/cvs/openide/explorer/src/org/openide/explorer/propertysheet/RendererFactory.java,v
 <--  RendererFactory.java
new revision: 1.1.14.2.2.1.18.1; previous revision: 1.1.14.2.2.1
done
Comment 24 Stanislav Aubrecht 2006-11-16 15:33:05 UTC
Created attachment 36098 [details]
a better fix
Comment 25 Stanislav Aubrecht 2006-11-16 15:39:28 UTC
i've attached a better and simpler fix. 

now when the user clicks the drop-down button OR the text area of the combo-box
the drop-down menu expands and stays visible. the text area has input focus and
the text in it is selected. so the user can either enter new value directly from
the keyboard or use mouse/arrow keys to choose from the drop-down menu.
the only downside is that the drop-down menu 'blinks' as it is first shown, then
hidden and then forced to expand again.

ivan, can you please verify that the patch is working for you?
Comment 26 Stanislav Aubrecht 2006-11-21 16:23:08 UTC
fixed in trunk

Checking in ComboInplaceEditor.java;
/cvs/openide/explorer/src/org/openide/explorer/propertysheet/ComboInplaceEditor.java,v
 <--  ComboInplaceEditor.java
new revision: 1.5; previous revision: 1.4
done
Comment 27 Stanislav Aubrecht 2006-11-23 10:43:15 UTC
fixed in release551 branch

Checking in ComboInplaceEditor.java;
/cvs/openide/explorer/src/org/openide/explorer/propertysheet/ComboInplaceEditor.java,v
 <--  ComboInplaceEditor.java
new revision: 1.1.14.2.2.1.22.1; previous revision: 1.1.14.2.2.1
Comment 28 ivan 2008-03-31 22:46:21 UTC
Apologies for re-opening this.
I do not find the fixes satisfactory (as tested in 5.5.1 and 6.0).

- The "focus fighting" described in 1.a and 1.b persists.
- The inability to select from combo box and be done with it (1.c) persists.
- Saubrecht's fix of  Thu Nov 16 15:39:28 +0000 2006
  IMO makes matters worse. If one chooses to strictly edit text and
  clicks in the text area the combo-box pulldown appears. 
  This is not how combo-boxes are supposed to work.
Comment 29 Stanislav Aubrecht 2008-04-01 09:40:50 UTC
it doesn't seem to be such a big issue since it was reopened after 4 months:)
lowering to P3, hopefully it'll be addressed with treetable rewrite planned for nb7
Comment 30 ivan 2008-04-01 23:38:37 UTC
This is not required for 6.1.1, so P3 is fine.
However, please consider ...

I've been dealing with NB bugs for over ten years.
In that context 4 months is a very short time.

If you really want to say ...
   If it were a priority to ivan he should've payed attention sooner
... I can't. I do round-robin scheduling of my tasks
and that's how long it took before I got to this one.

For more perspective consider that it took me roughly
one month of debugging to identify and isolate the
problems in #99042 or how many times we went back and forth
on #50761 until I traced the bug to #130265.

I also can't accept hopefully's.
Pretty much all of the visual elements of the debugger (jpda
included) utilize the TTV ... there has to be some
meaningful commitment to the fixing of the TTV. Tim's
contrib alternative to the TTV is not official enough.

Is there an umbrella IZ for a NB7 TTV rewrite?



Comment 31 Stanislav Aubrecht 2008-04-02 10:25:01 UTC
i've started adding tim's contrib/ttv into main repository and i've already got it working for debugger views (to some
extent). i'll be happy to share with you what i have at the moment and discuss all outstanding issues

ttv umbrella issue: #33281
Comment 32 ivan 2008-06-03 23:51:36 UTC
I've checked with the outline/based replacement and unfortunately
none of the issues were magically fixed:

- The "focus fighting" described in 1.a and 1.b persists.
- The inability to select from combo box and be done with it (1.c) persists.
- Saubrecht's fix of  Thu Nov 16 15:39:28 +0000 2006
  IMO makes matters worse. If one chooses to strictly edit text and
  clicks in the text area the combo-box pulldown appears. 
  This is not how combo-boxes are supposed to work.
Comment 33 Jiri Rechtacek 2009-05-06 18:33:55 UTC
No plans to fixing TTV in no distant time.
Comment 34 ivan 2009-10-31 01:26:39 UTC
modelview package has converted to outlineview.
This is a definite improvement.
1.b  still a problem (the fighting over focus)
1.c fixed
3 fixed
Because of the definit improvement I'm going to close this as verified and
open a new IZ to deal with 1.b
Comment 35 Quality Engineering 2009-11-02 11:00:47 UTC
NetBeans.org Migration: changing resolution from LATER to WONTFIX