Re: [platform-debug-dev] Changing variable values

[Jared Burns <jared-eclipse@xxxxxxxxx>]

I could be mistaken, but I don't think this would necessarily work with other 
(non-JDT) debug models. Is there any requirement that the detail computed for 
a variable will match the string returned by the presentation's getText(...)?

For instance, couldn't I create a debug model presentation which displayed a 
description of a variable's type in the details area? Can't I have a 
variables view that looks something like so?

------------------------------
| String x = "blah"            |
------------------------------
| This variable is a String, |
| which means that it...      |
------------------------------

I like the idea, but I don't think it's possible.

- Jared

On Tuesday 23 July 2002 10:49 am, you wrote:
> Another approach would be to use the "details" area. The user could type
> into the details area and press "save (CTRL-S)" to save the contents back
> to the selected variabe. This is how VAJ worked - and avoids another
> dialog/editor.
>
> Darin
>
>
>
>
>
> Jared Burns <jared-eclipse@xxxxxxxxx>
> Sent by: platform-debug-dev-admin@xxxxxxxxxxx
> 07/23/2002 09:55 AM
> Please respond to platform-debug-dev
>
>
>         To:     platform-debug-dev@xxxxxxxxxxx
>         cc:
>         Subject:        [platform-debug-dev] Changing variable values
>
> http://bugs.eclipse.org/bugs/show_bug.cgi?id=17491
>
> For this bug report, I changed the variables view to replace control
> characters like newline with their two-character equivalent. For example,
> newlines are displayed as "\n". This solves the problem of displaying
> multi-line strings in a single line text field.
>
> However, this is still a problem when modifying variable values.
>
> There are two options here. We can display the modified text in the editor
>
> text field. This would maintain consistency for the user. If they want a
> newline in their string, they'd have to enter "\n" instead of hitting
> return.
> However, this is inconvenient and I imagine it would be very unwieldy if
> you
> were trying to edit a large string, such as the contents of a document.
> Another problem with this approach is that we'd have to manage the case
> where
> the user types a control character by either replacing it automatically or
>
> ignoring the keystroke.
>
> The other option is to get rid of the inline editor and pop up a dialog
> with
> a multi-line text field. We could display the text unaltered in this
> field,
> which would make it easier for the user to enter the text they want and
> should also be better for large strings. I favor this approach
>
> Thoughts?
>
> - Jared
> _______________________________________________
> platform-debug-dev mailing list
> platform-debug-dev@xxxxxxxxxxx
> http://dev.eclipse.org/mailman/listinfo/platform-debug-dev