Case in Preference Files?

[sth]

I know that you can add all sorts of options to the preferences file.

That on the Mac you can use either Mac/Unix/DOS line endings

That on the Mac you can use either colon (":") or the traditional equals ("=") to separate your keyword and value.

BUT does the case of the keyword matter? Can I get the same behavior for
dWarnDialog=True
as for
DWarnDialog : True

Anyone know?

[smercurio_fc]

It is not case sensitive. It should return the first match:

[sth]

Right, but does LabVIEW itself use that same algorithm?  Soon the ultimate goal will be that the LabVIEW IDE will be written entirely in LV itself! 🙂

Until then, it is still an open question.   I can do the simple test of the LV config file VIs, but I need NI to verify that LV uses the case independent preference files.  I am assuming it does now, but getting that confirmed was the goal.

Mucking around with the LV preference file is not really sanctioned by NI yet is encouraged in the forums and elsewhere.  Thus clarifying this "feature" is important. 

[tst]

I don't know what the answer is, but I'm guessing you can a do a quick test with a couple of lines which are only likely to be used in the C code. That won't give you a definitive "yes", but you should be able to at least get some sort of idea.

By the way, some platforms have always been case insensitive and the developers working on them expect all apps to work like that...

Sorry, I couldn't help myself.

[smercurio_fc]

---

sth wrote:

Right, but does LabVIEW itself use that same algorithm?  Soon the ultimate goal will be that the LabVIEW IDE will be written entirely in LV itself! 🙂

---

Well, I sincerely doubt the latter will actually ever happen, but I gather you're probably saying that tongue-in-cheek. As for the former, I don't have an answer either. I can tell you that on Windows, the Windows API function GetPrivateProfileString is used to fetch a key, and it is not case-sensitive. Now, I can't tell you if LabVIEW is written to use that function.

[sth]

---

tst wrote:

By the way, some platforms have always been case insensitive and the developers working on them expect all apps to work like that...

Sorry, I couldn't help myself.

---

Wait...  Which platform?  What?  What platform does case insensitive string matching all the time?

I know that the Mac file system is case insensitive but case preserving and it drives me NUTS!!  That Un*x background just comes through and I am used to case sensitivity as in C programming.

And for windows is the file system case preserving?   Is it case sensitive?  Anyway preferences can be completely different since it is keyword matching.  What string function do the LV programming gnomes use?

Stay tuned.  I'll go mess with the Blink keyword and see what happens....

[sth]

Yes, it is case insensitive in reading keywords.  So it will accept Blinkspeed instead of the canonical blinkSpeed and read the value.  If you change the blink speed in the preferences the file will revert to the default blinkSpeed.  If you just open the preferences and do not change it, it will preserve the case as entered.

Thus it is case insensitive but case restoring.

I'll stop obsessing about the capitalization of the dWarn type dialog flags to get debugging info. 

For the config file VIs the documentation should mention that it finds the *first* key that matches in a case insensitive fashion.   The same is for sections.  This is a documentation problem and it would be nice if it got fixed rather than someone trying to find this forum thread.   The documentation for "read key" should have this info at either the top level or in the description of the section and key parameters but that would be duplication for each polymorphic type.  If you look in these VIs it is obvious that keys and sections are converted to lower case before checking for a match.

Weirdness alert:  an odd thing, is that when it searches the cache (in Config Data Registry.vi) it uses the raw input section name, but then maps it to lower case before searching for the entire array.  Thus if you are repeatedly looking in the same section you can have a speed up by entering your section in lower case.  I think it caches the current section in lower case!!  So the cache check is case sensitive and the final search is case insensitive.

Maybe that should be fixed as well as the documentation and assigned a separate CAR?.....

[tst]

Well, I was just doing a tounge-in-cheek comment. In Windows, the file system has always been case insensitive (which is perfectly logical. I think being case sensitive may have been useful for giving the compiler a small diet and saving some CPU cycles in the 70's, but is pretty stupid these days) and case preserving. A quick search seems to indicate you can set it to being case sensitive to support Unix interop.

[sth]

Yair,

See, I am not bi-lingual enough to have gotten the tounge-in-cheek aspect!!  In DOS days the file system was case insensitive and did not preserve case so everything was in CAPS.  I assume windows has progressed from that and is now like the Mac OS.  Case of a file name is whatever I enter it as, but the system will access the file no matter what case I use when I open it.  Thus the directory records the case but does all file operations independent of that.

The Mac Heirarchical File System+ can be set to be case sensitive, but that can lead to unexpected behavior that is usually "not good"!   So in this case the Mac/Windows question is that they are the same!

It is a bit difficult for old unixy types to get used to case insensitivity, I don't see one as more logical than another but just different.  I know as an american I am supposed to believe that there is only one moral answer to the question of case sensitivity but it may just be my moral relativism showing through.  🙂