Caling external Dll problem

Hi to all,
I am calling a dll in TestStand. Actually the dll contains 462 functions. But in TestStand it shows only 4 functions (which define as static). How could I access other functions?
Regards.

Hi,
When calling functions and class methods in a DLL from TestStand, there are a number of requirements for you to access these functions. One of these requirements is that the methods must be static and public. So it is expected that the only functions you currently have access to are the ones that were declared as static. You can find out about all the requirements for accessing methods and functions from a DLL in the section "Exporting Class Methods and Functions in Visual Studio" found in the TestStand Help.
Take a look at this help entry and let me know if you have any more questions.
Thanks,
Caroline
National Instruments
Thanks,
Caroline Tipton
Data Management Product Manager
National Instruments

Similar Messages

Problems using LIBRARY to access external DLL

Windows 2003, Oracle 10g and 11g.
We have an external dll that we can call using 'create library' and a wrapper function. The wrapper functios works well from SQL*Plus - our function is executed and the external dll does its work.
When we add the function to some Apex processing, the session hangs at the point at which the wrapper function is invoked and control never returns - we have to kill the database session.
Any ideas as to what might be happening? I thought that a permissions error would be returned immediately, I don't know what would just make the session hang.

Windows 2003, Oracle 10g and 11g.
We have an external dll that we can call using 'create library' and a wrapper function. The wrapper functios works well from SQL*Plus - our function is executed and the external dll does its work.
When we add the function to some Apex processing, the session hangs at the point at which the wrapper function is invoked and control never returns - we have to kill the database session.
Any ideas as to what might be happening? I thought that a permissions error would be returned immediately, I don't know what would just make the session hang.

FRM-40734 when calling external DLL Function from Forms 6

Even though some answers were given to my previous help request ("Again: Forms 6 and user-defined data types") I wasn't able to solve the problem of passing a parameter of an user-defined type to an external DLL function residing in the SECURSIGN.DLL library (the closest solution was to declare that "composite" parameter using the ROWTYPE clause referencing a custom-made table created just for the sake of defining that perticular datatype).
So I concentrated on SECURSIGN.DLL functions using more trivial data types, like a function requiring just four character strings as parameters.
I generated the necessary PL/SQL support using the FFI.
I discovered that also the simplest calls to external functions fail at runtime with the generic error FRM-40734.
I located the error: it happens just at the moment of calling the function from within the FFI-generated package body. Before that, the DLL is loaded with no problem, the function is correctly registered, and a function handle is regularly returned.
As long as I can regularly issue the very same call with the very same parameters from Visual Basic, I can't understand what's going wrong (ALL the needed DLL are in the same directory as the FMB/FMX forms).
I will greatly appreciate any help that You may be able to provide.

I have noticed just now that a dump file having a name like ifrun60_dump_299, is generated by FORMS every time I issue the aborted call to the foreign function.
Inside the form dump file, apart from useless info like Registers and so on, the message:
"Could not find Module32First"
By a FILE/FIND/CONTAINING TEXT I searched all the DLLs, and I noticed that Module32First is a routine that can be found within each of the following DLLs:
Cl32
d2kwut32
d2kwut60
I tried to load those DLLs along with SECURSIGN.DLL by modifying the PROCEDURE LoadLibrary into the FFI-generated PLL code, and I have apparently no problem in loading all the DLLs that I wish, but the error persists, and that dump file is constantly generated, always looking for the "Module32First" routine.
How can I avoid all that mess and the FRM-40734 error??

Controling a user interface with extern DLL

Hi,
I am currently developing an application that is based on a graphical interface. I divide my code into multiple DLLs. By going this route, I met several problems. I want to know some facts:
1 - from the DLL can I assign values to textbox, read listbox of the GUI:GetCtrlVal (panelHandle, PANEL_TEXTBOX, val); (the GUI is integrating in the project who call the DLL)
2 - I use global variables "extern int" in my files. h and my functions. How do I change this variable declaration when I migrate to the DLL.
If you have any exemple describing how can i control a GUI with extern DLL.
Thanks

Hey Fishingman,
It looks like this post is very similar to your other post on Application Architecture. If this is the case, let's continue this discussion on this thread so that it is easier to follow for anyone else who may be keeping up with this.
To expand on my original response a little though - if you are just looking to be able to modify the user interface in a dll then take a look at this link. It explains how to set up dll function calls to modify a user interface. Again, I wouldn't suggest building your entire GUI through different dlls but it is definitely possible to modify it within a dll.
Regards,
Trey C.

HELP! RETURN CLOB from External DLL

Hi
I am working on an External DLL using OCI. Basically, PL/SQL
calls an
External DLL to process the data and then returns LOB back to
the PL/SQL
procedure. Inside the DLL, I created a Temporary lob to process
the data.
The error is prompted from PL/SQL:
SQL> exec isdb.test_clob;
Before original length=10
ORA-24805: LOB type mismatch
ORA-06512: at "ISDBSVR.ISDB", line 24
ORA-06512: at "ISDBSVR.ISDB", line 29
ORA-06512: at line 1
So far I know that error is caused by the return from PLS_CLOB
is not clob.
"After_original := PLS_CLOB(before_original); {you will see more
code in the
below}" However inside the DLL, I have defined OCIClobLocator
and
OCI_TEMP_CLOB to carry the CLOB data.
I have found the following observations:
1. If I change everything to blob, it works fine. (such as
OCILobLocator,
OCI_TEMP_CLOB and all variables in PL/SQL)
2. If I run the same DLL and PL/SQL in 9i, it works fine (clob
too)
I guess it would be a bug for clob, please help to check thanks
-- CODE - PL/SQL
CREATE OR REPLACE PACKAGE BODY "ISDBSVR"."ISDB"
as
Function PLS_CLOB(var_clob in clob)
RETURN clob IS
EXTERNAL LIBRARY bb
WITH CONTEXT
NAME "Encrypt_Blob"
LANGUAGE C
PARAMETERS
CONTEXT,
var_clob,
var_clob INDICATOR SB4,
RETURN INDICATOR SB4
PROCEDURE TEST_CLOB IS
before_original cLOB;
After_original cLOB;
CHAR_TO_CLOB varchar(200);
bsize int;
BEGIN
CHAR_TO_CLOB := 'AAAAAAABBBBBBCCCCCCC';
dbms_lob.createtemporary( before_original, TRUE );
DBMS_LOB.write( before_original,10,1,CHAR_TO_CLOB);
bSize := DBMS_LOB.GetLength(before_original);
DBMS_OUTPUT.PUT_LINE('Before original length='||bSize);
After_original := PLS_CLOB(before_original);
bSize := DBMS_LOB.GetLength(After_original);
DBMS_OUTPUT.PUT_LINE('After original length='||bSize);
dbms_lob.freetemporary(before_original);
END;
END ISDB;
/* CODE - DLL */
EXPORT OCILobLocator * EncryptBlob(OCIExtProcContext
*with_context,
OCILobLocator *plaintext2,
sb4 pt_indicator2,
sb4 *ret_indicator
{ FILE *fp;
OCIClobLocator *cipherbb;
ub4 amount;
ocictx oci_ctx;
ocictx *oci_ctxp = &oci_ctx;
status = OCIExtProcGetEnv(with_context,
&oci_ctxp->envhp,
&oci_ctxp->svchp,
&oci_ctxp->errhp);
status = OCIDescriptorAlloc(oci_ctxp->envhp,
(dvoid **) &cipherbb,
(ub4) OCI_DTYPE_LOB,
(size_t) 0,
(dvoid **) 0);
status = (int) OCILobCreateTemporary(oci_ctxp->svchp,
oci_ctxp->errhp, cipherbb,
OCI_DEFAULT,
OCI_DEFAULT,
OCI_TEMP_CLOB, OCI_ATTR_NOCACHE,
OCI_DURATION_SESSION);
amount = 6;
status = OCILobCopy(oci_ctxp->svchp,
oci_ctxp->errhp,
cipherbb,
plaintext2,
amount,
(ub4) 1,
(ub4) 1);
*ret_indicator = OCI_IND_NOTNULL;
OCIDescriptorFree((dvoid *) cipherbb, (ub4) OCI_DTYPE_LOB);
return(cipherbb);

In what database version did you observe the problem?
Thomas

LabView user-event from external dll source

Hi!
I'm dealing with the following issue:
I use a CAN sniffer device, wich sends data over USB to a PC. The main goal is to create a vi that can process the incoming data. I already have a vi wich works with polling mechanism. It calls external DLL functions with the "Call library function node". The main problem is the polling mechanism.
I would like to recreate this vi so that it would work event-driven. I have an other application, written in C++, that does the same thing, and it gets interrupts from a DLL, when a new data is available in the input buffer.
The callback mechanism is implemented in the DLL.
In LabView I would like to do tha same thing. There is the "event case structure", but there is no option for defining such user-events, that i would prefer.
I have found a similar topic, there the solution is "occurrences". The occurrence is called from a DLL, too. But this solution uses the "waiting for occurrence to set", that is an endless-loop-like thing.
The other thing I've found is the ActiveX and .NET events. I don't know, probably that is the solution.
Anyway: is there a possibility to create such events, that can be generated from a simple external DLL and can be handled by "event case structure"? How should I do this?
Or how NI does this? I mean that NIs DAQ cards must use some similar methods for data processing. Is there some tutorial or support about it?
Thank you for your answer!

2716jag wrote:
Hi Wiebe, From your answer i have a doubt that What it exactly means "If the dll is used from within LabVIEW". Also i want to know Is there any way to access the functuions defined in the .SYS file in Labview Environment. Regards,Jagan Can you be a litte more specific with your first sentence. I have no good idea what you mean. A .sys driver is usually a kernel device driver. This driver has to be started and run in the kernel subsystem which LabVIEW can not access directly. Such a driver is initialized using the CreateFile() Windows API. The returned handle is then used with other API functions such as ReadFile(), WriteWile(), DeviceIoControl(), and finally CloseHandle().Theoretically you could call all this APIs directly from within LabVIEW using the Call Library Node. In practice you do not want to do this even for fairly simple kernel drivers since the parameters for those APIs do get fairly complex in most cases, and you usually do also want to have some sort of asynchronous operation using events or such to make the driver access user friendly. All these things are most easily handled in a user space DLL written in C that exports a more LabVIEW friendly API that you can then import into LabVIEW using the Call Library Node. Usually most kernel device drivers do come with a accompagning user space DLL already, as this is the only sensible way of accessing such a driver. So you can usually look for the documentation of that user space DLL API and go from there trying to import that into LabVIEW using the Call Library Node. Even then it may not be easy at all if that API uses complicated function parameters and even completely impossible if it uses callbacks or such, requiring you to write a so called wrapper DLL that translates between the native API and a more LabVIEW friendly API. You don't have to believe me but I can guarantee you that if writing such a user space DLL or wrapper DLL is beyond your capabilities, trying to go directly about accessing the Windows APIs in LabVIEW to access a kernel device driver is going to make you squirm in real pain. And those knowing how to write such a DLL would never even consider spending the time to try to access a kernel device driver directly from LabVIEW. Rolf Kalbermatter

What causes memory use of my program increase? (Write to Spreadsheet? Running in LV environment? External dlls? Waveform graphs?)

Hi
I have attached a plot for the discussion here..
I am monitoring the memory usage by my VI thru calling a window's dll to keep checking that (Many thanks to Matt).
I saw raising slopes and flat (wow! First time I catch this, that's what I am expecting)
I am thinking where could there be a reason for memory growing up!
What I did:-
1. Mostly use queues (all limited # of elements) for parameters delivery between loops and between subVIs
2. I close Obtained queue ref. every time I finish with it (only leaving a few keeping alive so they won't be killed)
3. For all arrays I initialized with a fixed size array constant and do all jobs with Replace subset, Index Array and that In-place block.
Above are measures I intended to use to save memory.
However for a few points I think there might cause a memory grows, and I wish that someone can share with me your experience or give me an answer...
1. Write to spread file:-- I keep using this to log data, events into harddisk, in my use I always append new logs/data to the existing file, however I keep doing it all the time throughout the run-time.
2. Running my program in LV.exe -- I havn't compiled it yet. However when I was taking the plot's data, my PC is left with no one using it.
3. There is a couple of external dlls running -- however it sounds to me from other's view point, external dll's resource doesn't count into Labview.exe. Since I am monitoring Labview's memory use, that couldn't be a source of the raising I see from this plot, right?
4. Waveform graphs -- I am not sure whether this can be a problem. Everytime I feed data into a waveform control, I initialized a constant array and then replace elements into it, I don't think my data source is casuing any problem.
Can someone comment on my above descriptions of my program?
Raymond

vgbraymond wrote:
1. Write to spread file:-- I keep using this to log data, events into harddisk, in my use I always append new logs/data to the existing file, however I keep doing it all the time throughout the run-time.
Write to spreadsheet file is a high level VI that opens and closes the file with every call. I would recommend to open the file once at the start of the programs, then append using lowlevel functions. Close the file after the program is done.
Have you done any profiling to see which subVIs shows the bulk of the memory use?
You might also turn off debugging to see if it makes a difference. Don't open the front panel of subVIs (and avoid functions that force the front panel to be in memory) unless they need to show something important to the user.
It would really help if we could see some actual code. Can you strip it down to the essentials that still show the problem?
LabVIEW Champion . Do more with less code and in less time .

Compiling own app with -X02 makes external dll core dump.

Hello,
I have a C++ app that calls a function w/in an external shared library. The external dll does not have debug symbols and is probably optimized. When my app is compiled with -xO2 or higher, I get a core dump (no mapping at the fault address) deep within the external dll. When I am compiling my app with -xO1 or with debug info, I do not get the core dump within the external dll.
My questions are:
1. Does this mean that there is a bug w/in my code or within the external dll's code?
2. If not error in either, is there any way to overcome this core dump without lowering the level of optimization (and thus slowing down the app)
Here is a stack trace I got by attaching dbx to my app:
t@1 (l@1) signal SEGV (no mapping at the fault address) in num2qword at 0xfd320248
[1] num2qword(0x345cfd8, 0xffffff85, 0x63ad0, 0xfd323ba0, 0xa800, 0xa8d8), at 0xfd320248
[2] evalexpr(0xffbf7f58, 0x345cee8, 0x1, 0x0, 0xfd27e558, 0xfd3230d0), at 0xfd323ba0
[3] eval_expr_full(0x328e388, 0x345d04c, 0x345cfd8, 0xfd27e558, 0x1, 0x0), at 0xfd3249e8
[4] cm_eval_expr(0x328e388, 0x345d04c, 0x5800, 0x5944, 0xb400, 0xb400), at 0xfd1eea68
[5] cm_optredeem_can_redeem(0x328e388, 0x345d1e0, 0x16ddec, 0x5c00, 0x0, 0x345d1e4), at 0xfd21620c
[6] cm_optredeem_condition(0x328e388, 0x345d1e0, 0x0, 0x0, 0x0, 0x135eb29), at 0xfd2162d8
[7] cm_maybe_execute_optredeem(0x328e388, 0x345d1e0, 0x0, 0x0, 0x0, 0x1), at 0xfd216568
[8] cm_pay_1_period(0x328e388, 0xfd3ba364, 0x345d1e0, 0x345d52c, 0xfd383c98, 0x0), at 0xfd21ab5c
[9] cm_payloop(0x328e388, 0x1, 0x0, 0x324df00, 0x0, 0x3), at 0xfd21ae08
[10] icmo_cashflows(0x0, 0x0, 0x168, 0x328b7b0, 0x0, 0x328b7b0), at 0xfd2d1700
[11] CMOInstrument::getICMOCashFlow(0x1627b28, 0xfd48bdb8, 0x570, 0x2b1c, 0x2800, 0x400), at 0xfd442410
[12] NE_CMOAnalytics::value(0x39b71e0, 0x98, 0xfd48bdb8, 0xe, 0xffbfc268, 0x2e93b08), at 0xfd42d560
[13] NumericExpression::value(0x1643800, 0x1667b48, 0x1667b48, 0x2eabde0, 0x2eabde0, 0x0), at 0xc13410
[14] NE_CMOPriceTimesBalance::value(0x2b02078, 0x2ead230, 0x1667b48, 0x2eabea0, 0x2eac06c, 0xfd48ec8c), at 0xfd42da9c
[15] NumericExpression::value(0x1643800, 0x1667b48, 0x1667b48, 0x2eabea0, 0x2eabea0, 0x0), at 0xc13410
[16] ExchangeableModuleBase::evaluateExpression(0x31259c4, 0x15e4400, 0x0, 0x2eabea0, 0x1667b48, 0x2e93b08), at 0x746e54
[17] ExchangeableModuleBase::evaluateExpressions(0x31259c4, 0x2f3d7c8, 0x746ca0, 0x1, 0x164c800, 0x15c8414), at 0x746c68
[18] ExchangeableModuleBase::recalc(0x31259c4, 0x0, 0xffffffc8, 0x164c800, 0x0, 0x746c40), at 0x746c10
[19] ExchangeableModule::recalc(0x31258d4, 0x15e5730, 0x15c81ac, 0x164c800, 0x7fe8c0, 0x0), at 0x4a8ff4
[20] BatchInstrument::commandDispatch(0x15fd850, 0x1ac, 0x1, 0x619b2c, 0xc, 0x2ebbbc0), at 0x619ce0
[21] Callback(0x2eee48c, 0x3, 0x5, 0x1, 0xffbfccf0, 0xffbfcd6c), at 0xe652f0
[22] CallExtRtn(0xffbfe1d0, 0x2, 0x1, 0xffffdffe, 0x1, 0xfcd0fc86), at 0xe727d4
[23] PcodeExecute(0x2eee8ac, 0xef5c18, 0x1, 0x15b9750, 0xef5c18, 0x4), at 0xeab848
[24] ExpStartThread(0x2eee48c, 0x0, 0x0, 0x1, 0x1, 0x0), at 0xe6e1e0
[25] BasicScriptCodeObject::executeThread(0x2ebb070, 0x2eee48c, 0x0, 0x2ebb074, 0x2eeed68, 0x0), at 0xa0fcb0
[26] BasicScriptCodeObject::run(0x2ebb070, 0x0, 0x0, 0x0, 0x0, 0x2ebb070), at 0xa0fe24
[27] BasicScriptManager::loadAndExecInitScriptFile(0x2d7eb08, 0x1, 0xa, 0x0, 0x1, 0x2eef5f0), at 0x587f80
[28] main(0x32db9b8, 0xffff3400, 0x308b998, 0x0, 0x1c1fd20, 0x1c0db58), at 0x438c6c
[10] icmo_cashflows(...) is the call to the external dll. From 9 and up to 1 the source code is not visible to me..
OS/CC Versions:
CC: Sun C++ 5.5 Patch 113817-05 2004/01/13
SunOS: 5.9 Generic_117171-05 sun4u sparc SUNW,Sun-Fire-880
compilation options:
-dalign -xarch=v8plusa -xlibmopt -D__solaris_sparc__ -errtags=yes -errwarn=wnoretvalue,wnoelseretvalue +w2 -erroff=doubunder,reftotemp,notemsource,hidef,hidevf,wbadlinkage_w,noexthrow,noextry,notused -DLIC_MGR -DUSE_SMART_HEAP -DUSE_SH_ALLOC -template=wholeclass -instances=explicit -features=no%except -features=rtti -Drindex=rindex -Dindex=index -DADD_DYNAMIC_SYMBOLS -KPIC -DNDEBUG -mt -xO1 ( -xO2 .. -xO5 or -fast give above noted core dump)
Thanks in advanice,
Alex

From the symptoms you describe, it is possible that the shared library contains a bug, but it is more likely that the problem is in your code, passing bad data to the shared library.
The problem might be a compiler bug, but I think an error in your code is more likely.
For example, your code as written might have undefined behavior that works by accident when compiling without optimizing, but fails when the compiler improves the runtime code.
Some examples:
1. A classic MT programming error is failing to declare a variable volatile when it is shared by more than one thread. In each thread, the compiler assumes it can remember the value of the variable and not reload it between references.
2. "x = ++x + b;" Modifying a variable twice in an expression withtout sequence points has undefined behavior -- compiler optimization can affect the result.
3." foo(x, x+=3);" the order of evaluation of function arguments is unspecified, so the actual values passed to foo could depend on optimization.
With C++ 5.5, you get some warnings from system headers that you can't do anything about, which I suspect is why you have disabled some warnings. Unfortunately, you might be disabling warnings that you need to see. That is, some of the disabled warnings could point to invalid code that results in the program crash.
I suggest using w instead of w2 (to avoid uninteresting warnings), and fix your code to eliminate the warnings you get.
In the current compiler, C++ 5.7 in Sun Studio 10, we have made some adjustments to warnings to make w and w2 more useful. You should consider upgrading.You can get a 60-day free trial version here:
http://www.sun.com/software/products/studio/index.xml
Also get the current patches for it here:
http://developers.sun.com/prodtech/cc/downloads/patches/index.html

Event structure doesn't handle all events from external DLL source

Hi!
I use a DLL, wich handles an USB CAN transceiver device, and generates LabVIEW user events with extcode.h and PostLVUserEvent() function.
In my vi I use an event case structure to handle theese external events. The problem is, that if the events come too frequently, then it cannot handle all events.
The vi contains a couple of parallel while loops which process the incoming data from the external event.
In another application I use the same architecture, and that works fine. This one is more complex.
Do you think I have reached the limits of the program? Or what else can be the problem?
I have tried to use a queue in the event structure, it helped a little, but yet, not all the events are handled. My external DLL sends all event, so the problem is not there.
Thanks in advance!

Hi Wasz,
Thanks for the post and I hope your well.
It is not possible for the event structure to miss events - it simply queues them up. To keep the event structure 'in time' with the code you must ensure the code to execute in each event is minimal to allow the event structure to handle the next event.
Please see this two links:
event structure buffering: leading to,
How to avoid built-up for "cursor move" events? : where somone is trying to avoid handling all events.
What sort of events are not being handled? Could it be an issue your events are not configured correctly? Maybe if you could produce a small example in LabVIEW code, so we can just test the event structure configuration... someone working around the external dll call - which you seem sure is working correctly.
In terms of queuing to process the events in other loops is certainly an option to speed up the event structure. To do this, use a produce/consumer design pattern.
hope this helps,
Kind Regards
James Hillman
Applications Engineer 2008 to 2009 National Instruments UK & Ireland
Loughborough University UK - 2006 to 2011
Remember Kudos those who help!

Wrapper for invoking external DLL-function

I want to run a Host-Command (e.g. rwrun60 report=xyz.rdf batch=yes) invoked by a trigger that fires when a new record is inserted.
I wrote a DLL which has an exported function that accepts a commandline (with parameters) and invokes the command via ShellExecute.
The problem is, that when i invoke the PL/SQL-wrapper, the DLL-function is properly run, but the program i want to run is only visible in the taskmanager(NT) and does nothing.
So what i need is a correct wrapper for the function:
DLL-function: OExecSysCmd(cmdLine *char)
Wrapper:
PROCEDURE OExecSysCmd(p_SysCmd in char)
IS EXTERNAL
NAME "OExecSysCmd"
LIBRARY demolib;
Thanks in advance
Dannys

Hi Russ,
with "invoke an external dll" I mean that I have to wite a log file to register my fdk client events and to do this I have to use an external dll wich exposes some functions to write to a common log file. I have imported the external dll in my client project and at the beginning of client code I have included the dll header file:
#include "LogDll.h"
Then I've tried to invoke a LogDll function (not within F_ApiInitialize (), but in a custom dialog box event):
int retval=LogDllFunction();
The code compiles, but if I start FM, I receive the message error. If I comment the line above, FM and my client start normally.
Thanks,
Stefano

Possibly mundane Mini-DVI to VGA into an external monitor problem

Hi,
I've had a look over the interwebs regarding my problem and it seems as if it's not unusual to have external monitor problems but I'm not sure if mine is slightly different:
I had a perfectly working set up with my new Macbook (the white one, '06 model I believe), that was connected to my Hanns-G HU196D monitor via a mini-DVI to VGA adapter, no problems whatsoever. But for a couple of weeks now my Macbook just flickers a light blue colour, with nothing at all on the monitor, and my macbook is unusable until I remove the adapter. I've read about updating firmware but I can't see my desktop once the macbook is connected to the monitor so it's not possible to configure anything. I've read somewhere that my external monitor isn't compatible with this set up, but it was until a couple of weeks ago!
My Macbook's 4 months old now and since then I've bought a new mini-dvi to vga adapter and a new VGA cable, no connections seem loose on either mini-dvi port or my monitor's vga port.
Thanks if you can help!
Jack

You will need to use a mini Dvi-dvi and a dvi-svideo/rca adapter.
Joy joy hallelujah.
Pardon the sarcasm...I just wasted 3 hours of my life trying to sort the issue out.
Heard a KWORLD PlusTV PCTOTV Converter SA235 USB 2.0 Interface would sort the issue out for under 40$ but it's not Mac.
Hope that helps.
~r

External Display Problem with x301

Hi everybody,
I have a external display Problem with my x301.
Ether direct attachment or via Lenovo USB Display Port Device, the external monitor (22" Benq LCD) starts to flickr after a couple of minutes and the external display shuts off.
Any ideas on this?
Thanks a lot
Chris

i have the same problem with X200 and the X200 ultrabay Docking station.
No idea yet ...

How to load external DLLs with C++ interface in TestStand?

Hi,
Can you please let me know how would I load external DLLs with C++ interface in TestStand?
Regards.

TestStand 3.x can only call static class C++ methods. TestStand cannot call methods on a C++ object because TestStand does not know how to enstantiate the C++ object. In TestStand 3.x, there is a online help topic called "Exporting Class Methods and Functions in Visual Studio .NET".
Scott Richardson
National Instruments

How to use external DLLs in InDesign server plugin

Hi,
I am working on a project, which is having dependency on libxml2 library. I compiled the code on 64 bit Windows platform and using InDesign server 64 bit version. I put the required DLLs in Adobe InDesign CS6 Server x64 folder(with other DLLs). But now my plugin is not loading in server and also not throwing any error message on command prompt.
If I remove the libxml2's method call, then plugin is loading successfully.
Is there any other way to use external DLL or I am missing something?
Thanks & Regards,
Harsh

Hi Sidharth,
If you are using web dynpro DC perspective then you need to follow the following points to use the external jar files in it.
1. Create a external library project.
2. copy the external jars in the library folder os the projects.
3.) Select all the jars from the u201CLibrariesu201D folder, Right click and then select Development Component and click on Add to Public Part
4.Select the first Radio Button (Provides an API)and give some nameto it.
5. Repeat the step no 3 but now select the second radio button other than as selected in step no 4.
6. Now build your lirary DC.
7. Now create a j2ee DC project.
8. ) Expand the node DC Definition and Right Click on Used DC. Select Add Used DC.
9. Select the External Library DC with build time dependency.
10.Right click on the J2EE DC and then select Development Component followed by Build
11. Right click on the J2EE DC and then select Development Component followed by Deploy
now you can use both the libary DC and the j2ee DC in your web dynpro DC as used DC.
But if you have created a web dynpro project only(but not DC) than you can directly add the external jars in java build path
hope this will help
regards
Narendra
Edited by: Narendra Singh on Oct 27, 2009 11:22 AM

CVI crashes when calling function from external DLL

I'm calling a CVI library from Test Stand 4.1. In that CVI library I load an external DLL (using LoadLibrary) and create a few function pointers (using GetProcAddress). The DLL loads successfully, and I get addresses for all of the imported functions.
However, when I one of the functions is called CVI crashes (Test Stand says it lost the ActiveX connection to CVI) when executing in an external CVI instance. If executed in the Test Stand process I get a system level exception.
If I step through the code in CVI, it hangs after trying to step into or over the call to the function pointer from the external DLL.
I am able to call the functions in a small test project I created in CVI, however when integrating it into an existing test library and calling it through Test Stand it fails.
Any ideas on how to go about debugging this issue?

Have you tried calling into the dll that CVI calls directly from TestStand? I am curious to know if this also crashes.
I am also curious to know if there are any path references in the dll that is called by the CVI program. If so are they relative, or absolute paths?
I ask because one of the possibilities is that relative paths are being used to specify a path from the location of the code that is called, and they are not working because the current working directory is being specified by TestStand, and the paths are not relative to the working directory given by TestStand.
Jensen
National Instruments
Applications Engineer

Caling external Dll problem

Similar Messages

Maybe you are looking for