Stop Limit orders

Interestingly enough, this is the opposite of the reason EasyLanguage was made this way in the first place. Most people in fact have the opposite problem, in that they want to do things like put on a long position and have various exit orders out there e.g. a stop AND a target AND a trailing stop AND a technical exit (some of which they may intend to reside at the broker and not on their PC), and they don't want to worry about the possibility that if more than one of them happens to be filled it may cause an opposite direction entry because they do not intend to reverse, only to specify more than one possible way to get out - it's for this reason that explicitly entry or exit orders were introduced.

Yes, I understand all that but you miss the point many users prefer the simpler approach. Besides, one can't use the current methods in MC to trade shares in certain ways that are very common in practice. For example, I buy 100,000 shares in a company then buy another 50,000 later. Then I want to sell several smaller parcels later on. I can't do this generically without writing code like I posted earlier. Even then it's impossible to take care of all possible parcel sizes on exit as I would have to write 100's of 1000's of lines in the study - and that will probably slow it down considerably, if not crash MC. In my mind there is no question about it. We need a simple buy and sell order type with no restrictions. The dangers you illustrated in doing this are easy and simple to control (ie, exit quantities exceeding the original quantity opened). All one has to do is have code in the study to verify unwanted transactions don't happen. I would recommend doing it anyway even with the current system to be ultra safe. The code is very simple to implement - probably one of the simplest things to do in any study.

Let's say MC uses buy/sell type statements rather than entry/exit specific statements. I want to have a stop and a target in place for the following 60 minute bar, without using IOG. They're spaced closely enough together that one or both of them could be hit in the next 60 minutes, but they're far enough apart that they won't be hit on the same second. How can I do that using only buy/sell statements unless they're exit-specific, without a possibility of an unintended reversal? I can't - no combination of EL lines or 1000s of lines can do it, because I can't know which will be hit first and thus I must keep them both in place for the next bar. It's for this reason that the platform has features that allow orders to be specifically exit orders, so that it can manage this aspect of the position even before my strategy is next calculated in 60 minutes.

I'm not opposed to there being additional keywords that allow bypassing these protections - I'm simply explaining why it's the more common need to have it be the way it is.

Let's say MC uses buy/sell type statements rather than entry/exit specific statements. I want to have a stop and a target in place for the following 60 minute bar, without using IOG. They're spaced closely enough together that one or both of them could be hit in the next 60 minutes, but they're far enough apart that they won't be hit on the same second. How can I do that using only buy/sell statements unless they're exit-specific, without a possibility of an unintended reversal?

Very simple. I do it now and have my own dll functions to simulate simple buy and sell order types. Conflicts are impossible as the dll uses a combination of multi-threading, critical sections and position checking. I ran some tests whereby I bombarded the dll with orders from multiple studies. This is for the more complex studies. For the simple ones where I will only ever have one study for a particular symbol, I use only EL code and check the current position to make sure I submit the correct order type and quantity.

You didn't answer the question. Using only EasyLanguage buy and sell statements that aren't exit specific, how can I have a "sell next bar at x stop" and a "sell next bar at x limit" in place for the following 60 second bar, yet not use IOG, and be assured there will be no unintended reversal? You can't. That's why there are exit order types like "sell" and "buytocover" - so that you can specify several exits without a reversal, and so that you can't be assured you won't close out more than you opened.

You didn't answer the question. Using only EasyLanguage buy and sell statements that aren't exit specific, how can I have a "sell next bar at x stop" and a "sell next bar at x limit" in place for the following 60 second bar, yet not use IOG, and be assured there will be no unintended reversal? You can't. That's why there are exit order types like "sell" and "buytocover" - so that you can specify several exits without a reversal, and so that you can't be assured you won't close out more than you opened.

I would never have an order to sell at stop and limit the way you described. I would do it all in EL code to decide in real-time what to do by checking the last trade. It avoids such complications that you describe. For example, if the price action passes my pre-determined stop on long positions I "sell".

That's fine - I understand you are saying you may not do this. But many people trade daily bars or other long time frames like 60 minute bars etc., and they have absolutely no desire to use IOG or to manage the orders at the low level you are talking about - it doesn't always make sense to do what you're describing and wait until the next calc to put one order or the other in the market, and certainly not from an "ease-of-use" standpoint or from the standpoint of what makes the shortest, easiest to understand code. That's one of the things that makes EasyLanguage "easy" is that it takes care of these details for you.

EasyLanguage isn't all things to all people - but it's designed to make a particular class of commonly needed things easy, and it does that very well.

Essentially, what you are saying is, you don't want it to be like EasyLanguage anymore - you want it to be like a more basic platform where there's no position management and everyone is on their own to manage orders. I'm not opposed to adding that as an option, but to suggest that the way it is is somehow inferior is I think missing the big picture, which is that for most people, the current design works very well indeed.

That's why there are exit order types like "sell" and "buytocover" - so that you can specify several exits without a reversal, and so that you can't be assured you won't close out more than you opened.

That's the other point. I can't re-use the same sell or buytocover command on multiple exits after doing a single entry. I have to resort to code I posted before to do this. Is there another way? For example, if I buy 100,000 shares and then want to sell 10,000 to 20,000 shares at a time, is there a way I can do this without using different sell commands?

Essentially, what you are saying is, you don't want it to be like EasyLanguage anymore - you want it to be like a more basic platform where there's no position management and everyone is on their own to manage orders. I'm not opposed to adding that as an option, but to suggest that the way it is is somehow inferior is I think missing the big picture, which is that for most people, the current design works very well indeed.

Yes. There are different types of traders out there. I've been a trader for over 25 years and I've met most of the different trader types. So to have a platform tied to just one type is limiting the market exposure of the product.

t doesn't always make sense to do what you're describing and wait until the next calc to put one order or the other in the market

You imply that MC has a real 'at market" order type for all kinds of entries and exits. It doesn't. That's something else I like to see put in. If my study decides to enter a long position at any given bar or tick, it should be able to place the order "at market" immediately.

Hi Support
I am with Janus on this,meaning why not allow this flexibility for those that wish to use it as Janus explained,For those like Bruce is suggesting can still do as done now,but at least allow MC with some other options.
This applies to many features in MC,excellent,but sometimes lacks flexibility,which over time I am sure will be added.
Thanks
Milton

I am with Janus on this,meaning why not allow this flexibility for those that wish to use it as Janus explained,For those like Bruce is suggesting can still do as done now,but at least allow MC with some other options.
This applies to many features in MC,excellent,but sometimes lacks flexibility,which over time I am sure will be added.
Milton

I'm a great believer in giving as much flexibility as possible, especially for advanced programmers like myself. I understand how less flexibility makes it easier to foolproof a development environment, but places too many restrictions to advanced users. That's why I actually prefer trading tools like NT and AB because they use advanced languages natively, but I've stayed with MC because of it's advanced charting features and easier to use language supplemented by my dll's for more advanced work ending up with the best of all worlds.

As I've said several times above, I support adding new optional features to place orders that are unmanaged. That's how I handle orders on any number of other platforms where I've been building autotrading systems for years. I was simply explaining why it isn't the case that the way things are in EasyLanguage is bad - it's what most people find the most helpful. What I reject is the notion that the current design is somehow defective - it's actually quite good at doing what it does - it simply wasn't designed to solve every possible problem and there are some things it doesn't cleanly express - it isn't and can't be all things to all people.

Right now, EasyLanguage doesn't have a clean solution for scaling both in/out in arbitrary pieces (no looping orders), and the code to do this tends to be awkward (e.g. a large number of different lines of code to allow placing 100 orders, etc.), for the simple reason that this isn't the problem EasyLanguage was designed to solve. On the other hand, for system trading ideas that are of the right sort e.g. a few setup conditions, then entry, a stop, a target, a trailing stop... EasyLanguage tends to have a solution that's about 5-10 lines long instead of hundreds of lines long, because it's extremely expressive and powerful for these types of ideas, and provides a way to handle many common needs with practically no code and in an English-like language, which is quite a time saver and very helpful.

The solution clearly is to leave in place everything that's here, and simply add separate, unmanaged order entry capabilities for those who want to be "on their own" in managing their own orders, so that for instance orders can be used in loops and are handled more like a "print" statement is, rather than being matched by comment, price and size, etc. and I agree that this suggestion can be helpful for those specific situations such as arbitrary scaling in/out where the current architecture doesn't really take the necessary things into account in its desire to make position management "easy" for most people testing and building out system trading ideas.

This new unmanaged capability will have to operate in a radically different way (more like unmanaged platforms do), returning unique order identifiers when an order is placed, and allowing order status, fill size/price, etc. to be checked by identifier, and orders to be canceled by identifier - it won't be able to match on price/size/comment like EasyLanguage does now and thus you would need to explicitly cancel orders rather than simply not restating them, but will allow programmers who want to take low-level control to do so.

I don't begrudge the addition of these kinds of capabilities and think they should be added to round out the capabilities - I simply reject that the current solution is somehow a bad one because it doesn't let you to loop and place orders etc. - that's a compromise that was thought out and clearly understood by the designers, and was considered to be the best compromise in terms of helping the most people the most. It's actually quite a good design considering, and that's why only a few users out of a great many find they need low level order control despite following many different kinds of approaches.

Will the Stop Limit order be added in the MC 6 release?

The solution clearly is to leave in place everything that's here, and simply add separate, unmanaged order entry capabilities for those who want to be "on their own" in managing their own orders, so that for instance orders can be used in loops and are handled more like a "print" statement is, rather than being matched by comment, price and size, etc. and I agree that this suggestion can be helpful for those specific situations such as arbitrary scaling in/out where the current architecture doesn't really take the necessary things into account in its desire to make position management "easy" for most people testing and building out system trading ideas.

100% agree. However, i won't hold my breath seeing it implemented. Pity really as it would attract many more subscribers if this was done.

Dear Sirs,

The Stop Limit orders will be implemented in the version 7.

We are currently working on MultiCharts 7.0. Actually this feature has been developped already in the separate brunch of version 7.0.

MultiCharts 7.0 should be released in the end of summer. So it will not take too long to have Stop Limit orders implemented.

We will not delay the release of 7.0 as we did with version 6. We had special reasons for that which cannot be publicized.

Will the Stop Limit orders be implemented in the Multicharts 7.0?

Dear ppan,

Yes, Stop Limit orders will be implemented in MC 7.0