Why property loader is so fragile?

[MimiKLM]

Hi,

Having worked with property loader I realised that it doesn't behave stable. It is very fragile for any format change and sometimes I have problems with loading values.

Usually when I have problems with the format Im using the export/import tool. It always works. However, for each day living the fragility of the property loader is a big problem. For example, when I have problem with loading the file I'm generating the proper format using import/export tool which I've just mentioned. However when I want to change on number i.e.. Low limit let say from 950 to 1145 in this file, after applying the change import is not successful. So, what I'm doing is I'm updated hardcoding values in the sequence, exporting to the text (tab delimited tab) file and then this file could be imported successfully.

Of course this method is good as a quick fix. However I understand that whole idea of keeping the figures externally is the easy possibility to manipulate them outside the sequence. Using import/export toll continuously is senseless. So what is the solution?

To investigate this problem I was trying to edit the text files in notepad in gVIm. I was expecting to see a kind of hidden characters using gVIm but I didn't. The file created by export function is identical (in format) as the same file with one figure modification only.

What's wrong? What make them distinguish for enabling to import?

K

[Norbert_B]

K,

i did not manage to reproduce this neither with notepad, wordpad nor VIM. Since this is the first time i hear about this "fragility", i am wondering:

How does the following files look like:

- The Sequence File (including the property loader step)

- The Limitfiles (original export from the tool and your modified version)

What version of TS are you using? What OS are you using?

thanks,

Norbert

[MimiKLM]

Hi,

WinXP 32bit Prof, TS.4.2, LV 8.6.1

K,

[Norbert_B]

K,

could you please post an example sequence file and limitfiles?

thanks,

Norbert

[RayFarmer]

Hi,

Just to follow up Norbert's request, can you post an example limit file that you have create using the Export/Import tool and one that you have changed (which hightlights the problem).

[MimiKLM]

Just a moment gents. I'll post it today.

[MimiKLM]

I'm very sorry everyone but I couldn't reporoduce theproblem on the sequence I want to send.

I STILL have an issue however I cannot post my sequence to public forum.

I'll post an example as soon as I can reporoduce the problem.

[Norbert_B]

You tell us that you cannot post your sources on a public forum. That's fine, but if you have problems at creation of a simple example which shows the issue, it is an indication that the issue is connected to your (rather special) sources.

Therefore i suggest you to contact your local NI office and send them your sources (this is no public access then). So if you are not under NDA, this could help you some steps further.

I hope you understand now our surprise about your message: Property loader is (by default) fragile.... since experience tells at least me: it isn't. It's very stable.

Norbert

[dug9000]

The problem might be that you are editing the file with Excel or some other editor that is stripping out characters that the property loader requires such as quote characters. If you edit the file in a text editor you will probably not see the problem.

Hope this helps,

-Doug

[MimiKLM]

Hi All,

No Doug it's not that.

Frankly speaking I'm rather tempted to keep everything in Excel file because it looks much structured than flat txt file.

For sure it's not a problem with missing character or something. I've checked it using a few text editors including gVim. The txt lie structure is correct.

I came across a few occurrences when limits from the text file were not been applied and error has not been thrown. Unfortunately, I cannot post the genuine sequence itself straight away. I have to cut it off and then try to reproduce the problem.

Basically, I have two examples when it was happen and I post them as soon as possible.