LabView - unable to permanently change string value, what can be the reasons? - controls

I received an abandoned student LabView project I need to adapt. There is one VI which contains an array of two controls with length 30. I need to change the strings in several places within that array which is possible as long as I do not close the vi. If I close and reload the vi the previous values are there again, saving the changed values as default does not help. Cutting the connection to the type def did not help either.
There is also no databinding and I could not find any mechanism that might lock the values. It must be something obvious to experienced LabView developers, but I could not find anything on the net.
What can be the reason that the values cannot be changed permanently?
Edit:
After playing around for a long time, i found out that I have to set as default value on the array, and not on the individual positions in the array. That solved it, simple problem, several hours spent...

After playing around for a long time, i found out that I have to set as default value on the array, and not on the individual positions in the array. That solved it, simple problem, several hours spent...

Related

How many PathItem's in a PathItems Collection

It seems that a PathItems collection cannot hold more than 998 PathItem's.
I am using:
var myPathItem = docRef.pathItems.add(NewPixel, lineSubPathArray);
where variable NewPixel varies from 1 to 999. But when it gets to 999 I get a notification saying that Photoshop might not support the function, while it has already done 998 iterations.
It says at the bottom of the ExtendScript Toolkit:
"General Photoshop error occurred. This functionality may not be available in this version of Photoshop".
What am I missing. Thank you. Stefania
Thank you for your interest.
Problem solved. What I did was close the document (not the script), reopen it and repeat with different offsets applied to the iterations counter. Not a very elegant solution but it worked consistently, and I must be pragmatic. Breaks my heart from the point of view of clean coding but it worked.
Thank you,

How to log LREAL values to file?

I'm new to PLC programming and I'm trying to keep track of an LREAL variable in some existing structured-text code. I'm using Omron's CX-Programmer with a simulated CJ2M.
My first instinct was to log all changes in value to SD card, using WRITE_TEXT() . Since I need a string value to write, I had hoped that LREAL_TO_STRING() would do the trick, but it appears that function does not exist.
How could I best log that value without losing precision?
Edit: I managed to work around this problem. Having been told CX-Programmer's SD card emulation could be unreliable, I simply wrote the values to an array and examined the contents of those memory locations with the built in tools. I could also export these values into a file if needed. This approach limits the amount of recorded data to available space in the simulated PLC memory.
In CXP you can't convert real into a string. You have to do the conversion yourself.
If you want to know if you can do any other conversion you can follow the table here.

Fill out video file attributes

I have a large collection of video files, which have missing atributes like length, resolution, bitrate etc. I would like to fill those out somehow but im not sure what solution to use. It would take ages by hand but i'd rather see if a program can do it first. I tried searching for a solution but didnt find anything substantial.
The reason why, is becuase im trying to filter out the videos by atributes. If a vid is shorter than 30 minutes, i delete it. Can sort with the windows explorer, which cant do that if the atributes are missing.
Since you asked this on StackOverflow and not on SuperUser I'm going to answer this as a programming question.
Those properties are provided by the Windows Property System. It is possible to write your own property provider and overwrite the system default provider registration but this is a fair amount of work if all you want to do is sort some files.

Core Data / NSTextView breaks only after save

We have an NSTextView and some data saved about its contents in a core data Managed object context. Everything works great while the managed object context stays in memory. However when we save it, we get very weird fetch request behaviors.
For example, we run a fetch request that asks for all elements with a textLocation less than or equal to 15. The first object in the array we get back has a textLocation of 16.
I know I can't get a definitive answer here, as the code is fairly complex. But does anyone know what this issue smells of?
My thought is that we are somehow not getting the proper MOC synced with the NSTextView after saving? What could change that breaks this?
Thanks.
For example, we run a fetch request
that asks for all elements with a
textLocation less than or equal to 15.
The first object in the array we get
back has a textLocation of 16.
Really, the only way to get that is to (in reverse order of likelihood):
Mess up ethe definition of the attribute such that you think your are saving one type of numerical info but that you are actually saving another.
You've mangled the predicate so that it actually looks for values of 16 or greater. (You can test predicates against an array of dictionaries whose keys have the same names as you Core Data entities.)
It's an error in the conversion between a number and a string for purposes of displaying in the UI or logging.
I would start with (3) myself because it seems more common and until you confirm you don't have a display problem, you can't diagnose the other problems.
I finally managed to work out what was going on. I was setting textLocation using the setPrimitiveValue... just because I didn't want notifications to fire off. Turns out that's a really bad idea, because Core Data didn't know the value had changed. It still thought the value was 15 instead of 16.
Let this be a lesson: never bypass KVO unless you're INSIDE the managed object and you know what you're doing!

Is RegNotifyChangeKeyValue as coarse as it seems?

I've been using ReadDirectoryChangesW to monitor a particular portion of the file system. It rather nicely provides a partial pathname to the file or directory which changed along with a clue about the nature of the change. This may have spoiled me.
I also need to monitor a particular portion of the registry, but it looks as if RegNotifyChangeKeyValue is very coarse. It will tell me that something under the given key changed, but it doesn't seem to want to tell me what that something might have been. Bummer!
The portion of the registry in question is arbitrarily deep, so enumerating all the sub-keys and calling RegNotifyChangeKeyValue for each probably isn't a hot idea because I'll eventually end up having to overcome MAXIMUM_WAIT_OBJECTS. Plus I'd have to adjust the set of keys I'd passed to RegNotifyChangeKeyValue, which would be a fair amount of effort to do without enumerating the sub-keys every time, which would defeat a fair amount of the purpose.
Any ideas?
Unfortunately, yes. You probably have to cache all the values of interest to your code, and update this cache yourself whenever you get a change trigger, or else set up multiple watchers, one on each of the individual data items of interest. As you noted the second solution gets unwieldy very quickly.
If you can implement the required code in .Net you can get the same effect more elegantly via RegistryEvent and its subclasses.

Resources