Ash, I am going to call support about this; it comes across as fishy. Especially because I already announced (support) that it could be PRT itself “failing”.

The result of that call :

“Hmm … I don’t know; IG can deal with this differently than IB” (in IB the StopLoss’s are always visible in Trader Workstation).
But we could not spend much time because the person in question has a day off.

I suppose it is offtopic for this thread (is it ?), but the result of that other investigation with the ridiculous distances required causing an order not too Enter (obtain position) was waved by IG with a “Yeah, well, we can’t tell why that is, because Limits are also subject to a minimum distance“. This was real news and even PRT in Paris is astounded by this.
Subjectively this was judged by ProRealTime as BS because it gave IG the opportunity to not give an answer at all.

PeterSt wrote:

I suppose it is offtopic for this thread (is it ?), but the result of that other investigation with the ridiculous distances required causing an order not too Enter (obtain position) was waved by IG with a “Yeah, well, we can’t tell why that is, because Limits are also subject to a minimum distance“. This was real news and even PRT in Paris is astounded by this.

yep, this topic with minimum distances (for entries) is not exactly at the right place here, but since you touched it, I will add a bit. IG is acting here very intransparent. if what they are doing is legaly fine, they should tell openly what exactly they are doing, why they are doing it and maybe even announce in advance somehow from when to when which minimum distances will be in place for which instruments. this year I was contacting them several times regarding min dinstances and got various responses which basically were leading nowhere (I avoid to use more harsh expressions…):

– some persons at IG did not know what I am talking about (and asked for real examples…)

– some were telling me that those min distances are for my advantage (well, so far it was always to my disadvantage…)

– some were telling that they have to do it based on law (never came back to me after I was asking to provide a copy of that law…)

– some were telling “yes, every other broker does it and we do it as well” but were not willing to tell any details about why, when etc…

well, I can imagin or even understand why they are puting in place sometimes those min distances. I assume by that they are reducing their own risks, their own costs. but I don’t understand why they do not tell it to customers in some very transparent way. the fact that they put in place those min distances is bad enough – it turns a bit manipulated cfd “market” into heavily manipulated one, but I suppose we as customers have right to know it.

justisan wrote:

I hope somebody will disagree

I wouldn’t dare to disagree with you :- )
But those who are nevertheless tempted to use a set target loss statement, should NEVER launch it simultaneously with the order entry (buy, sellshort), be it at market or pending. This one is meant to be launched once in real trouble, when loss is already BIGGER than the distance supplied with the set target loss. For those who hope, like you said.

hi,

you need to place commands „set stop…“ „set target…“ otside any conditions, so like this:

if … then

buy 1 lot…

endif

set stop ploss x

set target porofit y

Ash, you could say that this “outside of conditions” thing is for simplification (as in : first get things to work prior to make it more complicated).

Those commands are perfectly allowed to be within conditions, but the explanation of the conditions under which you now must operate, are beyond “knowledge”.
There’s really quite a bit involved like a necessity to reset a SL command with setting the SL to 0 (this is in the documentation, but nothing expects that If / Else conditions really apply it while you are on the edge of that desire). Or how things were explained to you in a fashion “from top to bottom in the program code”, which generally is true, but only comprehensible if you don’t apply conditions. Otherwise all is possible.
So the general advice is to make all mutual exclusive and explicit as you can. An example of not doing that :

If OnMarket then
  Set Stop pLoss to MyAcceptedLoss
endif

Why is this ambiguous ? well, because when the Set Stop command has been executed once, it will remain forever. Or maybe not when the position exits. I don’t even know.

This would make it unambiguous, though maybe without much sense :

If OnMarket then
  Set Stop pLoss to MyAcceptedLoss
else
  Set Stop pLoss 0
endif

Now you will always know what happens.

The moral is : when you want to change these stops and targets underway, then this is perfectly allowed and your approach regarding this is fine. But you must must know what you are doing very well. Make all as mutual exclusive as possible. No ambiguity is allowed in your code, or else you may not be able to follow yourself, while the PRT interpreter just does what you told it to do.
Now justisan’s example :

if … then
  buy 1 lot…
endif

set stop ploss x
set target porofit y

Prefectly clear ! But two small issues, when you’d ask me :

1. the Set Stop makes no sense when no position is in order; it is even dangerous because the amount of position may change while the Set Stop suggests a fixed distance (I know, with variable x this can be made variable);
2. It just does not allow for conditions, while you clearly want these.

Ad 1.: I thus rather have the command right in the same If condition as where the Buy occurs. But only if the Set Stop will be dependent on that Buy. If not, we’d face another issue : redundancy. End if one thing is killing it is that.

Many roads lead to Rome, but you first need to know the roads very well in order to choose one.

I generally use this approach …

Defparam CumulateOrders - False

IF LongCondition THEN //Not onMarket removed
BUY 1.0 CONTRACTS AT myLevel limit
SET STOP PLOSS lossDistance
SET TARGET PPROFIT profDistance
ENDIF