|
PureBytes Links
Trading Reference Links
|
(DISCLAIMER: I just now see you are using 16bit... In that case, I don't
think DLL_Add/DLL_Free/DLL_Context will be available to you. Hopefully the
DllMain will be - I don't know since I've never used DLLs with TS4)
At 02:24 PM 9/29/99 -0400, Barry Kaufman wrote:
>
>I am the guy that posted BASIC 16 bit DLL source code the other day.
Well, I
>have been trying to make the forward - backward zero lag MA that I described
>work. The DLL runs two passes, once to construct the EMA arrays and to
>calculate the composite. Then the 2nd or more passes to plot the MA.
>
>Problem is that EL seems to reload (de-allocate) the DLL on each pass so DLL
>arrays and flags written to on the 1st pass are empty at start of the 2nd
>pass.
I'm not sure how you are defining "pass", but the following may help.
I learned how TS interacts with the DLL just this last week using the
DLL_Add/DLL_Free/DLL_Context that is part of the 2000i developer kit.
If you export DLL_xxx from your DLL, TS will call them at specified times.
DLL_Add gets called whenever someone applies applies a new indicator.
DLL_Free gets called whenever someone sets it's status to off or deletes
it. DLL_Context gets call just before every other call to you DLL (so you
can tell what TS study is calling it).
Also use DllMain to show when TS is attaching to and letting go of your
DLL. Below is the example from TS2000i's example 32bitDLL from the dev
kit. I added the logging so I could see what was happening (debugLog is a
global ofstream (standard C++) object).
BOOL APIENTRY DllMain( HANDLE hModule,
DWORD ul_reason_for_call,
LPVOID lpReserved )
{
switch( ul_reason_for_call )
{
case DLL_PROCESS_ATTACH:
debugLog << "DLL_PROCESS_ATTACH at " << _strtime( tbuffer ) << endl;
break;
case DLL_THREAD_ATTACH:
debugLog << "DLL_THREAD_ATTACH at " << _strtime( tbuffer ) << endl;
break;
case DLL_THREAD_DETACH:
debugLog << "DLL_THREAD_DETACH at " << _strtime( tbuffer ) << endl;
break;
case DLL_PROCESS_DETACH:
debugLog << "DLL_PROCESS_DETACH at " << _strtime( tbuffer ) << endl;
break;
}
return TRUE;
}
>
>1) Is the DLL and its GLOBAL variables being de-allocated and then
>re-allocated again on each pass of the same EL program?
Globals should only be deallocated when the DLL is released (when all
studies using the DLL are turned off or deleted).
>
>2) When EL re-runs after changing an INPUT or turning STATUS OFF then ON,
>does EL re-initialize all VARS: (like set VAR1(5), to 5), and does EL re-run
>the DefineDLLFunc: and does that make a new DLL connection?
In EasyLanguage, yes, every time you turn a study on or off or change in
input, it runs it from scratch.
If you have two studies (A & B) both using the same DLL, and you change an
input of EL study A, study A will rerun from scratch, but you DLL will not
reinitialize since study B was still attached to it. I don't know if study
B reruns or not -- the way I code doesn't depend on it.
>
>3) Is there any EL variable that I can write to on one pass but will hold
>that value for additional passes of the same program? What does EL do
during
>an optimization? It can't re-initialize everything between optimization
>passes, or can it?
During optimization, it is changing the inputs, so you study reruns from
scratch for each set of inputs.
If I understand what you are getting at by "pass", you can't share any data
between passes.
When you write a study, you should (as I understand it) think of having a
chance to run your EL code on each bar. You're program starts on bar #1
with 1 pass. Then it runs on bar #2. Then bar #3. etc (each time it runs
your code on one bar). data can be passed from one bar to the next, but
when you hit the last bar of the chart, your code is dead.
Things get trickier when you talk about the DLLs... If we're square on
this, I'll share my 2cents on how the DLL's work, but the best way will be
for you to use DLL_Add/DLL_Free/DLL_Context/DllMain and display lots of
debug output to a file and watch what happens.
>
>If DefineDLLFunc: running more than once is re-allocating the DLL and its
>memory, than if there is a protected EL memory location, I could use it as a
>switch to conditionally run DefineDLLFunc: only on the first pass. Any
>solution to this problem?
Not sure what you're getting at, but a DLL is allocated when the first
study in TS uses it. It stays live and shares all global data until the
last study in TS using it gets turned off.
Hope that helps some.
|