[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
[dsdp-dd-dev] Re: FW: Load/save/fill memory operations
|
Ted,
I'll be more than happy to yield this feature to you :-) I've got a
million other things to do, so I have no problem letting this one go.
This is a must-have feature for our first Eclipse based product, and
that's why I was going to jump on it. If you were planning on
contributing this anytime in the next six months or so, that would work
for us. And of course, I'll be more than happy to work with you on the
feature if you'd like to team up on it.
See my comments inlined below:
At 09:36 PM 4/3/2006, Williams, Ted wrote:
John,
Yes, I've been planning to contribute such a feature, but (oops) I
wasn't aware of the bugzilla. If you're planning to implement this
soon,
I'll hold off. :-)
I understand the feature will be extensible, but I'd like to add a
few
thoughts in addition to what I see in the bugzilla.
- The reading/writing should happen on a Job. Large chunks can take
substantial time to transfer to and from embedded targets. The
cancel
flag should be checked periodically, between read and write
requests.
Definitely.
- Would a verify option
(checkbox in the dialog, read and compare after
write during the download) be useful?
Sure.
- There may be some
overlap with the "copy to clipboard" action. Maybe
copy and paste could be shortcuts to import/export actions or at
least
some of the code could be reused? Export to textual is similar to
copy.
Indeed, there's overlap, but I'm not sure there will be a good mapping
between copy&paste and the actions. If we can think of copy&paste
as an import/export action with a fixed, pre-defined set of
parameters...but even there, the destinations are quite different. I
imagine there's potential for code reuse but not a direct link between
the two sets of actions.
- Any thoughts on supporting
expressions in the address field of the
import/export dialog?
I think Samantha and I were envisioning import/export being retargetable
actions that could be invoked from, say, the context menu of the variable
view and _expression_. To that extent, expressions would be supported, but
such an action would bring up the dialog with the physical ptr/variable
value/address as the start address, pre-populated in the dialog. Whether
we should directly support expressions in the dialog...I suppose, but I
don't see a pressing need for it.
John
