Change of Behaviour in LV2010: Last EOL lost with config file

[Michael.Proctor]

Hello all,

In a previous thread I mentioned that the  EOL characters were being lost on write to text file.

Now I have understood what is happening and I believe it is a bug - or at least a change in LabVIEW behaviour.

The Problem is not in Write Text to File but with Write Key in the config file vi

In LV2009 and earlier; when using the Write Key Vi to write to a file where the Section bring written to is NOT the last text in the file.,Any EOL at the very end of the file are left untouched.

In LV2010 the EOL is lost.

This is not good as I append my data to the end of the file and update any run parameters in the sections above the data.

It has worked nicely for the last 10 years, but it does not in LV2010.

I have enclosed a test vi that I quickly developed to demonstrate the problem.

Michael

[Fred_V]

Hi Michael,

I've taken a look at your code, and I see what you're saying. The EOL characters do disappear when you use a Write Key VI after you Write to Text File. However, I did see the same behavior with running the VI with LabVIEW 2009 as well, so I'm not sure when the behavior changed. 

I'll file a CAR with R&D to look further into the issue.

Thanks,

[Ben]

---

@Fred_V wrote:

Hi Michael,

I've taken a look at your code, and I see what you're saying. The EOL characters do disappear when you use a Write Key VI after you Write to Text File. However, I did see the same behavior with running the VI with LabVIEW 2009 as well, so I'm not sure when the behavior changed. 

I'll file a CAR with R&D to look further into the issue.

Thanks,

---

ah-hah !

That is why it did not make sense.

config have been re-written in LVOOP.

Ben

[Michael.Proctor]

thanks for the testing and verification.

I did not test my test code vi in lv2009 but my production code vis ( that contains elements of the test code but some differences in execution order ) has been used lv2009 since February and I did not see the dropping of the EOL

but does in lv2010 so there is some difference that are causing EOL loss.

michael

[Neilo]

I'm struggling with a related issue in LabVIEW 2011. I'm migrating an application from LabVIEW 8.6 to LabVIEW 2011. Running my test VI (attached) in LV8.6 I get this INI file:

[TestSection]
TestKey=a,b

If I run the same VI in LabVIEW 2011 I get this:

[TestSection]
TestKey="a,b
"

This becomes a problem when I read the key back. 

This is not a difficult issue to fix, my main question is where would I find documentation on this change? I ran the compatibity analyzer tests, I looked through the upgrade notes but I did not find any reference to a change in behaviour in the Write Key.VI (which I assume is the VI that's changed). What other nuggets are there in this migration that I need to lookout for?

Neil.

[Ben]

---

@Neilo wrote:

I'm struggling with a related issue in LabVIEW 2011. I'm migrating an application from LabVIEW 8.6 to LabVIEW 2011. Running my test VI (attached) in LV8.6 I get this INI file:

...

 What other nuggets are there in this migration that I need to lookout for?

Neil.

---

None that I know of.

Ben

[JÞB]

The rewrite of the config file API was the only block that ever caused me a headache.  You might bear in mind that Code Interface Nodes were depreciated if you use a lot of them.  The compiler rewrite might cause some surprises when your code starts working with more optomized performance.

[Michael.Proctor]

---

@Ben wrote:

---

@Neilo wrote:

I'm struggling with a related issue in LabVIEW 2011. I'm migrating an application from LabVIEW 8.6 to LabVIEW 2011. Running my test VI (attached) in LV8.6 I get this INI file:

...

 What other nuggets are there in this migration that I need to lookout for?

Neil.

---

You might get caught out with the In Range.vi

It can cause the calling vi to refuse to Save and or Compile if there is a type conversion on one of the inputs.

My memory is shaky on exactly what it was and the compiler error was not too much help.

The easist way to debug if there is a problme is to just to Disable that section of code and see if it saves.

Michael