Help with folder change library call

[iyeager2012]

I'm attempting to create a labview function that waits on notification of a change in a folder, specifically a new file to be created. I'm trying to use the FindFirstChangeNotification, referenced here; http://msdn.microsoft.com/en-us/library/windows/desktop/aa364417(v=vs.85).aspx 

I've attached the .vi I'm having trouble with where I get the notification handle. It returns error 1097 when run. Any ideas?

-Ian

[iyeager2012 · Accepted solution]

Nevermind, just went with the .NET implementation. 

-Ian

[Bublina]

Your second example (solution) caused my labview to crash 🙂

You have it configured wrong.

You must configure the call as WinAPI (you call WinAPI) function.

You must configure the parameters compliant to the calling function. Look at the return type, it is a Handle and handle is defined as :

HANDLE

A handle to an object.

This type is declared in WinNT.h as follows:

typedef PVOID HANDLE;

I didnt check the rest.

Another thing is, you would have to call WaitForSingleObject (dunno the name proper) again from the call library node and pass it the handle parameter,

where the code would hang until you make the change to the folder/file you specified or timed out.

I am not sure, if you can manage calling these functions straight from labview without any labview-friendly DLL wrapping.

[iyeager2012]

The second .vi caused Labview to hang or crash? It will give the appearance of hanging. It waits until notification of a change in the given path before taking any action. The end result will run as a service, so sitting there, doing nothing will be the bulk of it's responsabilities. I only ask because I've tested it on 32-bit and 64-bit 7 and XP machines without any issues yet.

Any idea on how to configure Labview to provide a Handle type for a library call? 

[nathand]

---

iyeager2012 wrote:

Any idea on how to configure Labview to provide a Handle type for a library call? 

---

A Handle is a pointer type, so configure the type as a pointer-sized integer.

[iyeager2012]

Success. Now, since they both work, any thoughts on why one would be better than the other? The .NET method only requires one call to start waiting. The COMS object requires one call to get a ref and a second to wait, however, I'm a pretty firm believer that at the speeds these calls are executing, the difference overall is negligable.

Thoughts?

-Ian

[Bublina]

I meant Labview hanged when opening the example 🙂

I would use the .NET version, if you intend to use it on w7 or w8. You can call standard VIs to close the reference (you might need to close the notification object if you use the DLL version).

You might need to do extra .NET installation on older XP.

[Bublina]

---

@nathand wrote:

---

iyeager2012 wrote:

Any idea on how to configure Labview to provide a Handle type for a library call? 

---

A Handle is a pointer type, so configure the type as a pointer-sized integer.

---

That is great, I never noticed I can get back pointer like this, I allways changed the datatype of all returning pointers with (int)

[rolfk]

(U)Int32 was fine before there existed Windows 64 Bit and will still work if you call the VI only under LabVIEW for Windows 32 Bit (even if it runs on Windows 64 Bit). Also before LabVIEW 8.6 or so, there was no pointer sized integer datatype in the Call Library Node.

For maximum portability for the VIs to run on both Windows 32 and Windows 64 versions (and possibly other upcoming 64 Bit versions of LabVIEW, although obviously not an issue when calling WinAPI functions) you should however always use pointer sized integer datatype for any data pointer that you want to pass as a scalar number (instead of an array or string pointer). Since a Windows HANDLE is defined to be a pointer (usually to Windows private data) the pointer sized integer datatype is the correct datatype to chose, if you only want the VI to work in LabVIEW 8.6 and above.

[rolfk]

---

@iyeager2012 wrote:

I'm attempting to create a labview function that waits on notification of a change in a folder, specifically a new file to be created. I'm trying to use the FindFirstChangeNotification, referenced here; http://msdn.microsoft.com/en-us/library/windows/desktop/aa364417(v=vs.85).aspx 

I've attached the .vi I'm having trouble with where I get the notification handle. It returns error 1097 when run. Any ideas?

-Ian

---

The WinAPI solution you provided has just about all things configured wrongly in the Call Library Node. This version should be correct for both LabVIEW 32 Bit and 64 Bit and also provides the additional calls to be functional. It is not a perfect implementation if you want to wait repeatetly on the same event as there, one should not call FindFirstChangeNotification() each time but instead use FindNextChangeNotification() on subsequent calls. Also for a truely reusable library the creation of the handle, the subsequent reinitialization, and the waiting on the handle should probably be put in their own VI functions each. But it gives at least a correct Call Library Node configuration for the function calls involved.

 One caveat with this VI. It will block the LabVIEW thread in which it is called for the duration of the timeout (indefinitely with the default value that is in the VI) and LabVIEW can not be stopped in this situation, not even with the Abort button, since LabVIEW does not allow to reset a threads state when it is in external code. The only solution to get out of this state is killing the LabVIEW process (usually with the Task Manager) or forcing a change on the directory according to the configured change filter.