How do i determine if a variable exist?

i have a variable in my afl called myentry1. is there a routine i can call to see if it exist in the afl

you mean calling the variable in your plugin, right?

yes that is possible:

AmiVar myentry1 = gSite.GetVariable(“myentry1”);

I know that but what if it doesn’t exist how do i check

i would have to check mañana but I would guess if myentry1 is a number you do somethink like:

AmiVar myentry1 = gSite.GetVariable("myentry1");

if (NOT_EMPTY(myentry1.val))
{

}

if(IS_EMPTY(myentry1.val))
{

}

is also a possibility

1 Like

can i get a list of all the variable in my afl in my dll would be a better question

Relying on presence of certain variables in your DLL exported functions is bad idea.
All communication between formula AND DLL should be via function call arguments and return value. Modifying variables from within DLL in hidden way is bad coding practice and inevitably would lead to hours spent by you on debugging unclear relationships between formula and the DLL.

My dll need to lock a few variables just like /close/open/high /low

i need to see if those varabiles are used or not

wow 2 sentences to explain your problem instead of 1. You are making progress

4 Likes

Ed, that dry humor of your post made me LMAO. And it’s so true.
People (having issues) always expect detailed responses preferably (and of course copy&paste ready codes while leaning backwards) but many of them almost never provide detailed original post. End result: a lot of waste of time.

2 Likes

i know i am guilty always had that problem

Sorry @nickhere but I really don’t know what you mean with “lock a variable”. Maybe you meant “look at variable”? OHLC are built-in price arrays and they are always available and always exist.

tomaz is there a way to get a variable list in a dll?
a list of all the variables that the afl uses

No you can’t get list of all variables from DLL.
As I said, you should not communicate via variables and you should not rely on existence of variables or lack thereof.

The plugin should rely on passing arguments to function and returning value from the function. That is proper way to code the plugin.

You need to understand that your plugin will be called from MULTIPLE THREADS, and you won’t know which thread variable you are reading now.

It is very bad idea to communicate via variables. Use arguments and return value. That is the ONLY way.

1 Like

Do we not rely on the existent of open low high close and volume. All i am doing is making sure that a array is in the afl. I cant see how this is bad programming. I need to make sure the array myentry exist by the plugin. If the variable doesn’t exist exit the dll. Oh I get your point have the plugin pass the array. I can work that way to. But i am passing over 14 variables now

Hows that going to work sometimes I need to pass 6 more variable other time it may be only 3
I still think checking for existent is a better.

Hi @nickhere,

Several of my DLL files used to rely on passing data directly to afl variables and it was a huge mess.

On Tomasz recommendation I rewrote my functions to pass everything as arguments. This is the best way to do things. He is absolutely correct.

You can create as many functions as you need to pass different numbers of variables or write one that accepts a superset and pass a variable to tell your function which to use.

-Alan

DLLs support variable argument count.
The thing is that you provide default values for OPTIONAL parameters. And these optional parameters can but do not need to be provided by calling code. If given argument is not passed, it gets the default value.
See the AmiBroker Development Kit documentation for the details.

I forgot about optional parameters. Thanks for clarifying.

can you give me a example

so i should do this
myfunction(myentry1,myentry2,myentry3);
but if i do this
myfunction(myentry1);

what would tell me that only 1 has been passed

I have never coded default values into my DLL, so to avoid giving inaccurate advice I cannot say much about it. It is covered in section 2.4 of the ADK documentation. It appears that default values can only be applied to float arguments, not arrays or strings.

If your arguments are floats, select a default value that would indicate to your function that nothing was passed.

My original comment about having multiple functions would look like this (different functions depending on the number of arguments):

myfunction1(myentry1);
myfunction3(myentry1, myentry2, myentry3);

Or for a superset:

myfunction(myentry1, myentry2, myentry3);

You would send dummy arguments to the ones you are not using, letting your function know to disregard them.

Or…

myfunction(numArgs, myentry1, myentry2, myentry3);

Where numArgs tells your function how many arguments to use. You would still need to send dummy arguments in the unused entries.