Sorry to disturb you again,I've tried the headerfile,but it doesn't work either,here is the original code of the headerfile:
#ifdef CHEMNOISE_EXPORTS
#define CHEMNOISE_API __declspec(dllexport)
#else
#define CHEMNOISE_API __declspec(dllimport)
#endif
CHEMNOISE_API int Calculate_Noise(long sig_Length, double * time, double * signal,/*raw data*/
double t_Start, double t_End, /*time range*/
double * SD6, /*6SD*/
double * P2P, /*PtoP*/
double * ASTM, /*ASTM*
double * Wander, /*Wander*/
double * Drift /*Drift*/);
VEE can recognize it,but can't use it.What's the problem?Thank you very much!
Best Regards,
James
-----Original Message-----
From: Shawn Fessenden [mailto:shawn@testech-ltd.com]
Sent: Thursday, December 02, 2004 5:17 AM
To: 'HUANG,BO-NAN (A-China,ex2)'; 'VRF'
Subject: RE: [vrf] RE: How to transfer the dll file into VEE?
> Thanks,and what confused me is that I don't know whether the
> format of the headfile is right
Oh! Gosh, I'm sorry! I thought you wanted to actually read the dll file into a variable. This is much different.
You use an Import Library object. Set it to Compile Library (From the dropdown), name the dll file (in filename) and name the .h file (in definition file).
This looks ok except for calltype - which I assume is either _stdcall or _cdecl. Whichever it is VEEs 6 and 7 need the proper declaration. VEE 5 just figures it out for itself.
The complete def would be (depending on linkage type):
int _stdcall Calculate_Noise(long sig_Length, double *time,
double *signal, double t_Start, double t_End, double *SD6,
double *P2P, double *ASTM, double *Wander, double *Drift);
The long is Int32, the doubles are Real64 and the double pointers are Real64 arrays. All reference params (all except sig_Length, t_Start and t_End) *must* be allocated with enough space for output results before calling. Note that if _stdcall linkage is specified then the function name will actually be _Calculate_Noise@48 unless the name is specified via a .def file to the compiler or via a compiler switch. Use a export table dump to find the actual name of the function.
-SHAWN-
---
You are currently subscribed to vrf as: rsb@soco.agilent.com
To subscribe send a blank email to "join-vrf@it.lists.it.agilent.com".
To unsubscribe send a blank email to "leave-vrf@it.lists.it.agilent.com".
To send messages to this mailing list, email "vrf@agilent.com".
If you need help with the mailing list send a message to "owner-vrf@it.lists.it.agilent.com".
Aww heck - that's only 1/3 reply per day over 7 years
> Anyway, thank you for all your work on the archive.
You are most welcome! I'm having a blast
> Man! That thing is quick!
Yeah I'm really impressed. I had no idea it would be that quick. I was
hoping at most for around 15-20 seconds. MAPI would *never* get this kind of
speed.
Long story short - it's COM that's sapping all the power. The very best
trial runs I had with the old browser -> VRFSchCli.exe -> VRVSchSvr.exe ->
MAPI -> VRFSchSvr.exe -> VRFSchCli.exe -> browser all were on the edge of
acceptability. All of the custom stuff was running lightning fast, but when
I got to querying MAPI kabam. It was almost as slow as ArBot. A complex
query could take as long as 30 seconds to execute in real time.
This is a much, MUCH better way to do this kind of thing. Apologies to Randy
Schad. He told me this months ago when all this started!
-SHAWN-
---
You are currently subscribed to vrf as: rsb@soco.agilent.com
To subscribe send a blank email to "join-vrf@it.lists.it.agilent.com".
To unsubscribe send a blank email to "leave-vrf@it.lists.it.agilent.com".
To send messages to this mailing list, email "vrf@agilent.com".
If you need help with the mailing list send a message to "owner-vrf@it.lists.it.agilent.com".