<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <br>
    <div class="moz-cite-prefix">On 7/1/2012 3:59 PM, Dan Smith wrote:<br>
    </div>
    <blockquote cite="mid:4FF0AC3A.1010609@danplanet.com" type="cite">
      <blockquote type="cite">
        <pre wrap="">Forgetting for a moment about the apparently illegal repeater data
that breaks the upload to the D710,
</pre>
      </blockquote>
      <pre wrap="">
Please open an issue on the website and attach your debug log.</pre>
    </blockquote>
    <br>
    I know you already saw the bug but I'm reporting it here in case
    others want to comment:<br>
    <br>
    <a class="moz-txt-link-freetext" href="http://chirp.danplanet.com/issues/230">http://chirp.danplanet.com/issues/230</a><br>
    <br>
    <br>
    <blockquote cite="mid:4FF0AC3A.1010609@danplanet.com" type="cite">
      <pre wrap="">

</pre>
      <blockquote type="cite">
        <pre wrap="">is there a better way to upload a csv file? It seems a bit cumbersome
to first have to load the entire memory contents, then remove all
memories and then paste over.
</pre>
      </blockquote>
      <pre wrap="">
Yes, there's a better way. There's no need to delete everything first.</pre>
    </blockquote>
    <br>
    I first tried to paste over the existing data and it asked me 'do
    you want to overwrite' for each entry. That wasn't really workable
    so I first deleted everything. Does that sound like what I should
    have seen? Sorry for not including that part originally. I forgot
    till you wrote this.<br>
    <br>
    <blockquote cite="mid:4FF0AC3A.1010609@danplanet.com" type="cite">
      <pre wrap="">
Please keep in mind that the Kenwood ham rigs behave differently than
almost every other radio CHIRP supports. Thus, the workflow(s) are tuned
for a different memory model. If there are specific additional sequences
that would help Kenwood users work more efficiently, without penalizing
users of other radios and without turning CHIRP into an MCP clone, feel
free to file those in the issue tracker.</pre>
    </blockquote>
    <br>
    Yes, it would be great to have a non-live mode ala what MCP-2A does.
    I would like to be able to write a file to the radio without first
    having to read/clear all existing entries. I see the benefits of
    being able to change a few entries without writing all of them.<br>
    <br>
    <blockquote cite="mid:4FF0AC3A.1010609@danplanet.com" type="cite">
      <pre wrap="">

You might note that you can hit escape while chirp is attempting to load
all the memories from the radio, and that you can make individual
changes to memories while it's loading and it will prioritize those
writes over the background reads. However, exporting to CSV will cause
it to read any memories it has not yet red, for obvious reasons.</pre>
    </blockquote>
    <br>
    Ok, I did not know to hit ESC, will remember that, thanks.<br>
    <br>
    <blockquote cite="mid:4FF0AC3A.1010609@danplanet.com" type="cite">
      <pre wrap="">

</pre>
      <blockquote type="cite">
        <pre wrap="">- connect D710 to computer - load memories using CHIRP - delete all
memories using CHIRP (pasting over existing memories doesn't appear
possible)
</pre>
      </blockquote>
      <pre wrap="">
It's certainly possible. If something is failing, please open a bug and
attach your debug log.</pre>
    </blockquote>
    <br>
    Will wait you reply on the dialog. If it could be suppressed (simply
    flag an entry as illegal and move on) that would be great. Will open
    an RFE.<br>
    <br>
    <blockquote cite="mid:4FF0AC3A.1010609@danplanet.com" type="cite">
      <pre wrap="">

</pre>
      <blockquote type="cite">
        <pre wrap="">- copy all memories from .csv file - paste all memories onto empty
D710 document
</pre>
      </blockquote>
      <pre wrap="">
Just go to file-&gt;import and choose your CSV file. The import dialog will
show you the contents of the file to be imported and then let you import
them en masse. It does read the entire radio first to look for potential
collisions, which makes sense in every case other than importing a file
to replace the entire radio.</pre>
    </blockquote>
    <br>
    That makes sense, not sure why I didn't try that, sorry. Will try to
    soon.<br>
    <br>
    <blockquote cite="mid:4FF0AC3A.1010609@danplanet.com" type="cite">
      <pre wrap="">

Perhaps adding a "replace entire radio's memory with the contents of a
file" function would help here? That way, instead of downloading the
entire radio and then uploading all the changes, CHIRP could just step
through the current file and blindly blow the memories into the radio?</pre>
    </blockquote>
    <br>
    That would be really nice.<br>
    <br>
    Many thanks,<br>
    <br>
    &nbsp;&nbsp;&nbsp; Sander W1SOP<br>
    <br>
    <br>
    <blockquote cite="mid:4FF0AC3A.1010609@danplanet.com" type="cite">
      <pre wrap="">

</pre>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <br>
      <pre wrap="">_______________________________________________
chirp_users mailing list
<a class="moz-txt-link-abbreviated" href="mailto:chirp_users@intrepid.danplanet.com">chirp_users@intrepid.danplanet.com</a>
<a class="moz-txt-link-freetext" href="http://intrepid.danplanet.com/mailman/listinfo/chirp_users">http://intrepid.danplanet.com/mailman/listinfo/chirp_users</a>
</pre>
    </blockquote>
    <br>
    <br>
  </body>
</html>