I got 2.470328229206233e-323 in Igor 7.02 and
7.09471e-274 in Igor 1.38B01
for "#NV". This value should correspond to #N/A in the English version; created with the NV() resp. NA() function; Excel 2016.
Having a look in the xml-file shows #N/A as value.
Maybe it's a glitch in the loader?
As a workaround you might load the data as text and convert it later on in Igor, e.g. using str2num.
This affects loading .xlsx files but not .xls files.
I have fixed the problem in Igor7. #N/A will be treated as NaN. This fix should be available tomorrow (Wednesday Pacific Time) in the nightly build. Choose Help->Igor Pro Nightly builds.
I am not going to fix it in Igor6. Here is a workaround that you can execute after loading the wave:
wave0 = wave0<1E-300 ? NaN : wave0 // Workaround for XLLoadWave not recognizing #N/A
This affects loading .xlsx files but not .xls files.
I have fixed the problem in Igor7. #N/A will be treated as NaN. This fix should be available tomorrow (Wednesday Pacific Time) in the nightly build. Choose Help->Igor Pro Nightly builds.
I am not going to fix it in Igor6. Here is a workaround that you can execute after loading the wave:
wave0 = wave0<1E-300 ? NaN : wave0 // Workaround for XLLoadWave not recognizing #N/A
Hi hrodstein,
Thank you for your effort. Could you also do this for IGOR Pro 6.37? I have the same problem in 6.37.
Thank you for your effort. Could you also do this for IGOR Pro 6.37? I have the same problem in 6.37.
I'm afraid not.
In Igor6, XLLoadWave is an XOP which is trickier to mess with than something in Igor itself. Changing, recompiling, and testing it for Macintosh and Windows, 32-bit and 64-bit, is quite time consuming.
More important, any change runs the risk of introducing new bugs and we don't want to be introducing new bugs in Igor6. That would make Igor6 less stable and divert us from work on Igor7 and Igor8.
7.09471e-274 in Igor 1.38B01
for "#NV". This value should correspond to #N/A in the English version; created with the NV() resp. NA() function; Excel 2016.
Having a look in the xml-file shows #N/A as value.
Maybe it's a glitch in the loader?
As a workaround you might load the data as text and convert it later on in Igor, e.g. using
str2num
.HJ
February 21, 2017 at 07:20 am - Permalink
I have fixed the problem in Igor7. #N/A will be treated as NaN. This fix should be available tomorrow (Wednesday Pacific Time) in the nightly build. Choose Help->Igor Pro Nightly builds.
I am not going to fix it in Igor6. Here is a workaround that you can execute after loading the wave:
February 21, 2017 at 03:58 pm - Permalink
Hi hrodstein,
Thank you for your effort. Could you also do this for IGOR Pro 6.37? I have the same problem in 6.37.
Peter
March 23, 2017 at 02:49 am - Permalink
I'm afraid not.
In Igor6, XLLoadWave is an XOP which is trickier to mess with than something in Igor itself. Changing, recompiling, and testing it for Macintosh and Windows, 32-bit and 64-bit, is quite time consuming.
More important, any change runs the risk of introducing new bugs and we don't want to be introducing new bugs in Igor6. That would make Igor6 less stable and divert us from work on Igor7 and Igor8.
March 23, 2017 at 11:13 am - Permalink