Suggestion: Synthetic Tick Button

OK, this is a tweaky one, but here it is -

I'd like to suggest a new tiny button, ala the SA, I, R buttons:


and the purpose of the new tiny button would be to replace the last received tick synthetically.

IOW, the chart would pretend that it received the last tick again.

The point is to allow strategies that require a tick to act (i.e. to fire an order) to be triggered manually by the user even when the market is not ticking.

As EL/PL programmers know, some really great geometric stuff can be done on a chart and used to trigger orders. The only downside is that you need a tick to do it.

In a thin market, waiting for that tick can be an undesirable wait.

If we could simply send the most recent tick again to the active strategies, that is all that would be required to allow orders to be placed any time.

Note - I'm not suggesting altering saved data or anything like that. I just want to say to the strategies (by whatever technical slip-of-the-bit would do it) "pretend you just got that last tick again". That should be all that's needed to gain a really nice flexibility for implementing on-chart actors that can do their thing at any point in realtime.

That would be very useful. However, the other approach, which has been suggested before a couple of times at least is to have a time based trigger so that a study can be forced to run after a predetermined limit when an update tick was not received. Also, the study will have to know if this is the case to distinguish it form other times when an update tick did trigger the study. In this way, the study can take appropriate courses of action if and when required.

Of course, ideally it would be nice if both approaches were implemented.

Having said all this, I still prefer TSS to focus all their energies for a while to improve the user friendliness of the product as it stands, and fix the numerous bugs, as I stated in another post.

All good to have, (I concur):

Tick-based triggers (done!)
Time-based triggers
Manual triggers
User friendliness
Bug fixes

If this is regarding the movement of drawing objects such as trend lines, etc. why not simply have an option to trigger calculation when a drawing object is added/moved with this as the direct trigger? There are already special provisions to permit recalculation on broker events such as market position change or order fills (see Strategy Properties dialog for these settings) so this would not be much of a stretch to add this as a calculation trigger and would be less wasteful of resources to only do this when the user adds/moves something than to evaluate it every 1/10 second or at whatever interval on a timer. (I do support adding timer evaluation also.)

Regarding the implementation of hundreds of suggestions for minor improvements and minor bug fixes, no doubt these to some extent should be worked in along the way with each revision, as parts of the program are being revised, and as it makes sense in the context of ongoing efforts. Major bug fixes (of which there are very few really) should be fixed as soon as possible (bearing in mind this may not be immediate because of development already underway, and because of the time it takes to do testing) - the platform vendor will be best able to evaluate which issues are the most serious, affect the most people, and should be made the highest priority, once the facts have been made known by those reporting the problem and providing a test case.

Regarding the implementation of hundreds of suggestions for minor improvements and minor bug fixes, no doubt these to some extent should be worked in along the way with each revision, as parts of the program are being revised, and as it makes sense in the context of ongoing efforts. Major bug fixes (of which there are very few really) should be fixed as soon as possible (bearing in mind this may not be immediate because of development already underway, and because of the time it takes to do testing) - the platform vendor will be best able to evaluate which issues are the most serious, affect the most people, and should be made the highest priority, once the facts have been made known by those reporting the problem and providing a test case.

I agree. The problem that's now growing is that many of the so called smaller bugs (some of which are not small at all) and annoyances appear to be ignored completely. As I said, often it's the simple things that makes or breaks a product. All is that's required is a concentrated effort on the part of TSS to fix as many of these as possible. It should only take them a few weeks of effort. This is all for their own benefit, not just for the users - to maximize the popularity of MC. I would have thought any company worth their salt would listen to the users' complaints and do something about it. Leaving them at the low priority end means they will never be addressed. I'm not suggesting they do what a competitor I know does - they not only listen to suggestions and complaints of all sizes, they actually have them addressed typically in a matter of days. I'm just suggesting TSS spend a few weeks to catch up on as many of these issues as possible, and repeat the exercise say once a year.