Gerrit, This feature is already included in the system tester! You mention 3 input functions, Input functions are not allowed in systems, explorations, or experts per se. If you use a Fml() function or FmlVar() function from a custom indicator that uses Input functions then the default values will be used. What you have to do is replace the input function with Opt1, Opt2 IE: A:=Input("length1",3,20,5); A1:=Input("length2",9,60,15); A2:=Input("SIG length3",3,20,5); SHOULD READ in the system tester A:=Opt1; A1:=Opt2; A3:=Opt3; So your poll is moot

Henry Thanks a lot for the suggestion but I could not make it work, it sounds just like what I need though. I’m pretty sure this is something that needs to be changed in metastock to give it a very practical edge! So let's be clear. INDICATOR BUILDER I go into the indicator builder and build my own indicator. It is a huge formula that will just confuse the issue here. Note combining it with the buy condition logic simply will not fit into the system test if I paste into it. Let's just say in this indicator I refer to things like moving averages etc. for example. On every stock I want to view I need different settings, so I add a variable and set it from an input statement. Great for viewing the ind. SYSTEM TESTER Now I do not know what all the good settings in my indicator are that would work best with my system so I go to the indicator builder and refer to my indicator by fml(). According to the metastock manual when fml is used the default value of inputs are used. I just tried to go into the indicator builder now with your suggestion, but I get the error saying "Optimization variables are not allowed in this type of formula". Patrick, hope you understand now and hopefully either you, Henry or someone out there has a way to do this. One last point is that if I had to use OPT variables in the indicator instead of an input I would have to change the code each time I switch between using the ind on a chart and using it in a system test. But even that would be an improvement. So the suggestion is: Have the input statements filled from system tests or even experts and explorers with what ever is being passed into fml(). So fml("my ind", OPT1 , OPT2, OPT3) gets placed as if they were input into the indicator on a chart from top to bottom. Thanks Gerrit

Gerrit If you write to me privately I'll explain to you how you can optimise code outside the System Tester. Of course it's not as simple as writing "OPT1", but it's easy enough when you understand the principles involved. The key to it is knowing that the OPT constants can be made available to indicators. My method has been explained in a certain monthly newsletter that I'm not allowed to name. I assume I'm still allowed to give my email address so here it is - rlarsen@man.quik.co.nz Roy

Hi Patrick, I hope you have thought about it and decided to do it :D It will really make sense not to have different copies of the same code all over the show. I am sure it can avoid some distasters too with code being central. And note that my strategy tests would have been impossible to optimise productively without Roy's trick. Roy. Thanks for the info, I have used the GV.dll now in both my system test and in my expert adviser. I still need two copies of my indicator though. One for expert + system test and one for graphs, but I'm not complaining, at least now I can do what would have been impossible without your help. =D> Thanks Gerrit

Hi Patrick, two points: 1) If we could simply code custom formula's with input statements, and have the option of calling them from tests etc. with parameters that would fill in the input statements, we have 1 indicator working in ANY place in metastock that can call a custom indicator. At the moment I still have to have 2 copies of the same indicator which adds much unwanted maintenance overhead. One for graphs and one for tests and experts. 2) The global variable dll is handy, but after all is said, it is plainly a means to get around a limitation. I still end up adding code and still end up having to sacrifice some readability for the sake of being able to fit into small space limits. Coding this should be fairly easy for someone of your talent right :) Just stack the parms as you read them from the source text and let the indicator input them from the stack? Just an idea, guessing from outside. Thanks Gerrit

What are those ... If I end up rewriting something similar to the gv.dll mind as well try to improve it ... Thanks for the feedback ;) Patrick :mrgreen:

Gerrit You might also be interested to know that I've used the GV dll to get around the "only the default value is availaible" problem at times. However this was done to make one specific value available to an exploration (I think), not to provide a range of values to the System Tester. How it works is that an idicator on a chart saves the user value (rather than the default) as a GV, then the exploration calls the GV value and applies it to a copy of the custom formula. This also means that you end up with two copies if the formula, one as an indicator and one as a an element of the exploration or systems test. I haven't yet got my head around how this this approach might be used to further simplify what you're trying to do. There's no getting away from the need to add code simply to store user parameters as GVs, but that doesn't obsolete that formula as far as more normal activities are concerned. You would leave all normal variables in place, and add the ability to change one or more user parameters (Parameter window) to be picked up by other tools such as the ST or Explorer. Space may again be a problem. That's the main reason why I renamed Marks GlobalVar dll as GV. Roy roy@metastocktips.co.nz

Hi Gerrit I'm glad you're alert to the possibility of corrupted global variables. That's a problem that can and will occur if you don't take preventative measures. One has to remember that a GV can only give out what's been put in. Reading (GetVar) a GV variable before writing it (SetVar) won't give an error message, but it will return garbage. Also, accessing a GV (assuming it's) for one security when it was last written from and for another security will also give bad results. The best way around this sutuation that I've found, at least as far as explorations go, and I assume the same will work for experts, is to call the formula that sets up the required GVs before attemping to use them. As an example, all GV based Trade Equity explorations call the supporting TE formula in column A before attempting to use the TE GV data arrays. The following column A for Trade Equity GV LE is not a particularly good example because most of that code relates to creating a portfolio equity curve, and those variables are reset by dropping a custom "reset" indicator onto a chart. The portfolio action, marked by {*}, has to start at zero and accumulate from one security to the next to arrive at a final value for every bar across the entire portfolio. However, just summing the equity from each trade within one security requires the TE formula must be called for that security before MS can accumulate the equity spike at the end of each trade. In other words, the GV variables used by TE are always refreshed (updated) on the current security before being read. This also applies to the portfolio accumulation, but of course it is inappropriate to meddle with the accumulators between one security and the next. That's why the reset is done with an indicator BEFORE running an exploration to generate a portfolio (database) result. A portfolio-based GV reset could also be done with a single security exploration, but I've found that indicators work best, and anyway, an indicator has to be used to display a portfolio result (not the same indicator though). {Column A: $ Profit} {Net profit} Eq:=Fml("Trade Equity GV LE"); {*}Tr:=ExtFml("GV.GetVar","Tr"); {*}Cp:=ExtFml("GV.GetVar","Cp"); {*}Equity:=ExtFml("GV.GetVar","Equity"); {*}Trades:=ExtFml("GV.GetVar","Trades"); {*}Equity:=ExtFml("GV.SetVar","Equity",Eq+Equity-Cp); {*}Trades:=ExtFml("GV.SetVar","Trades",Trades+Tr); N :=ExtFml("GV.GetVar","N"); Cum(N); {accumulate the sum of all trades for current security} Roy