Bug in Class data member accessor with return in name

[wideofthemark]

Noticed a little bug in the class data member accessor creation.

If you have a carridge return in the variable title the vi it creates won't save.

[SteveChandler]

By variable title do you mean the name of the assessor? The filename cannot have a carriage return. It's an OS limitation. Or am I misunderstanding you?

[wideofthemark]

I think you understand perfectly.  FileNames can't have returns in them, but variables in labview can - so that if you use the data access templates to create your class accessors they seem to copy the returns across to the accessors names - but when you try to save them it fails.  Rather annoying, and took me quite some time to work out what was going on - because labview wasn't giving any decent error messages - just refusing to save. 

I was mostly just putting it up in case someone else has the same problems.

[Ben]

---

@wideofthemark wrote:

I think you understand perfectly.  FileNames can't have returns in them, but variables in labview can - so that if you use the data access templates to create your class accessors they seem to copy the returns across to the accessors names - but when you try to save them it fails.  Rather annoying, and took me quite some time to work out what was going on - because labview wasn't giving any decent error messages - just refusing to save. 

I was mostly just putting it up in case someone else has the same problems.

---

Interesting corner case you found there. I never put CRs in my varialbe names so I nevr saw that issue.

Concidering the options, I suspect LV will have to add a special warning.

I wonder how trailing spaces in the names would behave?

Ben

[wideofthemark]

Yes,

I guess that in general it's a bad idea to have carridge returns in variables - it certainly screws things up on FPGA vis as well - but sometimes I get carried away with trying to make the front panels look pretty!

[SteveChandler]

I always keep control names short yet descriptive. The name is not always the best thing from a users perspective. For the front panel it is best to show the caption instead. Plus the caption is writable at runtime.

[wideofthemark]

Yeah, I (grudgingly) see what you mean - though short but descriptive is a bit of a dichotomy.  Using captions is a way around it - but I guess that having two sets of names for things doubles the amount of things that need to be set.  I guess that i like the idea of being clear that the name i see at the front is the name i see at the back - avoiding confusion is good!

[SteveChandler · Accepted solution]

You don't have to set two things for every control. By default if you show the caption it is the same as the lable. You only need to modify it and then only for those on the FP.

[wideofthemark]

Fair point.

[Ben]

I still sense a bug that should be CAR'd here. At the very least, LV should give a clear explanation why the creation of the accessor failed.

Ben