[chirp_users] CHIRP 0.1.7b5

[Dan Smith]

> I suspect the reason why chirpw crashed was that when I deleted Mem 50
> (through chirpw) that the chirpw could no longer talk to the IC92AD as
> it was no longer in DV mode on that memory.  I discovered this when I
> tried to restore using csvdump and it complained as well.  Setting the
> radio to another memory, in DV mode, sorted this out.

Ah, okay, I should have read all my mail before replying :)

> If we can get rid of the dependence of having to have the radio sitting
> on a DV memory before any transfers take place I think that a lot of
> headaches would be minimised :)

Yeah, I agree.  I've spent quite a bit of time working on this with no 
progress.  It's pretty freaking annoying, but I don't want to just spend 
all of my time on it.

> I then tried to overwrite an existing Memory using the Import function.
> The Confirm Overwrite button was ticked.  When it got to the appropriate
> memory it overwrote the existing memory without prompting.  I would have
> thought having this field ticked would have prompted before overwriting.
> I then unchecked the Confirm Overwrite field and tried again, but once
> again it overwrote the data without prompting.

That checkbox makes it prompt you when you change the location of a 
memory to something that conflicts with something already in the radio. 
  If you're just doing an import without moving things around, then it 
never does that check.

I'd prefer it to do that check when you change a memory, instead of all 
at once when you click the OK button or something.  So:

1. Does that sound counter-intuitive?
2. Should I blank the "New location" of any conflicting memories to
    force you to do that?
3. Should I mark them red to indicate they're conflicts without the box?
    (That way I could avoid the chicken-and-egg of only checking when you
    change the location).

-- 
Dan Smith
dsmith#danplanet.com, s/#/@/
www.danplanet.com
KK7DS