표시기의 색상을 프로그래밍 방식으로 설정하는 기능이 없는 것은 버그가 아니라 아키텍처의 기능입니다.
표시기는 그리기와 계산의 두 부분으로 나뉩니다. 표시기의 그리기 부분은 계산된 버퍼의 설정에 따라 그리기를 담당합니다. 계산 부분은 그에 따라 버퍼를 고려합니다. 표시기의 그리기 부분은 차트에 있으며 GUI 스레드에서 작동합니다. 표시기의 계산 부분은 기호 기간 캐시에 있으며 기호 업데이트 스레드에서 작동합니다.
표시기의 계산 부분은 그리기 부분에 대해 아무것도 모릅니다. 전문가는 지표의 계산된 부분으로 독점적으로 작업합니다(대부분의 경우 도면 부분이 없음).
Expert Advisor에서 생성한 지표의 그리기 부분은 차트에 지표를 추가하는 명령(수동이든 ChartIndicatorAdd이든 상관없이)을 호출한 경우에만 나타납니다. 예를 들어, 동일한 지표가 있는 동일한 기간 기호의 여러 차트가 열려 있는 경우 여러 도면 부분이 지표의 동일한 계산 부분에 액세스할 수 있습니다.
요약. 표시기의 계산 부분은 0에서 99까지의 도면 부분을 "가질" 수 있습니다. 표시기의 계산 부분은 얼마나 많은 도면 부분을 그리는지 모릅니다.
방금 공식적으로 확인된 버그에 대해 설명했습니다. 이 문제를 해결하기 위해 일종의 API를 사용하도록 제안한 사람이 바로 당신이었습니다.
표시기 생성 과 iCustom을 통한 호출을 혼동하지 마십시오.
따라서 현실과 환상을 혼동하지 마십시오. 이것은 버그가 아닙니다. 어떤 API이고 생각할 필요도 없습니다. 그리고 당신은 어떤 목적으로 여기에 있습니까?
탬버린으로 춤을 마칠 수 있습니다.
SD는 다음 빌드에서 OrderSend()가 정상적으로 작동할 것이라고 대답했습니다. :)
정말 효과가 있었던 것 같습니다. 1550에 대한 업데이트가 방금 도착하여 확인했습니다. OrderSend() 직후 에 위치를 열면 전체 환경이 동기화됩니다.
1550에 대한 업데이트가 방금 도착하여 확인했습니다. OrderSend() 직후 에 위치를 열면 전체 환경이 동기화됩니다.
나는 OrderSend가 완전히 동기화되었음을 확인합니다. 브레이크 버그가 남아 있습니다.
요청/응답
Request.action = TRADE_ACTION_REMOVE ( 8 )
Request.magic = 0
Request.order = 136746576
Request.symbol =
Request.volume = 0.0
Request.price = 0.0
Request.stoplimit = 0.0
Request.sl = 0.0
Request.tp = 0.0
Request.deviation = 0
Request.type = ORDER_TYPE_BUY ( 0 )
Request.type_filling = ORDER_FILLING_FOK ( 0 )
Request.type_time = ORDER_TIME_GTC ( 0 )
Request.expiration = 1970.01 . 01 00 : 00 : 00
Request.comment =
Request.position = 0
Request.position_by = 0
Result.retcode = 10009
Result.deal = 0
Result.order = 136746576
Result.volume = 0.0
Result.price = 0.0
Result.bid = 0.0
Result.ask = 0.0
Result.comment = Request executed 2194.767 + 0.003 ms
Result.request_id = 245
Result.retcode_external = 0
결과
JM 0 22:37:34.308 Trades '5338170': accepted cancel order #136746576 buy limit 0.10 #AA at 36.99
FE 0 22:37:34.308 Trades '5338170': cancel #136746576 buy limit 0.10 #AA at market done in 2194.779 ms
흥미롭게도 OrderSend 실행 기간은 이제 실제보다 더 많이 로그에 기록됩니다. 저것들. OrderSend의 실행 시간을 직접 측정하면 매번 로그에 표시된 값보다 몇 밀리초 미만이 됩니다.
ZY 그런 기록이 있었다
따라서 현실과 환상을 혼동하지 마십시오. 이것은 버그가 아닙니다. 어떤 API이며 생각할 필요도 없습니다. 그리고 당신은 어떤 목적으로 여기에 있습니까?
그렇다면 이 문제를 해결하는 코드는 어디에 있습니까?
개발자는 이미 이것이 버그이며 해결책이 없음을 확인했습니다.
자기소개: 저는 2009년부터 이곳에 있었고 완전한 매크로와 B'1001011' 구조가 MQL5에 대한 제 제안입니다.
그렇다면 이 문제를 해결하는 코드는 어디에 있습니까?
개발자는 이미 이것이 버그이며 해결책이 없음을 확인했습니다.
무슨 버그? 어디서 확인되나요?
템플릿을 읽고 쓰는 데 API가 필요하지 않습니다. MQL5를 통해 모든 것이 정상입니다. 4개에서는 https://www.mql5.com/ru/forum/168767/page14#comment_4122244 도 했습니다.
무슨 버그? 어디서 확인되나요?
템플릿을 읽고 쓰는 데 API가 필요하지 않습니다. MQL5를 통해 모든 것이 정상입니다. 4개에서는 https://www.mql5.com/ru/forum/168767/page14#comment_4122244 도 했습니다.
일반적으로 우리는 템플릿에 대해 이야기하는 것이 아니라 표시기의 프로그래밍 방식 첨부에 대해 이야기하고 있지만 자체 색상의 표시기 선을 설치하는 것입니다. 위의 이 친구는 자신의 색상을 설정할 수 없는 것이 버그라고 생각합니다.
표시기의 색상을 프로그래밍 방식으로 설정하는 기능이 없는 것은 버그가 아니라 아키텍처의 기능입니다.
표시기는 그리기와 계산의 두 부분으로 나뉩니다. 표시기의 그리기 부분은 계산된 버퍼의 설정에 따라 그리기를 담당합니다. 계산 부분은 그에 따라 버퍼를 고려합니다. 표시기의 그리기 부분은 차트에 있으며 GUI 스레드에서 작동합니다. 표시기의 계산 부분은 기호 기간 캐시에 있으며 기호 업데이트 스레드에서 작동합니다.
표시기의 계산 부분은 그리기 부분에 대해 아무것도 모릅니다. 전문가는 지표의 계산된 부분으로 독점적으로 작업합니다(대부분의 경우 도면 부분이 없음).
Expert Advisor에서 생성한 지표의 그리기 부분은 차트에 지표를 추가하는 명령(수동이든 ChartIndicatorAdd이든 상관없이)을 호출한 경우에만 나타납니다. 예를 들어, 동일한 지표가 있는 동일한 기간 기호의 여러 차트가 열려 있는 경우 여러 도면 부분이 지표의 동일한 계산 부분에 액세스할 수 있습니다.
요약. 표시기의 계산 부분은 0에서 99까지의 도면 부분을 "가질" 수 있습니다. 표시기의 계산 부분은 얼마나 많은 도면 부분을 그리는지 모릅니다.
...