call library function node: malloc to recieve a struct
in [LabView]
|
Prev: error 200279
Next: CMD.EXE Output Not Showing up
From: lmd2 on 10 Jul 2008 17:10 ok, spoke to NI - if I understand this now, the CLFN will call my wrapper DLL, which will access the clients function internally, LabVIEW will not call the clients function through a CLFN ever. Glad someone finally said that it clears up a number of misconceptions.So nothing gets 'wired'. But even internally I need to supply some input to the clients function (textually). Since we want to do the real action on the block diagram would this be a call to a dummy function that simply returns a status? Can that dummy function be part of the same DLL or should it be external? Starting to make sense, let me think on this a little more
From: rolfk on 11 Jul 2008 02:10 lmd2 wrote:ok, spoke to NI - if I understand this now, the CLFN will call my wrapper DLL, which will access the clients function internally, LabVIEW will not call the clients function through a CLFN ever. Glad someone finally said that it clears up a number of misconceptions.So nothing gets 'wired'. But even internally I need to supply some input to the clients function (textually). Since we want to do the real action on the block diagram would this be a call to a dummy function that simply returns a status? Can that dummy function be part of the same DLL or should it be external?Starting to make sense, let me think on this a little moreWell I assumed that this would be made clear by the userevent.zip file that you found in my post earlier on. This is basically more similar to what you try to do than the NI example you found in your previous post.So lets look at the file from my userevent.zip. It's not very useful in terms of what it does since you can do the same with a notifier in LabVIEW much easier but quite educating in how it does it.RegisterUserEvent(LVUserEventRef *value, int32 delay) is the exported function that gets called by the LabVIEW CLFN to register (and unregister) the callback. This function calls eventually timeSetEvent() a Windows API that installs a callback function to be called periodically. The callback function is OneShotTimer() implemented in that file too.Basically timeSetEvent() would be where you would principially call the register callback function from the API you want to control and OneShotTimer() would be the callback function that API would expect, of course adapted to the prototype of the required callback function.I hope this clears up some of the confusion you may still have.Rolf KalbermatterMessage Edited by rolfk on 07-11-2008 07:47 AM
From: lmd2 on 14 Jul 2008 09:40 Hi Rolf conceptually I think I am finally getting this (nice when the light finally comes on) I am working on the mechanics, bit of a learning curve but I am finding examples, I'll get it. A question on architecture, or organization - I am going to need two functions to handle the wrapping of "the pointer to a function" (in one of the client's functions) and one or two to handle the earlier issue of "pointer to a pointer" and maybe others as I continue working on this driver project - Is it considered good practice to have a single DLL containing all of these pairs of functions? thanx for all your help; and your patience - lmd2
From: rolfk on 14 Jul 2008 09:40
lmd2 wrote: Hi Rolf conceptually I think I am finally getting this (nice when the light finally comes on) I am working on the mechanics, bit of a learning curve but I am finding examples, I'll get it. A question on architecture, or organization - I am going to need two functions to handle the wrapping of "the pointer to a function" (in one of the client's functions) and one or two to handle the earlier issue of "pointer to a pointer" and maybe others as I continue working on this driver project - Is it considered good practice to have a single DLL containing all of these pairs of functions?thanx for all your help; and your patience - lmd2Definitly! It will make maintianing that project much more easy. It would be a different story when you would support two rather different drivers. While you could still put everything in one file it may be more sensible to keep a differetn DLL for each driver type, eventhough if that might mean copying some functionality, but it is all a question of good sense, your own preferences and some "Fingerspitzengef�hl". Rolf Kalbermatter |