라이브러리: 캘린더 - 페이지 2

[Stanislav Korotky]

fxsaber:

모든 HTML 캘린더( 표준 캘린더 및 터미널 포함)에서 삼중(실제, 예상, 이전) = (실제, 예상, 수정)입니다. 따라서 다음 해당 이벤트가 발생할 때까지 기록에서 수정됨 필드를 사용할 수 없습니다. 다른 필드는 사용할 수 있습니다.

로컬 캘린더 API를 사용해 본 적이 없는데 문서에 미흡한 점이 많아서 좀 더 논리적인 라이브러리가 필요할 것 같습니다. 지정된 change_id에서 시작하는 이벤트 변경 사항 배열을 쿼리할 수 없나요? 어떤 이유에서인지 시간 기반이 아닙니다. 안타깝게도 이러한 질문은 라이브러리가 아닌 캘린더 자체에 대한 것이지만 라이브러리가 캘린더 위에 있기 때문에 라이브러리에 대해서도 열려 있습니다. 변경 사항의 문제는 외부 캘린더를 사용하는 과거 관행에서 일부 필드를 소급하여 조정할 수 있다는 것을 알았으므로 변경 연대기를 고려하여 테스트해야한다는 것입니다.

이전 = 개정 된 방법(MqlCalendarValue 구조에는 실제, 이전, 개정, 예측의 4 가지 필드가 모두 있음)과 기록에서 개정을 사용할 수없는 이유를 이해하지 못합니다. 즉, 마지막 이벤트 릴리스와 다음 이벤트 사이의 어느 순간에 (이전이 개정 된 경우) 개정 된 것이 나타날 수 있습니다 (즉, 기록에만).

[fxsaber]

Stanislav Korotky:

로컬 캘린더 API를 사용해 본 적이 없는데 문서가 많이 부족합니다(따라서 더 논리적인 라이브러리가 필요할 것 같습니다). 지정된 change_id에서 시작하는 이벤트 변경 사항 배열을 쿼리할 수 없나요? 어떤 이유에서인지 시간 제한이 없습니다.

캘린더의 각 변경사항에는 고유한 change_id가 있습니다. 따라서 특정 change_id부터 현재 change_id까지의 모든 변경 내용을 쿼리할 수 있습니다.

이전 = 개정 된 방법(MqlCalendarValue 구조에는 실제, 이전, 개정, 예측의 4 가지 필드가 모두 있음)과 기록에 개정 된 것을 사용할 수없는 이유를 이해하지 못합니다. 즉, 마지막 이벤트 릴리스와 다음 이벤트 릴리스 사이의 모든 순간에 (이전이 개정 된 경우) 개정 된 것이 기록에 나타날 수 있습니다.

캘린더에서는 이벤트에 대해 3개의 필드만 볼 수 있습니다. API에서는 4개가 있습니다. 수정됨은 가장 최근에 수정된 값으로, 실제가 접수된 후 일주일 후에도 올 수 있습니다. 이것이 백테스트에서 Revised를 사용하는 것이 다소 논리적으로 금지된 이유입니다.

저는 편리한 캘린더 사용 시나리오를 다소 좁게 봅니다. 자신 만의 옵션이 있다면 목소리를 내십시오. 아마도 라이브러리에 시나리오에 최적이 아닌 API가있을 수 있습니다. 그러면 우리는 그것에 대해 생각할 것입니다.

주제는 아주 새로운 것 같습니다.

[traveller00]

GMT 함수가 있지만 사용되지 않는 것 같습니다. 꼭 필요한 기능인지 모르겠습니다.

[fxsaber]

traveller00:
GMT 함수가 있지만 사용되지 않는 것 같습니다. 거기에서 필요한지 모르겠습니다.

미래를 위해 남겨둔 기능입니다. 달력은 서버 시간에 묶여 있고 외부에서 가져올 수 있기 때문입니다.

[Aleksey Mavrin]

fxsaber:

나는 캘린더를 편리하게 사용할 수있는 다소 좁은 시나리오를 봅니다. 자신만의 변형이 있다면 말씀해 주세요. 아마도 라이브러리에 시나리오에 최적이 아닌 API가있을 수 있습니다. 그러면 그것에 대해 생각해 보겠습니다.

주제는 아주 새로운 것 같습니다.

MT 캘린더 기능에 대한 설명으로 판단하면 모든 변경 사항을 모니터링하고 구독별로 새 이벤트가 도착하고 실제, 수정 된 변경 사항이 포함 된 관찰자와 같은 것을 작성해야합니다.

그러면 편리할 것 같습니다.

[fxsaber]

Aleksey Mavrin:

MT 캘린더 기능에 대한 설명으로 판단하면 모든 변경 사항을 모니터링하고 구독에 새로운 이벤트가 도착하고 실제, 수정 된 값의 변경 사항을 모니터링하는 관찰자와 같은 것을 기록해야합니다.

용어로는 이해가 되지 않습니다.

[Andrey Khatimlianskii]

fxsaber:

용어적으로는 이해가 되지 않습니다.

https://refactoring.guru/ru/design-patterns/observer

[fxsaber]

Andrey Khatimlianskii:

https://refactoring.guru/ru/design-patterns/observer

고마워요. OnCalendar에 대해 이야기하고 있다면 change_id 메커니즘을 통한 일종의 시뮬레이션이 될 것입니다.

물론 회로도 코드로 애플리케이션 시나리오를 시연하는 것이 좋습니다.

[Aleksey Mavrin]

fxsaber:

고마워요. 온캘린더에 대해 이야기하는 경우 change_id-mechanism을 통한 시뮬레이션이 있을 것입니다.

향후 MT5에 도입 될 수있는 캘린더 이벤트 시뮬레이션에 대해 이야기하고 있습니다.

언제든지 변경될 수 있으므로 수정된 변경을 포함하여 관심 있는 이벤트에 대한 구독 메커니즘을 언급하고 있었습니다.

옵저버 패턴에 익숙하지 않다면 안드레이의 링크를 참고하시기 바랍니다.

아이디어의 본질은 간단히 말해서 다음과 같습니다:

거래를 위해 중요도가 3보다 높은 모든 EUR 이벤트를 알아야 합니다. 공급자( 구독 및 알림을 관리하는 클래스의 객체, 게시자라고도 함)에 신청하고 구독합니다.

그런 다음 공급자 자체에서 관심 있는 이벤트의 모든 변경 사항을 모니터링하고 해당 정보로 이벤트 처리 메서드를 호출하여 알려줍니다 (해당 정보로 이벤트 처리 메서드 호출).

[fxsaber]

Aleksey Mavrin:

아이디어의 요지는 간단히 말하자면 다음과 같습니다:

거래를 위해 중요도가 3보다 높은 모든 EUR 이벤트를 알아야 합니다. 공급자( 구독 및 알림을 관리하는 클래스의 객체, 게시자라고도 함)에 연락하여 구독을 신청합니다.

그런 다음 공급자 자체에서 관심 있는 이벤트의 모든 변경 사항을 모니터링하고 해당 정보로 이벤트 처리 메서드를 호출하여 알려줍니다(해당 정보 포함).

사용자 지정 객체는 해당 호출 없이는 스스로를 확인할 수 없습니다. 즉, 사용자가 자신의 코드에 작성해야 합니다. 사용자가 작성했다면 처리는 사용자가 직접 수행합니다.

change_id 메커니즘은 매우 간단합니다. 새로 고침 메서드를 실행하면 됩니다. 그 후 생성한 이벤트 목록에서 업데이트된 데이터, 내용 및 위치를 확인할 수 있습니다.

CALENDAR Calendar;

Calendar.Set(...); // 추적할 이벤트 목록을 지정합니다.

if (Calendar.Refresh(...)) // 목록에서 업데이트된 항목이 있으면 원하는 대로 처리합니다.