Posts made by ylidor

@fxDreema Confirm that the importation is a real issue. Also, when I attempted to delete projects by clicking the X at the "Load Project" window, the software asked for confirmation and removed the selected project after confirmation, but when I reopen the "Load Project" window, the deleted projects are still available... Last, the Trace block doesn't trace the same indicator it traced before the blackout. I still investigating it on my side but so far it seem that the problem resides on FxDreema server, since I can trace this indicator with the desktop version of FxDreema (with some limitation since this version is not fully complaint with new updates of the online software) . It seems there are serious issues with the working copy of FxDreema after the blackout. Please check it. Thanks in advance.

I guess this problem was universal. I checked www.fxdreema.com on the site http://downanalyze.com/check/fxdreema.com and it confirmed that the entire site was down for about 18 hours for everyone around the globe. The good news: It's up again.

Bossx, Sorry for being so late (2 months late) to reply. I don't understand your question. The indicator is attached above and the code is unavailable since it is an ex4 file. This topic deals with setting up correctly the enum type of parameters in indicators for which the code is unknown.

Thank you Miro!

I actually was able to solve it myself, as I explained here: https://fxdreema.com/forum/topic/4842/lack-of-support-to-enum-datatype/4. It is pretty much like your solutions. I placed my enum list in the Global Variables section of the FxDreema EA (see picture in the link). I also changed the input parameter at all the iCustom functions as seen in the picture. I wish FxDreema would be able to do all this work for us.

Well after playing around I found how to use enumeration in FxDreema EA. Inserting the list here in the following format does the trick:

Then you have to manually change the enum value at all the icustom lines, as follows:

And then it compiles with no issues

So if I import the indicator exactly as it appears in the Input parameters, as follows

The default value is not liked by the EA, as seen here

And confirmed by the compilation results

Is there any other way to import successfully an enumaration value?

And to be more specific:

These are the input parameters of the custom indicator "ocn_nma_3_1.ex4"

"Price to use" is enumaration data type

I used "enum" as data type

The enum list was casted here in the EA

This is how the enum appeared in the iCustom

And these are the results of the compilation

Can this be resolved? The indicator is attached as it's available on public domain (coded by Mladen - thanks!)

0_1499663853086_ocn_nma_3_1.ex4

FxDreema doesn't support enum datatypes. Some great coders, such as Mladen, are using enum frequently for Price type. Even when I imported one of his "mq4" indicators that has enum Price type I could not use it as costume indicator in FxDreema because of this datatype. Importation of one of his "ex4" indicator ended up the same. When I tried to use "int" with the default value of the enum (which was "close"), I got errors message on this "close" during compilation.

Are there any new ideas how to tackle this deficiency?

Thanks Ron

Hi Miro,

FxDreema doesn't support enum datatypes. Some great coders, such as Mladen, are using enum frequently for Price type. Even when I imported one of his "mq4" indicators that has enum Price type I could not use it as costume indicator in FxDreema because of this datatype.. Importation of one of his "ex4" indicator ended up the same. When I tried to use "int" with the default value of the enum (which was "close"), I got errors message on this "close" during compilation.

Awhile ago you suggested to try a work-around it, but I can't find my post in the forum where you suggested it. Do you have any practical experience with converting enum datatypes to a list of the usual datatypes, and if yes could you please share with me one or two segments of codes to teach me how to do it?

With your permission I'll also post this question as a new topic in the forum to check if the moderator has any new ideas.

Thanks Ron

Thank you very much Miro! I figured out there should be some easy way to do it with which I was still unfamiliar.

I'm almost convinced someone had asked this question before me but as much as I can tell searching with Keywords or short phrases is unavailable on this forum. I wish this would be added so that we would not repeat asking the same question again and again and again....

Creating Stop Loss with x periods of the ATR is pretty straight forward with the available native ATR indicator. But how can we create SL with multiples of the value of ATR over x periods? Is there a simple way to do it without using a costume indicator that calculate these multiples?

Thank you for your suggestion. I was not aware of this block which indeed solved this problem and provided solution for some other configurations. It is a very useful block!

Hi FxDreema,

I have a general question to you and the experienced in this forum:

I have used this template from the examples (https://fxdreema.com/demo/mt4-buy-sell-buy-sell-opposite-conditions) with success. It uses the same opposing condition blocks to enter and exit the trades perpetually.

Is there another generalized template for the following: Enter a trade when the entry condition based on one indicator is met (as in the template above), but instead of waiting to the opposite entry condition to be met in order to close the first trade, exit the first trade when an exit condition based on a different indicator is met, then wait with no entries until the reverse is happening: Enter an opposite trade when the opposing entry condition based on the first indicator is met (as in the template above), but instead of waiting to the opposite entry condition to be met in order to close this opposing trade, exit this trade when an exit condition based on a different indicator is met, then wait with no entries until the reverse is happening.

Please see my crude drawing (attached) to understand my request if the text is unclear.

Thanks in advance, Ron!

Hi FxDreema,

If I'm not mistaken when we design the EA on the "on Tick" tab all the conditions that we add before a market order can be placed should be executed on the same bar. So all the condition have to be met at the same instance to be executed.

I may have missed it by reading through the forum and I assume you have addressed it somewhere else but I couldn't easily find it, so I'm asking you here: what should be the general approach in FxDreema if one condition should be met on a certain bar x and then another one on the next y bars, and yet another on the next z bars (etc.) before a market order can be placed? It is important to add that I'm interested in 2 different scenarios:

1. All the conditions should be true when the last one is met (i.e. the condition on bar x and y should still exist when the condition on bar z is met).

2. The conditions on bar x and bar y have been met once or more but they may or may not persist when the condition on bar z is met.

Thank you in advance for your guidance.

No problems. Instead of playing with this indicator I found that the indicator provided by miro (Fisher_org-v11.2) is useful in FxDreema and that it is actually a pretty good non-repainting replacement (for my purpose) to SolarWind (thank you so much miro!!).

This current topic is now resolved. However, since there is no formal manual to FxDreema I need to ask you a general question which deserves a new topic for everybody's education. It relates to the general approach in FxDreema to 2 conditions or more that have to be met before a market order is placed but they span over several bars. See you there.

Thanks for the reply. So FxDreema doesn't handle enumerations. The solution you are suggesting makes sense to me but I don't know how to do it. Can you please point me to a link showing how to practically convert enum types to their corresponding integers in mlq4?

Thank you FxDreema for your insightful explanation.

I did act on miros’ advice and searched non-repainting replacement for SolarWind.

Of all the mladen’s Ehlers’ Fisher transform indicators that I have found on ForexTSD the only one that may be beneficial to me, based on visual inspection of the output, is “Ehlers fisher transform histogram 2.5”. To test the output of this indicator I imported it to fxdreema . All the input parameters and the buffers were imported well. Also, the indicator itself was compiled well (see snapshot) and ran well on a chart. However, when I wanted to trace a buffer output, the tracer EA would not run. Compiling this EA showed several errors in the way fxDreema interprets the input parameters of this indicator (see snapshot). Can you check whether it’s a bug in fxdreema?

http://www.screencast.com/t/ggvaMJWWh
http://www.screencast.com/t/ZDiib1KmxB8

Ehlers Fisher transform histogram 2.5.mq4

......
Ehlers Fisher transform histogram 2.5.mq4

__If you understand why this happens like that, tell me[/quote:375pqco4]
FxDreema,
The good news – I’m now a yearly subscriber.
The bad news - I have no idea and can’t even make sense why the tick that crossed above the 0 from below was not captured by the EA. Miro’s comment gives a plausible explanation, but as I discuss it next, it may not be the case.

__miro1360
because repainting make for you this issue ...[/quote:375pqco4]
Hi miro,
Thank you so much for your explanation and the file attached. The reason I’m not 100% convinced that the problem lies with repainting is that from what I have read and learned about it, everything that happens in bar0 is actually really happening, but by the time that the bar closes - whatever happened there may have disappeared. Actually, most people would not consider it a "repainting" but rather a normal behavior of Bar0. What is considered as a true repainting is that during the recurrent recalculation of bar1, bar2...., they are "repainted". So, I would expect Bar0 to be the only "normal" bar in a repainting indicator. This bar should provide the output of the formulas as they were originally designed by the indicator creator. Correct me if I’m wrong, but IMHO based on the “tracer” values that I see here, regardless of the "repainting" of Bar0, one of the ticks that formed bar0 did cross over the 0 and this should have triggered the condition, but it did not.

In addition to “SloarWind”, a good example for a “worst repainter” indicator is another one that I use here – “TMA” (as opposed to the “True TMA” that supposedly is a non-repainter). Yet if you are familiar with the lengthy thread of “The Extreme TMA System” on ForexFactory, the group led by Alorente made loads of pips by intentionally using the TMA rather than the True TMA.

I am going though to explore usage of the indicators you have suggested and the MA solution that you have provided here so graciously, to see whether they add reliability and profitability and whether they conform with the rules of the system as I have envisioned them. In its first edition the EA is designed for longer TFs (4H and daily) and so far it has demonstrated to make tons of pips, so repainting is an issue I can live with as long as it doesn’t compromise reliability.
Thanks again Ron

FxDreema - You are THE man!

Just for the record: Using Trace did not help. Actually the numbers that you see on the bars in the 2nd snapshot are the output of the Solarwind buffer. And yes, I did test it with "every tick" and the problem persisted...

But your suggestion to change the cross width from 1 to 2 resolved the problem. Somehow the width of 1 was "too narrow" for the condition to catch the cross, even with "every tick".

As I said before - you are great: this is the 2nd time that your suggestion helped me very much. I will sign up for the yearly subscription after the Labor Day holiday end here. You've earned it. Thank you very much.

http://www.screencast.com/t/H2uxaPDW7d

Hello fxdreema community,

I have one missed execution of a “close condition” which worked well in all the other occasions. The arrow in the snapshots attached (one panoramic and the other detailed) shows were the close condition should have been met but was not executed. Can anybody explain to me why?

http://www.screencast.com/t/kMXvwRONgNGe
http://www.screencast.com/t/lv8Rf4ru

https://fxdreema.com/shared/Bwm1LhEVd

TMA.mq4SolarWind.mq4

......
TMA.mq4
SolarWind.mq4