그러나 가치가 있는지 여부는 추측해야 합니다. 유추하여 "다른 모든 전문가도 수신을 중지하므로 한 전문가가 이벤트 수신을 취소하는 것으로 충분합니다"라고 계속 말합니까? 나는 이것이 될 수 없으며 버그 일 것입니다 (또는 버그 일 것입니다).
첫째, 확인하기 쉽습니다. 내가 직접 했을 수도 있지만 FORTS 계정만 있고 주말에는 닫혀 있습니다.
그러나 그렇다면 상황이 웃기게 나타납니다. 표시기인 Expert Advisor를 켰고 구독이 작동했습니다. 전문가 또는 지표의 연결이 끊어졌습니다. 이미 구독이 떨어졌다고 썼습니다. 이것은 방송이 여전히 그 반대의 방식으로 작동하고 있음을 시사합니다. 이제 무언가가 변경되었다고 상상해 보십시오(예: 기록이 변경되고 표시기가 다시 계산됨). 그러나 OnInit 및 OnDeinit는 임의로 호출할 수 있음을 알고 있습니다. 때로는 맞고 때로는 그 반대입니다. 차트가 지표의 새 버전을 먼저 호출한 다음 이전 버전을 제거하면 어떻게 됩니까? 구독이 취소됩니다. 이것은 "조용히 덤프"와 유사합니다. 주문서에 대한 견적 수신이 중단되는 경우 주문 및 메시지를 확인하기 위해 OnInit 및 OnDeinit에 인쇄물을 넣는 것이 좋습니다. 아마도 문제가 해결될 것입니다.
이벤트 브로드캐스팅의 개념은 한 가지이지만 이벤트 구독 및 구독 취소를 위한 함수의 쌍을 호출하는 원리는 별개입니다. 이들은 필요하지 않은 의미 기술에서 독립적이며 이상적으로는 서로 영향을 미치지 않아야 합니다. 이벤트가 방송되게 하십시오(확실히 이것은 효율성을 이유로 수행되었지만 이것은 매우 논란의 여지가 있으며 잘못 구현될 경우 현재 문제를 일으킬 수 있음). 이것은 이벤트가 모든 것을 수신하기 시작하도록 구독하는 것으로 충분하다는 것을 의미합니다. 그러나 반대 방향으로-구독을 취소하는 것으로 충분하고 모든 사람을 위한 크란트가 있습니다-이것은 이미 일종의 편협함입니다.
이것은 매우 중요하지만(그리고 방송에 대한 문구는 위의 이유에 대한 설명이 아니지만) 문서에 구독자 카운터에 대한 단어가 없습니다. 참고로 방송은 구독자 수가 0이 될 때까지 계속되어야 합니다. 그렇지 않으면 MQL 프로그램(다른 개발자의 프로그램 포함)이 작업에 지장을 주지 않기 위해 어떻게든 서로 통신해야 할 것이 분명하지만 이것은 넌센스다. 구독이 이런 방식으로 구현되는 소프트웨어 예(가장 넓은 의미에서 MT, Windows 등에 국한되지 않음)에 대해 알지 못합니다.
MarketBookRelease에 대한 다음 구절이 있습니다.
Обычно эта функция должна вызываться из функции OnDeinit() в том случае, если в функции OnInit() была вызвана соответствующая функция MarketBookAdd().
다시 말하지만, 그것은 모호합니다. 이는 구독 수를 제어하는 것으로 해석될 수 있습니다. 그러나 소프트웨어는 사적인 해석을 허용하지 않습니다.
전체적으로 IMHO는 구현이 레이크(MQL 수준에서 확인하고 재구독해야 함)이고 문서가 흐릿합니다. 악의적이거나 완전히 잘못된 코드가 카운터를 사용하더라도 다른 사람의 구독을 죽일 수 있다는 주장은 완전히 관련이 없습니다. 이러한 모든 스크립트는 터미널의 다른 여러 위치에 해를 끼칠 수 있습니다(예: 다른 사람의 개체 삭제, 다른 사람의 위치에서 중지 등 이미 백만 번 발생). 그렇게 솔직하게 돼지 발현에 대해 이야기하는 것은 무의미합니다. 사용자 징계, 다른 사람의 코드 교정(있는 경우) 또는 데모에서 확인하는 것 외에는 막을 수 없습니다. 이제 문제는 올바르게 작성된 코드가 이제 정상적으로 실행될 수 없다는 것입니다.
이 메커니즘이 올바르게 수행되었다면 물론 아무도 게시자/구독자 패턴을 취소하지 않았습니다. 그것은 확실히 성능에 영향을 미치지 않을 것입니다.
"한 명의 Expert Advisor가 이벤트 수신을 취소하는 것으로 충분하며 다른 모든 Expert Advisor도 수신을 중지합니다."
그러나 가치가 있는지 여부는 추측해야 합니다. 유추하여 "다른 모든 전문가도 수신을 중지하므로 한 전문가가 이벤트 수신을 취소하는 것으로 충분합니다"라고 계속 말합니까? 나는 이것이 될 수 없으며 버그 일 것입니다 (또는 버그 일 것입니다).
첫째, 확인하기 쉽습니다. 내가 직접 했을 수도 있지만 FORTS 계정만 있고 주말에는 닫혀 있습니다.
그러나 그렇다면 상황이 웃기게 나타납니다. 표시기인 Expert Advisor를 켰고 구독이 작동했습니다. 전문가 또는 지표의 연결이 끊어졌습니다. 이미 구독이 떨어졌다고 썼습니다. 이것은 방송이 여전히 그 반대의 방식으로 작동하고 있음을 시사합니다. 이제 무언가가 변경되었다고 상상해 보십시오(예: 기록이 변경되고 표시기가 다시 계산됨). 그러나 OnInit 및 OnDeinit는 임의로 호출할 수 있음을 알고 있습니다. 때로는 맞고 때로는 그 반대입니다. 차트가 지표의 새 버전을 먼저 호출한 다음 이전 버전을 제거하면 어떻게 됩니까? 구독이 취소됩니다. 이것은 "조용히 덤프"와 유사합니다. 주문서에 대한 견적 수신이 중단되는 경우 주문 및 메시지를 확인하기 위해 OnInit 및 OnDeinit에 인쇄물을 넣는 것이 좋습니다. 아마도 문제가 해결될 것입니다.
첫째, 확인하기 쉽습니다. 내가 직접 했을 수도 있지만 FORTS 계정만 있고 주말에는 닫혀 있습니다.
계정을 확인하는 것은 전혀 필요하지 않습니다. CHARTEVENT_OBJECT_CREATE 같은 방송 이벤트
이것은 생각할 필요가 없습니다
불분명. 언제든지 링크 카운터를 추가할 수 있습니다.
불분명. 언제든지 링크 카운터를 추가할 수 있습니다.
카운터가 없습니다. 만약 그렇다면, 문서는 그 존재와 Add\Release에 대한 한 쌍의 호출의 허용 가능성을 명시적으로 나타낼 것입니다. 그렇지 않으면 카운터가 잘못되어 존재의 의미가 손실될 것입니다.
그리고 링크 카운터가 필요하다고 말하면 ... 더 나아가 방송을 완전히 취소 할 수 있습니다.
카운터가 없습니다. 만약 그렇다면, 문서는 그 존재와 Add\Release에 대한 한 쌍의 호출의 허용 가능성을 명시적으로 나타낼 것입니다. 그렇지 않으면 카운터가 잘못되어 존재의 의미가 손실될 것입니다.
자, 이제 해제 기능의 의미가 사라졌습니다. 누구든지 이벤트 구독을 취소할 수 있는 논리는 미친 논리이기 때문에
MarketBookRelease 기능을 사용하지 않는 간단한 제안이 있습니다.
이론적으로 이것은 터미널 및 서버 리소스의 일부를 낭비하게 됩니다.
그러나 실제로는... 이것으로 인한 실제 결과가 있습니까?
자, 이제 해제 기능의 의미가 사라졌습니다. 누구든지 이벤트 구독을 취소할 수 있는 논리는 미친 논리이기 때문에
고슴도치의 경우 설명하는 것은 무의미하므로 나머지는 ;-).
이벤트 브로드캐스팅의 개념은 한 가지이지만 이벤트 구독 및 구독 취소를 위한 함수의 쌍을 호출하는 원리는 별개입니다. 이들은 필요하지 않은 의미 기술에서 독립적이며 이상적으로는 서로 영향을 미치지 않아야 합니다. 이벤트가 방송되게 하십시오(확실히 이것은 효율성을 이유로 수행되었지만 이것은 매우 논란의 여지가 있으며 잘못 구현될 경우 현재 문제를 일으킬 수 있음). 이것은 이벤트가 모든 것을 수신하기 시작하도록 구독하는 것으로 충분하다는 것을 의미합니다. 그러나 반대 방향으로-구독을 취소하는 것으로 충분하고 모든 사람을 위한 크란트가 있습니다-이것은 이미 일종의 편협함입니다.
이것은 매우 중요하지만(그리고 방송에 대한 문구는 위의 이유에 대한 설명이 아니지만) 문서에 구독자 카운터에 대한 단어가 없습니다. 참고로 방송은 구독자 수가 0이 될 때까지 계속되어야 합니다. 그렇지 않으면 MQL 프로그램(다른 개발자의 프로그램 포함)이 작업에 지장을 주지 않기 위해 어떻게든 서로 통신해야 할 것이 분명하지만 이것은 넌센스다. 구독이 이런 방식으로 구현되는 소프트웨어 예(가장 넓은 의미에서 MT, Windows 등에 국한되지 않음)에 대해 알지 못합니다.
MarketBookRelease에 대한 다음 구절이 있습니다.
Обычно эта функция должна вызываться из функции OnDeinit() в том случае, если в функции OnInit() была вызвана соответствующая функция MarketBookAdd() .
다시 말하지만, 그것은 모호합니다. 이는 구독 수를 제어하는 것으로 해석될 수 있습니다. 그러나 소프트웨어는 사적인 해석을 허용하지 않습니다.
전체적으로 IMHO는 구현이 레이크(MQL 수준에서 확인하고 재구독해야 함)이고 문서가 흐릿합니다. 악의적이거나 완전히 잘못된 코드가 카운터를 사용하더라도 다른 사람의 구독을 죽일 수 있다는 주장은 완전히 관련이 없습니다. 이러한 모든 스크립트는 터미널의 다른 여러 위치에 해를 끼칠 수 있습니다(예: 다른 사람의 개체 삭제, 다른 사람의 위치에서 중지 등 이미 백만 번 발생). 그렇게 솔직하게 돼지 발현에 대해 이야기하는 것은 무의미합니다. 사용자 징계, 다른 사람의 코드 교정(있는 경우) 또는 데모에서 확인하는 것 외에는 막을 수 없습니다. 이제 문제는 올바르게 작성된 코드가 이제 정상적으로 실행될 수 없다는 것입니다.
이 메커니즘이 올바르게 수행되었다면 물론 아무도 게시자/구독자 패턴을 취소하지 않았습니다. 그것은 확실히 성능에 영향을 미치지 않을 것입니다.