여기서 첫째, 코드를 따라 더 나아가 주문이 있는지 다시 확인해야 하는 경우 함수를 다시 호출해야 합니다. 그리고 변수에 값을 저장하면 추가 없이 추가로 전송할 수 있습니다. 함수 호출. 둘째, 취향의 문제입니다. 특히 여러 조건이 있거나 많은 인수가 함수에 전달되는 경우 복잡한 구성을 구분하는 것을 좋아하지 않습니다. 코드에 대한 이해도를 떨어뜨립니다.
Tapochun : 여기서 첫째, 코드를 따라 더 나아가 주문이 있는지 다시 확인해야 하는 경우 함수를 다시 호출해야 합니다. 그리고 변수에 값을 저장하면 추가 없이 추가로 전송할 수 있습니다. 함수 호출. 둘째, 취향의 문제입니다. 특히 여러 조건이 있거나 많은 인수가 함수에 전달되는 경우 복잡한 구성을 구분하는 것을 좋아하지 않습니다. 코드에 대한 이해를 저해합니다.
Tapochun : 프로젝트가 확장되고 있습니다. 우리는 미래에 대해 생각하려고 노력해야 합니다.
네, 과학에 감사드립니다. 무슨 생각을 하게 될지...
추신. 그런 다음 검사를 조건이 아니라 변수로 반환하고 이미 검사하는 것을 방지하는 것은 무엇입니까? 아마도 미래에 이 프로젝트 의 가장 거친 복잡성 ...
그리고 한 가지 더: 프로젝트가 확장되면 코드 실행 시간이 늘어날 수 있습니다. 변수에 데이터를 입력하면 더 많은 계산이 수행됩니다. 따라서 재확인이 필요할 때까지 주문이 이미 종료되고(예: stop, ... 또는 take ...) 프로그램이 잘못된 값을 고려하는 일이 발생할 수 있습니까? 변하기 쉬운?
맞습니다. 큰 프로젝트와 발생할 수 있는 모든 가능한 상황에 대해 미리 생각해야 합니다. 그래서 저는 항상 최신 데이터를 사용 하기 직전에 가지고 있다는 신념을 고수할 것입니다. 가능한 한 많이.
...
if (OrdersTotal() == 0 && ********** )
OrderSend("USDCHF",OP_BUY,Lots,Ask,0,0,0,"5891",MagicNumb,0,Red);
if (OrdersTotal() == 0 && ***********)
OrderSend("USDCHF",OP_SELL,Lots,Bid,0,0,0,"58892",MagicNumb,0,Red);
...두 명의 고문이 같은 마법을 가지고 있어야 합니다. 그리고 그들은 같은 악기의 다른 차트에서 시작되어야 합니다. 물론 일반적으로 다른 것을 차단하는 것보다 기본을 수정하는 것이 더 쉽습니다.
그들의 시장을 완성하는 것은 작동하지 않을 것입니다.
2 차트에서는 당기지 않습니다. 마땅한 조건을 찾지 못하기 때문입니다. 주문이 0개일 때 2가지 방향으로 주문을 엽니다. 하지만 2가지 방향이 작동해야 합니다.
음, 무언가를 확인하는 것은 플래그를 반환하는 함수 호출 입니다.
if(!Function_of_checking_if_a_position(symbol, OP_BUY,magic)) Function_opening_position(symbol, OP_BUY,Lots,stop_loss,take_profit,magic,comment);
if(!Function_of_checking_position_existence(symbol, OP_SELL,magic)) Function_opening_position(symbol, OP_SELL,Lots,stop_loss,take_profit,magic,comment);
글쎄, 내가 "포함하지 않음"에 대해 이야기할 때 실수가 있었습니다. 이 기능은 Trade.mqh 포함 상자에 있습니다.
괜찮아요. 닫힌 반대편
일반적으로 5-rka는 매우 인상적이었습니다. 특히 거래에 필요한 것들. 결말은 일반적으로 한 번에 작성되었습니다. 신호를 더 길게 만듭니다.
4-rka에서,이 관점에서 볼 때 더 나빠지는 것 같습니다 ....
그리고 멀티 화폐라는 사실이 사랑스럽습니다.
브라보 개발자 여러분! //처음으로 전환은 정확히 1일이었습니다.
여기서 첫째, 코드를 따라 더 나아가 주문이 있는지 다시 확인해야 하는 경우 함수를 다시 호출해야 합니다. 그리고 변수에 값을 저장하면 추가 없이 추가로 전송할 수 있습니다. 함수 호출. 둘째, 취향의 문제입니다. 특히 여러 조건이 있거나 많은 인수가 함수에 전달되는 경우 복잡한 구성을 구분하는 것을 좋아하지 않습니다. 코드에 대한 이해를 저해합니다.
마켓에서 완료하는 것은 불가능합니다.
2 차트에서는 당기지 않습니다. 마땅한 조건을 찾지 못하기 때문입니다. 주문이 0개일 때 2가지 방향으로 주문을 엽니다. 하지만 2가지 방향이 작동해야 합니다.
질문에 따르면 더 이상 필요한 것은 없습니다.
프로젝트가 확장되고 있습니다.
Artyom Trishkin :
하나의 차트에서 작동해야 하고 두 번째 차트(간단한 두 위치를 여는 차트)에서 작동해야 합니다. 그것을 하는 방법은 이미 당신에게 알려졌습니다.
당신은 충분하지 않습니다. 안녕
프로젝트가 확장되고 있습니다. 우리는 미래에 대해 생각하려고 노력해야 합니다.
네, 과학에 감사드립니다. 무슨 생각을 하게 될지...
추신. 그런 다음 검사를 조건이 아니라 변수로 반환하고 이미 검사하는 것을 방지하는 것은 무엇입니까? 아마도 미래에 이 프로젝트 의 가장 거친 복잡성 ...
그리고 한 가지 더: 프로젝트가 확장되면 코드 실행 시간이 늘어날 수 있습니다. 변수에 데이터를 입력하면 더 많은 계산이 수행됩니다. 따라서 재확인이 필요할 때까지 주문이 이미 종료되고(예: stop, ... 또는 take ...) 프로그램이 잘못된 값을 고려하는 일이 발생할 수 있습니까? 변하기 쉬운?
맞습니다. 큰 프로젝트와 발생할 수 있는 모든 가능한 상황에 대해 미리 생각해야 합니다. 그래서 저는 항상 최신 데이터를 사용 하기 직전에 가지고 있다는 신념을 고수할 것입니다. 가능한 한 많이.
le0nid2014 :
당신은 충분하지 않습니다. 안녕