Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [platform-debug-dev] Changing variable values

In light of this, we'll go with the dialog implementation. I've released the 
changes to CVS.

- Jared

On Tuesday 23 July 2002 12:08 pm, you wrote:
> 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
>
> _______________________________________________
> platform-debug-dev mailing list
> platform-debug-dev@xxxxxxxxxxx
> http://dev.eclipse.org/mailman/listinfo/platform-debug-dev


Back to the top