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 35140 - Nodes switch places after selecting the "Command-line Diff" node
Summary: Nodes switch places after selecting the "Command-line Diff" node
Status: RESOLVED FIXED
Alias: None
Product: utilities
Classification: Unclassified
Component: Diff (show other bugs)
Version: 3.x
Hardware: All All
: P4 blocker (vote)
Assignee: Martin Entlicher
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2003-07-25 10:52 UTC by bnv
Modified: 2003-12-11 14:20 UTC (History)
3 users (show)

See Also:
Issue Type: DEFECT
Exception Reporter:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description bnv 2003-07-25 10:52:38 UTC
Product Version       = Sun ONE Studio, Native
Edition (Build 030722)-- build 14                  
IDE Versioning        = IDE/1 spec=3.42.1 impl=030722
Operating System      = SunOS version 5.8 
Java; VM; Vendor = 1.4.1_02; Java HotSpot(TM)
Client VM 1.4.1_02-b06; Sun Microsystems Inc.

1.Tools->Options->IDE Configuration->Server and
External Tools Settings->Diff Settings
2.Select 'Default Diff Engine' property editor
3.Wait for the 'Default Diff Engine' dialog
4.Select the Diff Engines->Command-line Diff node

The selected node at the previous one switch places.
Comment 1 _ tboudreau 2003-09-09 03:46:49 UTC
Reassigning to diff module.

Martin - the problem here is that the diff module writes to the
folder that the editor is showing (I guess you probably have a 
setting like "isDefault" on the objects).  The problem is that
ObjectEditor's UI uses Explorer, and is listening to the folder for
changes.  It receives one when the user selects the item, which
causes the view to refresh.

There's another problem, which I worked around, which is that since
the tree gets rebuilt, the BeanTreeView in the editor will briefly
set the selection to null, and DiffSettings can't handle null.  I
did a workaround by ignoring any changes that set the selection to
null (the user can't do that through the GUI anyway).

I'm thinking about providing a radio-button based UI for ObjectEditor
that would have less of these problems.  But a better solution 
might be to just use something a little more normal than ObjectEditor
- it's kind of a mess (sorry Jarda).

Probably we eventually need some kind of enum editor over a registry
context, which would be similar in function.
Comment 2 Martin Entlicher 2003-11-27 13:21:15 UTC
This is in fact as designed.

The order of nodes is significant, because the first node represents
the default engine. This is why when you change the default, the order
has to change as well.

In dev there's a different property editor and this should not be an
issue any more.

Therefore this was already fixed.