 |
A. Program Design The activity of progressing from a specification of some required program to a description of the program itself. Most phase models of the software life cycle recognize program design as one of the phases. The input to this phase is a specification of what the program is required to do. During the phase the design decisions are made as to how the program will meet these requirements, and the output of the phase is a description of the program in some form that provides a suitable basis for subsequent implementation.
Frequently the design phase is divided into two subphases, one of coarse architectural design and one of detailed design. The architectural design produces a description of the program at a gross level; it is normally given in terms of the major components of the program and their interrelationships, the main algorithms that these components employ, and the major data structures. The detailed design then refines the architectural design to the stage where actual implementation can begin. See also program design language.
B. Productivity Tools
End-User Programming Productivity Tools
Andrew J. Ko, Brad A. Myers, Michael J. Coblenz, and Jeffrey Stylos
Human-Computer Interaction Institute
Carnegie Mellon University
Pittsburgh, PA 15213
ajko@cs.cmu.edu, bam@cs.cmu.edu, mcoblenz@andrew.cmu.edu, jsstylos@cs.cmu.edu
http://www.cs.cmu.edu/~marmalade
ABSTRACT
Our research focuses on developing interactive technologies
for a broad range of end-user programming activities,
including code construction, verification, debugging, and
understanding. A common goal among all of these
technologies is to identify core ideas that can be used across
a variety of domains and programmer populations.
INTRODUCTION
Although end-user programmers’ interests vary widely,
spanning the web, animation, documents, databases, mail,
and countless other types of information, all of these users
use programming as a means to an end [10]. Therefore, to
minimize the distractions from end users’ primary goal, it is
essential that end user programming tools are approachable,
easy to learn, and immediately helpful [1].
We are designing several technologies that satisfy these
criteria, including new interaction techniques for editing
code, new languages that help end users identify mistakes,
debugging tools that answer users’ questions about their
program’s output, and workspaces that help them
understand the answers. All of these technologies have been
directly inspired by the empirical research of a variety of
programmer populations and their difficulties [5, 6, 8, 11].
Figure 1. Barista [7], a Java editor that supports drag and
drop, auto-complete menus, and text editing in a single editor,
and embedded, in-context tools and visualizations.
CONSTRUCTING PROGRAMS
Syntax has long been a significant learning barrier in end-
user programming systems, largely because of the difficulty
of understanding and remembering the hidden and complex
rules encoded in language grammars [5]. We have been
working on a new class of code editors that try to help users
construct code by choosing from different options rather
than having to memorize the syntax. Barista [7], shown in
Figure 1, is a Java editor that embodies this approach. It
supports drag and drop interactions for creating and
modifying code and syntactic and semantic auto-
completion, as well as traditional text editing interaction
techniques, all in a modeless editor. Barista also allows
designers of end-user programming systems to embed tools
and information in code, as illustrated by the method header
on the bottom of Figure 1.
Although Barista is currently for Java, its underlying design
and techniques could be an alternative to conventional text
editors across the spectrum of programming languages.
DETECTING ERRORS
Some spreadsheet systems allow users to specify units (e.g.
5 lbs.) with their data in order to help detect unit errors in
calculations. However, most data represented in
spreadsheets is a measurement of a particular kind of object
(e.g., 5 lbs of apples), and it is often inappropriate to
perform calculations on data that represent different kinds
of objects. Slate [2], shown in Figure 2, allows users to
Figure 2. Slate [2], a spreadsheet language that allows users to
give data labels, in order to help identify incorrect input and
formulas. For example, the label “(apples, oranges)” at the
bottom right of the spreadsheet suggests an error, since
nothing can be apples and oranges simultaneously.Figure 3. The Whyline [4] which allows users to ask “Why
Did” and “Why Didn’t” questions about their program’s
output, and get answers in terms of the events related to the
behavior in question. In this situation, the user asked why Pac
did not resize, and the answer shows the execution events that
caused the “else” part of the conditional to be executed.
represent the object of measurement as a label. By
intelligently propagating labels, Slate can help users
identify incorrect input data and calculations. For example,
in the spreadsheet shown in Figure 2, the result “$179.55
(apples, oranges)” tells the user that one of the formulas is
likely to be incorrect, since nothing can be an apple and an
orange at the same time.
Labels could be used in other end-user domains, such as
animations or dynamic web pages that involve computation
on heterogeneous and semi-structured data.
Figure 4. Crystal [9], a word processor that allows users to ask
questions about the document and application state, and get
answers in terms of the user interface components that are
related to the behavior in question. In this situation, a user
asked why a word changed from “teh” to “the”, and the
answer explains that the “Replace text as you type” checkbox
is checked.
processor’s behavior. A user study demonstrated that this
helped users solve common problems about 30% faster than
the same word processor without support for questions [9].
We are currently generalizing the Whyline to more complex
and widely used languages, such as Java, in order to
identify issues of scale and assess the range of questions
that people ask about program behavior.
UNDERSTANDING PROGRAMS
DEBUGGING PROGRAMS
One reason debugging is the most time-consuming part of
programming is that end users must map their questions
about a program’s behavior onto debugging tools’ limited
support for analyzing code. We have been working on a
new approach called interrogative debugging, which allows
programmers to ask questions directly about their
programs’ output. Our prototype, the Whyline [4], allows
programmers to ask "Why did" and "Why didn't" questions
about their program's output in the Alice programming
environment (www.alice.org). Programmers choose a
question from an automatically generated menu, and the
tool provides an answer, as seen in Figure 3, in terms of the
runtime events that caused or prevented the desired output.
In user studies of the Whyline, users with the Whyline
spent an eighth as much time debugging the same bugs than
users without the Whyline and made 40% more progress.
In generalizing the Whyline, we have begun to apply its
ideas to traditional user interfaces. Our Crystal word
processor [9], seen in Figure 4, allows users to ask
questions such as “Why did this word change from ‘teh’ to
‘the’?” and get answers in terms of the user interface
components and state that were responsible for the word
Even though their programs tend to be small, end users still
tend to have difficulty relating code to its corresponding
behavior [5]. Furthermore, the interfaces that end users use
to navigate and understand code, mainly windows and tabs,
incur significant navigational overhead [6]. We are
currently designing a new type of workspace that helps
users both interactively and automatically collect fragments
of code and other information that is relevant to their
maintenance or debugging tasks. It will eliminate much of
the navigational overhead, while helping users to quickly
understand dependencies between different parts of their
program.
LEARNING TERMINOLOGY
One common programming activity, even among end-user
programmers [5] is learning to use a collection of external
code in the form of libraries, toolkits, APIs, and
frameworks. Some of the difficulty in this task comes from
the fundamental vocabulary problem [3]: a particular
programming concept can be described in multiple ways
and no one word will best describe it for all programmers.
Mica, shown in Figure 5, attempts to solve this problem by
acting as a thesaurus: programmers supply a description of
the desired functionality, using their own terminology, andACKNOWLEDGMENTS
We thank our collaborators, including Htet Htet Aung,
Christopher Scaffidi, and David Weitzman. This work was
supported by the National Science Foundation, under NSF
grant IIS-0329090, and as part of the EUSES consortium
(End Users Shaping Effective Software) under NSF grant
ITR CCR-0324770. The first author was supported by an
NDSEG fellowship.
REFERENCES
1.
2.
3.
4.
Figure 5. The Mica web application. Mica includes a keyword
sidebar on the left, which is generated from Google Web API
search results shown on the right. Search result pages
containing code are marked with an icon.
Mica finds related classes and methods in the standard Java
APIs in the form of keywords (method, class and interface
names on the left in Figure 5) and regular web search
results (on the right in Figure 5). Mica determines API
keywords by analyzing the content of the Google search
result pages and comparing these to a list of all class and
method names for the standard Java API. The keywords are
ranked based on the frequency with which they appear in
the search result pages for the query and the overall
frequency with which they appear on all pages indexed by
Google. The list of keywords dynamically updates as Mica
loads and processes all of the search result pages.
We plan to expand Mica’s to aid other aspects of API use,
such as understanding high-level API concepts, finding
example code, and integrating examples into programs.
CONCLUSIONS
Our research covers a broad spectrum of programming
activities, and we anticipate that our techniques will
generalize to a variety of domains and programmer
populations. We hope that our broad focus will both inspire
new ideas for commercial programming tools and drive
innovations in end user software engineering research.
5.
6.
7.
8.
9.
10.
11.
Blackwell, A., First Steps in Programming: A
Rationale for Attention Investment Models, IEEE
Symposia on Human-Centric Computing Languages
and Environments, (2002), 2-10.
Coblenz, M. J., Ko, A. J., and Myers, B. A., Using
Objects of Measurement to Detect Spreadsheet
Errors, IEEE Symposium on Visual Languages and
Human-Centric Computing, (2005), 314-316.
Furnas, G. W., Gomez, T. K. L. L. M., and Dumais,
S. T., "The Vocabulary Problem in Human-System
Communication," in Communications of the ACM,
30, 1987, 964-971.
Ko, A. J. and Myers, B. A., Designing the Whyline:
A Debugging Interface for Asking Questions About
Program Behavior, Human Factors in Computing
Systems, (2004), 151-158.
Ko, A. J., Myers, B. A., and Aung, H., Six Learning
Barriers in End-User Programming Systems, IEEE
Symposium on Visual Languages and Human-Centric
Computing, (2004), 199-206.
Ko, A. J., Aung, H., and Myers, B. A., Eliciting
Design Requirements for Maintenance-Oriented
IDEs: A Detailed Study of Corrective and Perfective
Maintenance Tasks, International Conference on
Software Engineering, (2005), 126-135.
Ko, A. J. and Myers, B. A., Barista: An
Implementation Framework for Enabling New
Interaction Techniques and Visualizations in Code
Editors, ACM Conference on Human Factors in
Computing, (2005), to appear.
Ko, A. J. and Myers, B. A., A Framework and
Methodology for Studying the Causes of Software
Errors in Programming Systems, Journal of Visual
Languages and Computing, 16, 1-2, (2005), 41-84.
Myers, B. A., Weitzman, D. A., Ko, A. J., and Chau,
D. H., Answering Why and Why Not Questions in
User Interfaces, ACM Conference on Human Factors
in Computing Systems, (2005), to appear.
Nardi, B. A., A Small Matter of Programming:
Perspectives on End User Computing. Cambridge,
MA: The MIT Press, 1993.
Panko, R., What We Know About Spreadsheet
Errors, Journal of End User Computing, 2, (1998),
15-21.
C. Expert Advisors
The
principles of MQL4-programs
development are shown on sample of creating
a simple Expert Advisor system based on the standard
MACD indicator. In this Expert Advisor, we will also see examples of
implementing such features as setting take profit levels with the
support of trailing stop as well as the most
means ensuring safe work. In our example, trading is done through
opening and managing a single position.
Trading principles:
- Long (BUY) entry – MACD indicator is below zero, goes upwards and is crossed by the Signal Line going downwards.
- Short (SELL) entry – MACD indicator is above zero, goes downwards and is crossed by the Signal Line going upwards.
- Long exit – by execution of the take profit limit, by
execution of the trailing stop or when MACD crosses its Signal Line
(MACD is above zero, goes
downwards and is crossed by the Signal Line going upwards).
- Short exit – by execution of the take profit limit, by
execution of the trailing stop or when MACD crosses its Signal Line
(MACD is below zero, goes
upwards and is crossed by the Signal Line going downwards).
Step 1 – Writing the Expert Advisor description
Step 2 – Creating the primary structure of the programme
Source code of the test Expert Advisor will only occupy several pages, but even such volume is often difficult to grasp, especially regarding that we are not professional programmers - otherwise, we would not need this description at all, would we? :)
To get some idea of the structure of a standard Expert Advisor, let us take a look at the description given below:
Step 3 – Assembling the resulting code of the programme
Let's open the Expert Advisor settings (using a button or a line in the "Properties..." menu. We are offered a window in which we have to define the external settings of the working parameters:
 |
Point the mouse cursor at the Expert Advisors section of the Navigator window, press the right button of the mouse, and select "Create a new Expert" command in the appearing menu. The Initializing Wisard of the Expert Advisor will ask you for entering certain data. In the appearing window, write the name (Name) of the Expert Advisor - MACD Sample, the author (Author) - indicate your name, the link (Link) - a link to your website, in the notes (Notes) - Test example of an MACD-based Expert Advisor. |
Step 2 – Creating the primary structure of the programme
Source code of the test Expert Advisor will only occupy several pages, but even such volume is often difficult to grasp, especially regarding that we are not professional programmers - otherwise, we would not need this description at all, would we? :)
To get some idea of the structure of a standard Expert Advisor, let us take a look at the description given below:
- Initializing variables
- Initial data checks
- check the chart, number of bars on the chart
- check the values of external variables: Lots, S/L, T/P, T/S
- check the chart, number of bars on the chart
- Setting the internal variables for quick data access
- Checking the trading terminal – is it void? If yes, then:
- checks: availability of funds on the account etc...
- is it possible to take a long position (BUY)?
- open a long position and exit
- is it possible to take a short position (SELL)?
- open a short position and exit
- checks: availability of funds on the account etc...
- Control of the positions previously opened in the cycle
- if it is a long position
- should it be closed?
- should the trailing stop be reset?
- should it be closed?
- if it is a short position
- should it be closed?
- should the trailing stop be reset?
- should it be closed?
It turns out to be quite simple, only 4 main blocks. - if it is a long position
- Initializing variables
All variables to be used in the expert program must be defined according to the syntax of MetaQuotes Language 4 first. That is why we insert the block for initializing variables at the beginning of the program
MetaQuotes Language 4 is supplemented by "external variables" term. External variables can be set from the outside without modifying the source code of the expert program. It provides additional flexibility. In our programm, the MATrendPeriod variable is defined as extern variable. We insert the definition of this variable at the beginning of the program.extern double TakeProfit = 50; extern double Lots = 0.1; extern double TrailingStop = 30; extern double MACDOpenLevel=3; extern double MACDCloseLevel=2; extern double MATrendPeriod=26;
extern double MATrendPeriod=26;
- Initial data checks
This part of code is usually used in any expert with minor modifications because it is a virtually standard check block:
// initial data checks // it is important to make sure that the expert works with a normal // chart and the user did not make any mistakes setting external // variables (Lots, StopLoss, TakeProfit, // TrailingStop) in our case, we check TakeProfit // on a chart of less than 100 bars if(Bars<100) { Print("bars less than 100"); return(0); } if(TakeProfit<10) { Print("TakeProfit less than 10"); return(0); // check TakeProfit }
- Setting internal variables for quick access to data
In the source code it is very often necessary to access the indicator values or handle the calculated values. To simplify the coding and speed up the access, data are put into internal variables.
int start() { double MacdCurrent, MacdPrevious, SignalCurrent; double SignalPrevious, MaCurrent, MaPrevious; int cnt, ticket, total; // to simplify the coding and speed up access // data are put into internal variables MacdCurrent=iMACD(NULL,0,12,26,9,PRICE_CLOSE,MODE_MAIN,0); MacdPrevious=iMACD(NULL,0,12,26,9,PRICE_CLOSE,MODE_MAIN,1); SignalCurrent=iMACD(NULL,0,12,26,9,PRICE_CLOSE,MODE_SIGNAL,0); SignalPrevious=iMACD(NULL,0,12,26,9,PRICE_CLOSE,MODE_SIGNAL,1); MaCurrent=iMA(NULL,0,MATrendPeriod,0,MODE_EMA,PRICE_CLOSE,0); MaPrevious=iMA(NULL,0,MATrendPeriod,0,MODE_EMA,PRICE_CLOSE,1);
Now, instead of the monstrous notation of iMACD(NULL,0,12,26,9,PRICE_CLOSE,MODE_MAIN,0), you can use MacdCurrent in the source code.
- Checking the trading terminal – is it empty? If it is, then:
In our Expert Advisor, we use only those positions which are opened with market orders and do not handle the pending orders. However, to be on the safe side, let us introduce a check of the trading terminal for previously placed orders:
total=OrdersTotal(); if(total<1) {
- checks: availability of funds on the account etc...
Before analyzing the market situation it is advisable to check the status of your account to make sure that there are free funds on it for opening a position.
if(AccountFreeMargin()<(1000*Lots)) { Print("We have no money. Free Margin = ", AccountFreeMargin()); return(0); }
- is it possible to take a long position (BUY)?
Condition of entry into the long position: MACD is below zero, goes upwards and is crossed by the Signal Line going downwards. This is how we describe it in MQL4 (note that we operate on the indicator values which were previously saved in the variables):
Additional control over the size of the 'hillocks' being drawn was already mentioned above. MACDOpenLevel variable is a user-defined variable which may be changed without interfering with the program text, to ensure greater flexibility. In the beginning of the programme we insert a description of this variable (as well as the description of the variable used below).// check for long position (BUY) possibility if(MacdCurrent<0 && MacdCurrent>SignalCurrent && MacdPrevious<SignalPrevious && MathAbs(MacdCurrent)>(MACDOpenLevel*Point) && MaCurrent>MaPrevious) { ticket=OrderSend(Symbol(),OP_BUY,Lots,Ask,3,0,Ask+TakeProfit*Point, "macd sample",16384,0,Green); if(ticket>0) { if(OrderSelect(ticket,SELECT_BY_TICKET,MODE_TRADES)) Print("BUY order opened : ",OrderOpenPrice()); } else Print("Error opening BUY order : ",GetLastError()); return(0); }
- is it possible to take a short position (SELL)?
Condition of entry of a short position: MACD is above zero, goes downwards and is crossed by the Signal Line going upwards. The notation is as follows:
// check for short position (SELL) possibility if(MacdCurrent>0 && MacdCurrentSignalPrevious && MacdCurrent>(MACDOpenLevel*Point) && MaCurrent<MaPrevious) { ticket=OrderSend(Symbol(),OP_SELL,Lots,Bid,3,0,Bid-TakeProfit*Point, "macd sample",16384,0,Red); if(ticket>0) { if(OrderSelect(ticket,SELECT_BY_TICKET,MODE_TRADES)) Print("SELL order opened : ",OrderOpenPrice()); } else Print("Error opening SELL order : ",GetLastError()); return(0); } return(0); }
- checks: availability of funds on the account etc...
- Control of the positions previously opened in the cycle
"cnt" – " is a cycle variable that must be defined at the beginning of the program as follows:// it is important to enter the market correctly, // but it is more important to exit it correctly... for(cnt=0;cnt { OrderSelect(cnt, SELECT_BY_POS, MODE_TRADES); if(OrderType()<=OP_SELL && // check for opened position OrderSymbol()==Symbol()) // check for symbol {
int cnt = 0;
- if it is a long position
if(OrderType()==OP_BUY) // long position is opened {
- should it be closed?
Condition for exiting a long position: MACD is crossed by its Signal Line, MACD being above zero, going downwards and being crossed by the Signal Line going upwards.
if(MacdCurrent>0 && MacdCurrent<SignalPrevious && MacPrevious>SignalPrevious && MacdCurrent>(MACDCloseLevel*Point)) { OrderClose(OrderTicket(),OrderLots(),Bid,3,Violet); // close position return(0); // exit }
- should the trailing stop be reset?
We set the trailing stop only in case the position already has a profit exceeding the trailing stop level in points, and in case the new level of the stop is better than the previous.
// check for trailing stop if(TrailingStop>0) { if(Bid-OrderOpenPrice()>Point*TrailingStop) { if(OrderStopLoss() { OrderModify(OrderTicket(),OrderOpenPrice(),Bid-Point*TrailingStop, OrderTakeProfit(),0,Green); return(0); } } }
}
- should it be closed?
- if it is a short position
else // go to short position {
- should it be closed?
Condition for exiting a short position: MACD is crossed by its Signal Line, MACD being below zero, going upwards and being crossed by the Signal Line going downwards.
if(MacdCurrent<0 && MacdCurrent>SignalCurrent && MacdPrevious<SignalPrevious && MathAbs(MacdCurrent)>(MACDCloseLevel*Point)) { OrderClose(OrderTicket(),OrderLots(),Ask,3,Violet); // close position return(0); // exit }
- should the trailing stop be reset?
We set the trailing stop only in case the position already has a profit exceeding the trailing stop level in points, and in case the new level of the stop is better than the previous.
// check for trailing stop if(TrailingStop>0) { if((OrderOpenPrice()-Ask)>(Point*TrailingStop)) { if((OrderStopLoss()>(Ask+Point*TrailingStop)) || (OrderStopLoss()==0)) { OrderModify(OrderTicket(),OrderOpenPrice(),Ask+Point*TrailingStop, OrderTakeProfit(),0,Red); return(0); } } }
} } } return(0); }
- should it be closed?
- if it is a long position
Now let us try to generate pieces of code step by step for each section of the structural scheme:
Step 3 – Assembling the resulting code of the programme
Let's open the Expert Advisor settings (using a button or a line in the "Properties..." menu. We are offered a window in which we have to define the external settings of the working parameters:
Let's assemble all the code from the previous section:
//+------------------------------------------------------------------+ //| MACD Sample.mq4 | //| Copyright © 2005, MetaQuotes Software Corp. | //| http://www.metaquotes.net/ | //+------------------------------------------------------------------+ extern double TakeProfit = 50; extern double Lots = 0.1; extern double TrailingStop = 30; extern double MACDOpenLevel=3; extern double MACDCloseLevel=2; extern double MATrendPeriod=26; //+------------------------------------------------------------------+ //| | //+------------------------------------------------------------------+ int start() { double MacdCurrent, MacdPrevious, SignalCurrent; double SignalPrevious, MaCurrent, MaPrevious; int cnt, ticket, total; // initial data checks // it is important to make sure that the expert works with a normal // chart and the user did not make any mistakes setting external // variables (Lots, StopLoss, TakeProfit, // TrailingStop) in our case, we check TakeProfit // on a chart of less than 100 bars if(Bars<100) { Print("bars less than 100"); return(0); } if(TakeProfit<10) { Print("TakeProfit less than 10"); return(0); // check TakeProfit } // to simplify the coding and speed up access // data are put into internal variables MacdCurrent=iMACD(NULL,0,12,26,9,PRICE_CLOSE,MODE_MAIN,0); MacdPrevious=iMACD(NULL,0,12,26,9,PRICE_CLOSE,MODE_MAIN,1); SignalCurrent=iMACD(NULL,0,12,26,9,PRICE_CLOSE,MODE_SIGNAL,0); SignalPrevious=iMACD(NULL,0,12,26,9,PRICE_CLOSE,MODE_SIGNAL,1); MaCurrent=iMA(NULL,0,MATrendPeriod,0,MODE_EMA,PRICE_CLOSE,0); MaPrevious=iMA(NULL,0,MATrendPeriod,0,MODE_EMA,PRICE_CLOSE,1); total=OrdersTotal(); if(total<1) { // no opened orders identified if(AccountFreeMargin()<(1000*Lots)) { Print("We have no money. Free Margin = ", AccountFreeMargin()); return(0); } // check for long position (BUY) possibility if(MacdCurrent<0 && MacdCurrent>SignalCurrent && MacdPrevious<SignalPrevious && MathAbs(MacdCurrent)>(MACDOpenLevel*Point) && MaCurrent>MaPrevious) { ticket=OrderSend(Symbol(),OP_BUY,Lots,Ask,3,0,Ask+TakeProfit*Point,"macd sample",16384,0,Green); if(ticket>0) { if(OrderSelect(ticket,SELECT_BY_TICKET,MODE_TRADES)) Print("BUY order opened : ",OrderOpenPrice()); } else Print("Error opening BUY order : ",GetLastError()); return(0); } // check for short position (SELL) possibility if(MacdCurrent>0 && MacdCurrent<SignalCurrent && MacdPrevious>SignalPrevious && MacdCurrent>(MACDOpenLevel*Point) && MaCurrent<MaPrevious) { ticket=OrderSend(Symbol(),OP_SELL,Lots,Bid,3,0,Bid-TakeProfit*Point,"macd sample",16384,0,Red); if(ticket>0) { if(OrderSelect(ticket,SELECT_BY_TICKET,MODE_TRADES)) Print("SELL order opened : ",OrderOpenPrice()); } else Print("Error opening SELL order : ",GetLastError()); return(0); } return(0); } // it is important to enter the market correctly, // but it is more important to exit it correctly... for(cnt=0;cnt<total;cnt++) { OrderSelect(cnt, SELECT_BY_POS, MODE_TRADES); if(OrderType()<=OP_SELL && // check for opened position OrderSymbol()==Symbol()) // check for symbol { if(OrderType()==OP_BUY) // long position is opened { // should it be closed? if(MacdCurrent>0 && MacdCurrent<SignalCurrent && MacdPrevious>SignalPrevious && MacdCurrent>(MACDCloseLevel*Point)) { OrderClose(OrderTicket(),OrderLots(),Bid,3,Violet); // close position return(0); // exit } // check for trailing stop if(TrailingStop>0) { if(Bid-OrderOpenPrice()>Point*TrailingStop) { if(OrderStopLoss()<Bid-Point*TrailingStop) { OrderModify(OrderTicket(),OrderOpenPrice(),Bid-Point*TrailingStop,OrderTakeProfit(),0,Green); return(0); } } } } else // go to short position { // should it be closed? if(MacdCurrent<0 && MacdCurrent>SignalCurrent && MacdPrevious<SignalPrevious && MathAbs(MacdCurrent)>(MACDCloseLevel*Point)) { OrderClose(OrderTicket(),OrderLots(),Ask,3,Violet); // close position return(0); // exit } // check for trailing stop if(TrailingStop>0) { if((OrderOpenPrice()-Ask)>(Point*TrailingStop)) { if((OrderStopLoss()>(Ask+Point*TrailingStop)) || (OrderStopLoss()==0)) { OrderModify(OrderTicket(),OrderOpenPrice(),Ask+Point*TrailingStop,OrderTakeProfit(),0,Red); return(0); } } } } } } return(0); } // the end.
