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

[David Sanders <dsanders@xxxxxxxxxxx>]

We use the details area to output both variable information, variable
value, and a hex dump of the variable value.  For example:

PACKED-DECIMAL [20, 10]: "999999999.9999999999"

00000: 39393939 39393939 392e3939 39393939 999999999.999999
00010: 39393939 -------- -------- -------- 9999------------ 

Thanks,

David


Darin Wright wrote:
> 
> It is true that there are no restrictions on the display details and
> the content.
> 
> However, the user is always able to type any content they would like
> and save it back to the variable. Thus, in cases where the details
> does not reflect the content, there would not be a good starting point
> from which to edit. In general, I beleive that the details area
> displays variable contents, but it would be interesting to hear from
> other debug model developers on how they use the details area, and
> their opinion on such an "editor".
> 
> Darin
> 
>  Jared Burns <jared-eclipse@xxxxxxxxx>
>                                                To:
>  Sent by:                               platform-debug-dev@xxxxxxxxxxx
>  platform-debug-dev-admin@xxxxxxxxxxx          cc:
>                                                Subject:        Re:
>  07/23/2002 11:04 AM                   [platform-debug-dev] Changing
>  Please respond to platform-debug-dev  variable values
> 
> 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
> _______________________________________________
> platform-debug-dev mailing list
> platform-debug-dev@xxxxxxxxxxx
> http://dev.eclipse.org/mailman/listinfo/platform-debug-dev