DLL calling convention

I wonder what calling convention I should select at the call library node for these 2 cases of DLL
if my functions in the DLL are declared as follow;
1. extern "C" void PASCAL EXPORT my_function()
2. void __declspec(dllexport) my_function2()
thanks

The first one uses the obsolete type PASCAL. This has been mapped to __stdcall so that is what you should put in your Call Library Node.
The second one doesn't declare an explicit calling convention so I have to make some assumptions:
1. This is not a member fuction of a C++ class.
2. You haven't defined an explicity calling convension in the compiler (such as /Gz or /Gr).
In that case, it defaults to __cdecl.
Brian Tyler
http://detritus.blogs.com/lycangeek

Similar Messages

  • RoboHelp for Word Version 8-Run-time error 49-Bad DLL calling convention

    I just installed the trial version of RH8. I have RH5 installed. I also have Word97 installed. When I start RH8, the RH Explorer pane opens, but when it tries to open Word, the following error message appears: "Microsoft Visual Basic - Run-time error '49'. Bad DLL calling convention." Any ideas on what I can do to fix this problem?

    See Snippets on my site.
    See www.grainge.org for RoboHelp and Authoring tips
    Follow me @petergrainge

  • VB Error  - Runtime error '49' Bad DLL  calling convention

    Hi Experts,
    When User is running report he is getting error VB Error  - Runtime error '49' Bad DLL  calling convention .
    Can you please suggest how to resolve this issue?
    User has already tried uninstalling SAP GUI and installing again.
    Thanks & Regards
    Deepak Chavan.

    Hi Deepak,
    this doesnt appear to be an SAP error.
    I did a Google search on the error & got lots of hits, including:
    http://www.bigresource.com/VB-WindowFromPoint-Bad-DLL-calling-convention-run-time-error-49--G1wKaVeqwY.html
    Its a Microsoft Visual Basic programming error code.
    Rgds,
    Colum

  • Bad DLL Calling Convention

    Hi,
    I've created a dll with LV8.6 and I'm trying to call it from VB6.0.  I get the message 'Bad Dll Calling Convention.  Run Time Error '49'.
    Questions:
    1.  Any idea what might cause this error?
    2.  What is the meanig of the second function appear inh the h file ( long __cdecl LVDLLStatus(char *errStr, int errStrLen, void *module)
    Thanks very much for your help
    Rafi
    The dll definition as appear in the h file:
         void __stdcall EDASAnalysis(double f_sampleMHz, char FilePathFromOut[],
             double *RMSValue, double *AmplitudePP);
         long __cdecl LVDLLStatus(char *errStr, int errStrLen, void *module);
    The Decleration in Visual Basic 6.0:
         Declare Sub EDASAnalysis Lib "D:\NI Projects\eDAS400\DLL\ LV-DLL_V2\DLL\eDAS400_Analysis.dll" _
                (ByVal f_sampleMHz As Long, ByVal FilePath As String, RMSValue As Long, AmplitudePP As Long)
    Using the Function in VB6.0:
        Call EDASAnalysis(10, "D:\NI Projects\eDAS400\Data Files\Samples\10MHz.txt", rms, pp)

    Rafi2003 wrote:
    Hi,
    I've created a dll with LV8.6 and I'm trying to call it from VB6.0.  I get the message 'Bad Dll Calling Convention.  Run Time Error '49'.
    Questions:
    1.  Any idea what might cause this error?
    2.  What is the meanig of the second function appear inh the h file ( long __cdecl LVDLLStatus(char *errStr, int errStrLen, void *module)
    Thanks very much for your help
    Rafi
    The dll definition as appear in the h file:
         void __stdcall EDASAnalysis(double f_sampleMHz, char FilePathFromOut[],
             double *RMSValue, double *AmplitudePP);
         long __cdecl LVDLLStatus(char *errStr, int errStrLen, void *module);
    The Decleration in Visual Basic 6.0:
         Declare Sub EDASAnalysis Lib "D:\NI Projects\eDAS400\DLL\ LV-DLL_V2\DLL\eDAS400_Analysis.dll" _
                (ByVal f_sampleMHz As Long, ByVal FilePath As String, RMSValue As Long, AmplitudePP As Long)
    Using the Function in VB6.0:
        Call EDASAnalysis(10, "D:\NI Projects\eDAS400\Data Files\Samples\10MHz.txt", rms, pp)
    muks already pointed you to a discussion that shows the problem. VB can not call cdecl exported functions, so when you create your DLL you'll have to tell LabVIEW to use the stdcall calling convention to export the function for VB.
    Rolf Kalbermatter
    CIT Engineering Netherlands
    a division of Test & Measurement Solutions

  • DLL Calling Conventions, Need Help

    Hey everyone,
    need some help here...
    How do I setup the 'call library function node' for a function in a dll which is called as such:
    (in C)  bool get_dxdy_pos (signed short * pDXManual, signed short * pDYManual);
    I'm not sure how I pass a pointer in labview, and as for the bool return I can just use an unsigned short int right?
    Thanks

    Hi IEC,
    As attachement you will find how the setup should be in LabVIEW, hope this helps
    Christian
    Attachments:
    Call Library Function.jpg ‏38 KB

  • WEBUTIL_C_API: Writing wrapper DLL's to address calling convention issues

    I am interested in calling the Windows API using WEBUTIL_C_API. In particularly, I am interested in calling FindWindow to obtain window handles. I registered the function as required, but have yet to get a meaningful result. Upon researching Metalink a bit, I encountered a post stating that FindWindow uses Pascal calling conventions, while WEBUTIL_C_API expects C calling conventions. The suggested solution is to wrap the API call in my own DLL, which adapts between the two calling conventions.
    I'm fairly adept at writing standard C code, albeit out of practice, and with a bit of Googling, I have even managed to compile a DLL using GNU gcc. Alas, I evidently don't understand all the compiler directives required to write the wrapper DLL that I have described. Has anyone else managed a similar task, who might share an example or direct me to some helpful documentation?
    Thanks,
    Eric Adamson
    Lansing, Michigan

    Mr. Ronald,
    Thank you for your assistance. After going through the webutil log file and the WebUtil Familiarization Manual a few more times, and lastly, metalink, it was stated in a metalink post that the "Cause for the Error WUC-20 can be that the webutil.cfg file has an invalid virtual directory: install.syslib.location".
    According the WebUtil Familiarization Manual (p.11 of 49), install.syslib.location=/webutil. I did just that, and the log file indicated that
    xxx.xxx.xxx.xxx:xxxxxxx: 2004-Jan-22 11:32:53.746 WUI[setProperty()] Setting property WUC_GET_LOCAL_PROPERTY to syslib.ffisamp.dll
    xxx.xxx.xxx.xxx:xxxxxxx: 2004-Jan-22 11:32:53.761 WUI[getProperty()] Getting property WUC_GET_LOCAL_PROPERTY
    xxx.xxx.xxx.xxx:xxxxxxx: 2004-Jan-22 11:32:53.761 WUI[loadSettings()] No local properties file to load
    xxx.xxx.xxx.xxx:xxxxxxx: 2004-Jan-22 11:32:53.761 WUI[getProperty()] Value of WUC_GET_LOCAL_PROPERTY=null
    xxx.xxx.xxx.xxx:xxxxxxx: 2004-Jan-22 11:32:53.777 WUI[setProperty()] Setting property WUC_URL_DOWNLOAD to 1|40960|Y|/webutil/ffisamp.dll|ffisamp.dll|WebUtil Install|Downloading required libraries; Please wait...|ffisamp.dll
    xxx.xxx.xxx.xxx:xxxxxxx: 2004-Jan-22 11:32:53.777 WUI[getProperty()] Getting property WUC_URL_DOWNLOAD
    xxx.xxx.xxx.xxx:xxxxxxx: 2004-Jan-22 11:32:53.777 WUI[downloadFromURL()] Source is http://<machine_name:port>/forms90/f90servlet/webutil/ffisamp.dll
    So I tried the absolute URL, http://<machine_name:port>/forms90/webutil, Voila! It worked. The point is somehow, the download url should not include .../f90servlet/...; just plain /forms90/webutil.
    Thank you for your time and assistance.
    Regards,
    thomas

  • How to build a DLL that has Pascal calling conventions with application builder?

    Hi,
    I'm researching for possible solution to one of our problems.
    In one case, solution would be to build a DLL from LabView
    code. This should be simple task, but the application that
    is going to load the DLL requires that the functions in the
    library are exported using Pascal calling conventions,
    similar to the C/C++ example code below.
    DWORD APPEXPORT far APPPASCAL function(char hexr[])
    Could this be possible with LabView somehow? Or is it best just
    to write the DLL with C/C++?
    Thanks.

    Thanks Wiebe.
    I don't know whether I need pass string pointers or not. The example
    I posted was from the manual of the program that will be using the DLL
    I build with LabView. I only wanted to show with it the exported calling
    convention needed. It seems that it actually confused my question rather
    than clearing it.
    Anyway, now I know that it's possible to declare the calling convention
    when building the DLL. And it's always good to know that I might encounter
    different pointer types on the way, this may actually save me from a lot of
    debugging some day.

  • Error Code 1097 Coming in DLL Calling

    Hi,
    I am getting error code 1097 in DLL calling function. Please find the DLL calling function details for more information.
    Function :  GetControllerListTest(controller *ptrControllertest,char *max_controller);
    Controllertest parameter details:
    define NO_OF_CONTROLLER  100
    #ifndef CONTROLLER_STRUCT
     typedef struct
      CString name;
      char status;
      CString blocked_by;
      char group;
     }controller;
    Controllertest parameter data type is structure. In LabVIEW, I have configured parameter as a cluster.
    name : String control
    status : U8 Integer control
    blocked_by : String control
    group : U8 Integer control
    Could you please confirm it, did I configured the datatype in correct way?
    I am getting empty array output and Error Code from the DLL 1097. Can you please tell me where I am missing?
    Thanks
    Sivaramkumar.V
    Solved!
    Go to Solution.

    Call Library Node problems without the VI in question attached AND the complete C prototype of the function provided, AND preferably some documentation about the C function in question can be not diagnosed. These informations are paramount to get the Call Library Node configured properly since there is no way a calling application can retrieve the necessary information from the DLL itself. The DLL interface was never intended to be a self configuring interface and it was designed with the understanding, that the user of such an interface is a fully knowledgeable C programmer knowing both, how to read a header file definition as well as various details about memory buffer handling.
    So show us your VI and the C header file, and we can start to help you. Otherwise all we can do is guessing in the way you have done with changing the calling convention randomly. You can of course try to shoot in the shooting range with a blindfold on, but the chances that you not only do not hit the target, but injure some other person instead is very high.
    The only reason that the suggestion from Fragger Fox has any merits is the fact that LabVIEW used to have some heuristics that changed the Call Library Node automatically from C calling convention (the LabVIEW default) to Windows calling convention, if it recognized a certain pattern in the exported function name. This heuristic was removed in LabVIEW 2009 because it did prevent the Call Library Node to be able to call functions that were using C calling convention but happened to match the heuristic pattern. So changing a Windows calling convention to C calling convention when the code has "seemed" to work before is NEVER a solution.
    Rolf Kalbermatter
    CIT Engineering Netherlands
    a division of Test & Measurement Solutions

  • FTDI FT4222.DLL calling

    I am attempting to use the FTDI FT42222 usb to SPI/I2C/GPIO chip with LabVIEW.
    FTDI provides two dll's that talk to the chip. After some trial and error, it appears that one dll uses the C calling convention, the other uses winapi convention. FTd2xx.dll and FT4222.dll are provided by FTDI. FTD2xx.dll are the generic USB open device calls and FT4222.dll are the FT4222 specific support.
    With that figured out, I was able to successfully communicate via I2C.
    Having that, I now would like to use the remaining GPIO pins, one for input, one for output.
    So I started and can initialize the port with no errors returned. But, reading or writing to the pins returns an error.
    I think it might be the way I'm calling the following:
    LIBFT4222_API FT4222_STATUS FT4222_GPIO_Init(FT_HANDLE ftHandle, GPIO_Dir gpioDir[4]);
    LIBFT4222_API FT4222_STATUS FT4222_GPIO_Write(FT_HANDLE ftHandle, GPIO_Port portNum, BOOL bValue);
    Their docs show:
    xx_STATUS       DWORD
    FT_HANDLE    DWORD
    GPIO_DIR        enum
    GPIO_Port        enum
    BOOL                unsigned char
    So, I used the following in my library function node:
    xx_STATUS        Numeric, Unsigned 32-bit Integer
    FT_HANDLE     Numeric, Unsigned 32-bit Integer, Pass:Value
    gpioDir[4]           Array, Unsigned 32-bit Integer, Array Data Pointer
                                  (Here I pass in a 4 element U32)
    portNum            Numeric, Unsigned 32-bit Integer, Pass:Value
    bValue                Numeric, Unsigned 8-bit Integer, Pass:Value
    I'm thinking since all works well for the I2C communication, that I've gotten the STATUS and HANDLE definitions correct.
    Am I right in assuming the bools end up 8 bit integers and enums will end up being unsigned 32-bit?
    Do I need to use the old trick using a cluster with the first element the array size to pass the gpioDir array?

    I guess it's not clear from what I posted, but their docs show gpioDir as an array:
    I have since got it working and each of the 4 elements of the array controls the direction of one of the 4 I/O pins.
    It turns out to get the GPIO pins to work as GPIO in Mode 0 of the chip, you need to de-assign the default functions of the pins. In Mode 0, pins 0 & 1 are I2C SDA & SCL and pins 2 & 3 are wake and suspend. De-assigning wake and suspend allows GPIO control of pins 2 & 3, while I2C is still functional on pins 0 & 1.
    Regards,
    Mac

  • Labview Crashes after DLL call

    HI All,
    I am working on to write a wrapper to a dll. The call to dll works fine an returns appropriate values but as soon as i close the VI the LabVIEW dev environment crashes. Any help on avoiding the same. I went through a lot of posts and tried varing the types of data being sent to the dll but still it gets crashed.
    the dll function I am using is of the prototype(with C type call convention)
    int functionName(Struct *cfg, UCHAR dNumber, UCHAR hTYPE)
    The UCHAR varables I am passing as Unsigned 8-bit Integers.
    For the structure I have made a cluster and am passing with Adapt to Type and as Handles.
    The DLL executes fine and the VI stops too, but as soon as i try to close the VI the dev environment crashes. Please help.
    Thanks.
    Solved!
    Go to Solution.

    While nathand is right about possible other errors, the Struct that you fail to tell anything about is a big flag pole for something that might be going wrong. Show us the C header declaring the structure and function and attach the VI you created (please no BMP or other image! They do say a picture says more than thousend words, but in the case of a LabVIEW diagram a picture is not enough to show all aspects of a VI, especially things like how the Call Library Node is configured!)
    Rolf Kalbermatter
    CIT Engineering Netherlands
    a division of Test & Measurement Solutions

  • Intermittent problem with TestStand calling CVI DLL calling MSCV DLL

    Sorry about cross post, but I am not sure which group is best to address
    this issue.
    Setup:
    Windows 2000 SP1
    TestStand 2.01f
    CVI 6.0
    MSVC++ 6.0 SP5
    Problem:
    I have a CVI Test Library DLL that contains test functions called by
    TestStand using the C/CVI adapter. The CVI Test Library DLL in turn makes
    several calls to another DLL written in MSVC++. I am experiencing an
    intermittent problem with one of the MSVC functions. The problem ~appears~
    to be stack related, but I am not sure. Among other things, this MSVC
    function accepts a const char * argument that is a TestStand lookup string.
    The function uses this string to access the TestStand API.
    What happens is this: Everything works fine. I then recompile the CVI DLL
    after making some mod, then run. The MSVC++ DLL asserts that the const char
    * arg passed by the CVI DLL is NULL. However, this is not the case if I
    single step through the CVI code. It has happened both with passing
    variables as the const char * argument and as hardcoded strings literals, so
    its not that I am actually passing NULL. The other argument to this
    function is the TestStand sequence context dispatch pointer (LPDISPATCH
    pobjSequenceContextDisp) and it always ~appears~ to be passed correctly.
    The problem is frustrating and hard to debug because I can not
    deterministically reproduce it. The problem ~never~ appears when I debug my
    MSVC++ DLL in Visual Studio. And it only occasionally appears otherwise.
    The problem, when it appears, always appears on the first run after
    recompiling the CVI DLL, though the problem does not happen after ~every~
    recompilation. I'd say it happens 1 in 6 times after a recompile.
    Recompiling the exact same code does not always make the problem disappear.
    If I change the CVI code (code that has nothing to do with the argument
    itself though) and recompile the problem almost always goes away. Selecting
    'Mark all for compilation' and rebuilding does not make the problem go away.
    Only tweaking the CVI code and recompiling does (usually).
    Whats more, the problem appears:
    * With the CVI DLL built as Debug or Release mode.
    * With the CVI default calling convention set to __stdcall or __cdecl.
    * With the C/CVI TestStand adapter set to run in-process or external
    instance of CVI.
    The problem appears to be some sort of stack or argument passing problem
    between CVI and MSVC, though thats just a guess based on the symptoms. I
    have quadruple checked the calling conventions of all declared functions.
    The CVI DLL functions all use TX_TEST (which resolves to __cdecl). The MSVC
    DLL functions all explicitly use __stdcall. Is there a problem with calling
    __stdcall MSVC functions from a __cdecl CVI function?
    I can find no other memory leaks or indications of memory corruption
    elsewhere in either the CVI or MSVC DLLs. Its only this one function that
    exhibits this strange 'null const char *' problem.
    Can anyone offer any ideas about what may be causing this problem? Anything
    else I should check/verify?
    Regards,
    Joe

    Silvius,
    > Although I'm not sure if any of the following are the real cause of
    > your problem, I have the following suggestions:
    Thanks for the reply. At this point any and all suggestions are welcome...
    > 1. There could be a problem with calling
    > __stdcall MSVC functions from a __cdecl CVI function. As a workaround
    > wrap the _cdecl call inside a _stdcall call that is exposed or
    > exported to TestStand or vice-versa. This can be a problem because if
    > _cdecl is used, the calling function is responsible for cleaning up
    > the stack and if _stdcall is used, the called function is responsible
    > for cleaning up the stack.
    I was under the impression that as long as everything was explicitly and
    consistently declared, you could safely mix cdecl and stdcall f
    unction
    calls. Is it bad to do this? Is this a known issue with the CVI compiler?
    I've never seen a problem with doing this under MSVC++.
    I'll try wrapping them in cdecl calls for CVI - though we have a
    depressingly large number of stdcall functions in the MSVC DLL ;-). They
    need to remain stdcall in the DLL because we also call them from Visual
    Basic.
    > 2.Don't mix Debug version of one DLL with the Release version of the
    > other DLL. I had some bad experiences doing this and both DLLs where
    > developed in MSVC. Allways use either Debug either Release versions of
    > DLLs.
    I verified that the MSVC DLLs were either ALL Debug or Release. I too have
    seen nasty problems when MSVC Debug and Release is mixed.
    One thing I had not thought of until your reply: What about mixing CVI Debug
    DLLs with MSVC Release DLLs? Have you ever seen issues with doing this?
    Thanks!
    Joe

  • How is it possible to make sure that LV uses the same thread for several threadsafe DLL calls?

    Hello,
    i have a thread safe DLL and most functions are called from serveral threads from the LV apllication without problems.
    In case of an error i have to call an error handler function in this DLL (like WinAPI: GetLastError()) from the same thread which has called the function that failed before.
    I can't use the user interface execution because some functions need a long execution time and i don't want to balk the user interface.
    All other executions than the user interface execution have more than one thread and in most cases the DLL function calls were executed from different threads - so the error handling doesn't work...
    Any idea?
    Thanks for your help!

    Hmmm....
    How about wrapping all of your dll calls in a single VI (or an Action Engine ) and make sure the VI's thread is NOT set for "Same as caller".
    "Threadconfig.vi" (sp?) will also let you dictate the number of threads associated with an execution system. Set your target thread for "1".
    Not sure on the above.
    Please correct me if this is wrong!
    Ben
    Message Edited by Ben on 07-19-2007 08:26 AM
    Ben Rayner
    I am currently active on.. MainStream Preppers
    Rayner's Ridge is under construction

  • Private dll calling in Labview

    Hi everyone, (refinement of my question)
    I have two dlls. One contains public functions which I call from Labview. The functions in this dll call functions in the other (private) dll. However, how do I tell Labview where to find this private dll?
    I have tried installing the dll in the system path directory. I have also put the dll in various different places relevant to Labview (e.g. in the directory of the Labview executable file). However, none seem to work (.
    Is there an option in Labview where I can set paths to dlls?
    Any help will be gratefully received.
    Ciao,
    Matthew Banham (colleague of Francois)

    > I have two dlls. One contains public functions which I call from
    > Labview. The functions in this dll call functions in the other
    > (private) dll. However, how do I tell Labview where to find this
    > private dll?
    >
    > Is there an option in Labview where I can set paths to dlls?
    >
    The problem is that the system loader is what handles the dependent
    DLLs. Since LV knows about the primary DLL, we try multiple locations,
    the path in the dialog, next to the VI, in the LV search paths, and
    finally we ask the system to look in their places. LV doesn't know
    about the dependent DLL, and it is up to the system to find it. I'd
    recommend trying the system or windows folder again. That should be the
    right solution.
    An off the wall thought that might h
    elp would be to add a dependency
    directly into LV by making a DLL node that calls in the the "private"
    DLL. You don't actually have to call it, you can place it in a case
    structure with a constant set the other way. Anyway, this will cause LV
    to look for the DLL, and I think it might help if nothing else works.
    Greg McKaskle

  • Configuring array of byte in dll call

    Dear all,
    I need to send the data 2010010100H to the dll at the question mark(U8) i mentioned in the attachment. Actually the data has to be transferred at a time not in bits and pieces. How to do this? I just put an array constant. Is it correct? Kindly give suggestions asap.
    Thanks,
    Mathan
    Attachments:
    1.PNG ‏10 KB

    Hi mathan,
    the dll call in your pic only accepts single bytes (U8) - so no way to wire an array!
    why do you create so many new threads, when the topic doesn't change?
    Best regards,
    GerdW
    CLAD, using 2009SP1 + LV2011SP1 + LV2014SP1 on WinXP+Win7+cRIO
    Kudos are welcome

  • How to response polling event during dll call

    Hello,
    There is a long time dll call in my program. The program doesn't response to mouse click in the front panel during the dll call when I want to display other page in Tab control. It only response after the call.
    How to solve the problem?
    Thanks!

    Wether or not it is possible to fix this situation is dependent on the dll itself.
    IF
    the dll is written to be re-entrant (thread-safe)
    THEN
    you can configure the Call Library function to not run in the user interface thread. This can be done by right-clicking on the node and selecting "configure". In the configure screen, ther is a drop down selection box that defaults to "Run in UI thread". Change this to re-entrant.
    You can then determine which thread the dll runs in by setting the properties of the calling VI.
    Warning!
    If the dll is not re-entrant you WILL experience random crashes and possible data coruption! All bets are of if the dll is used in the wrong manner.
    What is happening:
    LV's execution systems are multi-thread with the exception
    of the UI thread. The UI thread is single threaded to ensure updates of control and indicator information is updated correctly, etc. This thread also uses co-operative multi-tasking wherein a proccess is expected to "put itself to sleep" regularly in order to allow other proccesses in that thread to gain access to the CPU. Your dll is dominating this thread and prevent user actions to be serviced!
    Final note;
    If you do not know if the dll is thread-safe and decide you just want to experiment,
    BACKUP YOUR ENTIRE MACHINE!
    Ben
    Ben Rayner
    I am currently active on.. MainStream Preppers
    Rayner's Ridge is under construction

Maybe you are looking for