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.
Description: Steps to reproduce: - create and deploy a BPEL application - set a breakpoint - attach debugger - send test message - when the breakpoint is achieved open BPEL Variables debug window - click on ellipsis button next to any variable, editor window appears - try to open an editor window for another variable Result: Now only one editor window is allowed to watch the variable in debugger. Because message type variable is a very long xml text it is difficult to compare two of them.
I do not think this is a bug. This seems to be consistent with Variable view in Java debugger, no? If it is not consistent with Java debugger, then we have a problem and you can reopen the bug. Otherwise this should be an RFE to debugger in general.
Reopening as a request for enhancement. (lowering to P4) This definitely would be a nice feature to have to be able to compare multiple variable values.
Debugger Core operates the Variable Values Windows the same way as it does for all other fields in the Debugger Views. That is it opens a custom editor as a modal dialog when the elipsis button is pressed. I don't believe we could ask the Debugger Core team to treat VARIABLES fields differently neither we could ask them to change this behaivor for all the other fields. Although, we could think of using another approach (I believe it was originally proposed by Mike Frisino) along with the existing one. Along with having an ellipsis button and custom editor for the BPEL Variable Value we could add an action on the variable's node - smth like "Open Variable's value in the Editor". Adding such an action would not intorduce any inconsistency with Java or other debuggers. Lingling, Mike, do you think that would suffice to be able to compare variables' values?
I think we shoulld propose the last idea to HIE and see what they say. My biggest concern is with the lifecylcle of the non-modal edit window. Its not a file, its a variable value so how do respect this lifecylce?
-> Sierra
The user has the ability expand the variables, so that individual tag and attribute values are seen in the tree. Hence it is much easier to compare these values. I assume that this will satisfy this use-case. Also, as Mike mentioned, the current behavior is consistent with Java debugger et al. Resolving as WONTFIX.
verified