开云体育

New tinySA-App release
Version 1.240.4
Changes:
- Integrated the normalize function from OneOfEleven
- Solved a crash in writing the CSV files when localization set to using a "," as decimal dot.

Hi Erik,

The version is really 1.240.5.

A quick test shows that you nailed the problem when writing CSV files. The function to choose the decimal and field separators runs perfectly. This makes very easy to use these files in Excel when Windows uses this configuration. Without it, it is quite cumbersome to do the conversion.

Thank you again.

Ignacio EB4APL

PD. Maybe Cathy could do the same in the nanoVNA-App for writing its files. It is really useful for countries which use comma as decimal separator.

--
El software de antivirus Avast ha analizado este correo electrónico en busca de virus.

On Thu, Oct 8, 2020 at 01:34 AM, EB4APL wrote:

PD. Maybe Cathy could do the same in the nanoVNA-App for writing its
files. It is really useful for countries which use comma as decimal
separator.

Yes no problem. Though I don't know what's been done or anything, Erik would have to let me see the source code to see what he's done exactly.

If OK with you I will push my branch to you so you can easily see the changes I made
Would it be possible for you to enable normalization of line endings in your github repository?
Windows is driving me crazy.......

On Thu, Oct 8, 2020 at 08:28 AM, Erik Kaashoek wrote:

If OK with you I will push my branch to you so you can easily see the changes I made
Would it be possible for you to enable normalization of line endings in your github repository?
Windows is driving me crazy.......

Yes sure.

No idea where the github line endings settings is, I just use GitHub Desktop to push any file changes.

On Thu, Oct 8, 2020 at 12:53 AM, OneOfEleven wrote:

No idea where the github line endings settings is, I just use GitHub Desktop to push any file changes.

If you add a file named .gitattributes to the folder where the nanoVNA-App .git subfolder and all the working sources are located, with only one line in it with:
* text=auto
the line endings should become normalized and the problems will disappear over time
Some of you current source files have a mix of windows line endings and linux line endings.
Examples:?
Graphs.cpp
Unit1.cpp
and my merging normalizes everything to windows line endings which confuses github compare and merg meaning I have to do all updating manually


I pushed my branch containing the tinySA variant.

If you search for field_sep, decimal_dot, fieldSep and decimalDot you will quickly find what I did to the regionalization of the .csv files

Had a quick look through your CSV code and found source code problems that will cause range check error pop ups.

I'll create a new function purely for .CSV file loading/saving and fix the source coding problems at the same time later on.

I sometimes cut some corners in my self inflicted urgency...
While you are making changes, can I kindly ask you to make the "S11" and "S21" part of the displayed graph names coming from a #define or a setting variable so I can change "S11" to "Level" in one location so Graphs.cpp can be reused without any change??

Adding settings for the user to have to set complicates things (decimal point and field char) for them, their are often far better ways really (though not always), you can auto-detect what the file is using (by doing a quick scan of the lines in the file for one), but at the moment I've gone the easy route and set the CSV load/save functions to use the users machine locale setting.

I will ALWAYS avoid adding any unnecessary settings for the user to have to set/fill-in if at all possible as it gives them something else to set/get wrong and cause problems.

Never let your PC software generate exception pop-up boxes on a users PC, if it does (as your CSV code was doing with the range check error exception dialogs) then the code must be fixed to never do so (you can totally screw up a PC if it gets out of hand if your software decides to throw up a 100 exception boxes in the following 2 seconds - I've had that happen and learn from it). Always assume the user is going to load a totally incompatible file (because they will at some point), always do sanity checks on every part of the data you're loading in, if their seems to be a problem with the data then let the user know so that they can either fix the error they are making or get back to you with the much needed feedback for you to fix the source coding error - treat pop-up exception dialogs as evil ;)

I've just set the CSV save function to surround each parameter (value) in the CSV file with double quotes (the CSV load function removes them) - this solves the decimal point problem.

The intention is to load the .csv file into excel for further analysis
Will this work with double quotes?

If excel is any good it should, no guarantee though, have to try it and see.

Using double quotes around each param is quite normal in CSV files (to over come the decimal point ambiguity).

I am neither a noob nor a luddite, nor am I a programmer, but I do really like this philosophy! Thank you!

73

-Jim
NU0C

On Thu, 08 Oct 2020 12:02:10 -0700
"OneOfEleven" <cmoss296@...> wrote:

Adding settings for the user to have to set complicates things (decimal point and field char) for them, their are often far better ways really (though not always), you can auto-detect what the file is using (by doing a quick scan of the lines in the file for one), but at the moment I've gone the easy route and set the CSV load/save functions to use the users machine locale setting.

I will ALWAYS avoid adding any unnecessary settings for the user to have to set/fill-in if at all possible as it gives them something else to set/get wrong and cause problems.

Never let your PC software generate exception pop-up boxes on a users PC, if it does (as your CSV code was doing with the range check error exception dialogs) then the code must be fixed to never do so (you can totally screw up a PC if it gets out of hand if your software decides to throw up a 100 exception boxes in the following 2 seconds - I've had that happen and learn from it). Always assume the user is going to load a totally incompatible file (because they will at some point), always do sanity checks on every part of the data you're loading in, if their seems to be a problem with the data then let the user know so that they can either fix the error they are making or get back to you with the much needed feedback for you to fix the source coding error - treat pop-up exception dialogs as evil ;)

On Thu, Oct 8, 2020 at 01:57 PM, OneOfEleven wrote:

If excel is any good it should, no guarantee though, have to try it and see.

Tested with this small file:

The program saves the CSV file according to the machines locale settings, so loading the file back into another program in the same locale should be flawless ?

If you're trying to load CSV files with number parameters from locales different to the locale software you're trying to load into, then you will have the problem you have unless the other software has been written to cope with that (few are unfortunately - including the big companies).

The CSV load function I've done for you will load a CSV file from either locale type.
?

Excellent

If you want to give the user a settings to alter the decimal point then go for it, though it can be made so that they don't need too.

If any user has any more problems with the CSV files then ask them to upload the problem file so you can use it and locate the exact line of code you have that may be causing the problem - easy to do if you set your TinySA-App project into debug mode (menu / view / configuration manager), set a break point on a line of code in the function with the possible problem and then single step through function, when the problem crashes (exception pop-up boxes or whatever) then you've found the line of code that needs fixing.

Also, it sounds like you're using linux or mac-os, if so then you can install that OS's version of the development software (c++ builder) and compile TinySA-App program to work directly in the OS of choice (no wine etc needed).

I only use windows so I can't compile NanoVNA-App for the other OS's, much as people might like.

Am I understanding correctly that the tinySA-App can be compiled to run on Linux?? What would that entail?? Could we go one step further and make it into an Appimage?

On Mon, Jul 26, 2021 at 05:30 PM, Jason Ringas wrote:

Am I understanding correctly that the tinySA-App can be compiled to run on Linux?? What would that entail?? Could we go one step further and make it into an Appimage?

Jason,
? The topic you are referring to was a conversation between Erik and OneOfEleven, the original developer of NanoVNA-App, of which tinySA-App is a branch.? NanoVNA-App and tinySA-App are written in C++ so according to OneOfEleven, "you can install that OS's version of the development software (c++ builder) and compile TinySA-App program to work directly in the OS of choice".

? OneOfEleven privately sent her code to Erik with the caveat that it was not to be publicly distributed.? Erik's development system is Windows so he does not have the software tools to attempt a cross development of tinySA-App to Linux or MAC.

? OneOfEleven recently publicly released her NanoVNA-App source code at? ?so possibly Erik could now also publicly? release his tinySA-App branch for users of other operating systems that want to help compile the application to run natively on their environment.

? Alternatively, NanoVNA-APP supports both the NanoVNA and tinySA so, if you have the proper development tools,?you could first try to cross compile OneOfEleven's public release to Linux and let Erik know if you are successful or not.

Herb
? ?