Thanks for the clarification. I don't need to use this file it was only for testing. I will delete it and make a new one from the current version. The logical "File Format Compare" step would be extreeeeeeeeemely helpful. You get my vote. This goes for import overlays as well. Hint Hint I spent the better part of 4 hours running down an invisible entry (space) in a csv file for the map import only to discover through the debug that it was trying to import to many fields. I hate to sound windowish, but an error messsage would be of great help in these circumstances.

Thanks Dan

73

Dave N4DIB

-----Original Message----- From: chirp_users-bounces@lists.danplanet.com [mailto:chirp_users-bounces@lists.danplanet.com] On Behalf Of Dan Smith Sent: Wednesday, November 26, 2008 12:00 PM To: Discussion of CHIRP Subject: Re: [chirp_users] CSV Import

Hi Dave,

Not having much luck importing csv into Chirp using the import feature (although it is much easier to find the file now with the selectable dropdown) Here is a copy of the csv file. Can someone see what is wrong? This file was created from chirp as an export.

It looks like this CSV file was generated with CHIRP before I added the Tuning Step field to the format. So, CHIRP is looking for the tuning step in what is actually the URCALL field and thus is failing to import each of the lines.

I obviously need to make it report these sorts of failures better, no question about that.

Anyway, if you insert a column (using Excel or something) after the Mode field, and before the URCALL field, and put something like "5.0" in there for each memory, then you should be able to import it.

Further, I'm about to add a couple more columns like skip and bank in there, which will require another change to existing CSV files. This is a good reason why CSV isn't a very practical storage mechanism for things like this. The .chirp files can have version information embedded in them so we can help protect backwards compatibility.

How about I read the first line of the CSV and compare it to the list of column headers the current version would write out, and throw an error message if they don't match? This would help determine that the formats are incompatible. The only problem with this is that if you synthesize a CSV file, you'd have to include that header verbatim, and if you tweaked it by accident, it would fail to import.

Dave T, you're a heavy CSV user... What would you think about adding that to the CSV load logic?

Dan,

Also I would agree that bypassing a single error may not be in the best interest when that one record turns out to be the one you need. I am okay with athe all or none approach. I think the information that is writen to the debug log would be more then sufficient to explain the problem and where to go to fix it. I don't know how hard it is to take that information and send it to an Error Window. When I finally looked in the debug log every line that had erronious data displayed as "in error". This made it very easy to correct. Not sure what can be done without major work, but this is just my experience. Hopefully this same type of logic check can be performed in all imprt functions for DRATS and Chirp.

Thanks Dan and Happy Turkey Day

Dave N4DIB

-----Original Message----- From: chirp_users-bounces@lists.danplanet.com [mailto:chirp_users-bounces@lists.danplanet.com] On Behalf Of Dan Smith Sent: Wednesday, November 26, 2008 12:29 PM To: Discussion of CHIRP Subject: Re: [chirp_users] CSV Import

Thanks for the clarification. I don't need to use this file it was only for testing. I will delete it and make a new one from the current version. The logical "File Format Compare" step would be extreeeeeeeeemely helpful. You get my vote. This goes for import overlays as well. Hint Hint I spent the better part of 4 hours running down an invisible entry (space) in a csv file for the map import only to discover through the debug that it was trying to import to many fields.

Yep, I know. That's one nice thing about the .chirp format, it's much harder to break just because of a misplaced character.

Right now, it behaves as it does because it's hard to decide how tolerant I should be of errors in the file. For example, if one CSV line is bad, but the rest are okay, should I throw an error on the first and give up? Should I go on and parse the rest?

Now that I hear how some of you are using it, I think the former might be better than the (current) latter approach. If you've got multiple errors, you'll see the first. If you correct it and try to import again, you'll see the second one, etc.

I hate to sound windowish, but an error messsage would be of great help in these circumstances.

Showing error messages isn't a Windows trait. There is no shame in that... :)

Throwing up an intelligent error box is not quite as trivial as it sounds in many cases, mostly because of where it has to happen in the code to make sense and avoid breaking things when you're not running in a GUI.

Thanks Dave :)