나는 분명히 썼습니다. 사본으로 전송하는 데 필요한 데이터를 항상 최신 상태로 유지하십시오. init에서만 이 작업을 수행할 필요는 없으며 항상 최신 상태로 유지하십시오.
Andrey, 당신은 모든 손실과 함께 표시기 사본의 파괴로 인해 시간 프레임을 변경할 때 표시기의 변수 및 배열에 저장된 모든 현재 데이터가 무의미해진다는 것을 농담하거나 정말로 이해하지 못합니다. 물론 전문가의 경우 모든 것이 간단하기 때문입니다. 재초기화는 없습니다.
Andrey, 당신은 모든 손실과 함께 표시기 사본의 소멸로 인해 시간 프레임을 변경할 때 표시기의 변수 및 배열에 저장된 모든 현재 데이터가 무의미해진다는 것을 농담하거나 정말로 이해하지 못합니다. 물론 전문가의 경우 모든 것이 간단하기 때문입니다. 재초기화는 없습니다.
아니, 농담이 아니야.
당신은 내가 말한 것을 이해하지 못합니다.
예를 들어, 지표의 다른 복사본으로 전송해야 하는 특정 데이터 세트가 있습니다(차트에 던져진 다른 지표인지 또는 기간 변경 시 지표의 새 복사본인지 여부는 중요하지 않음). 지표는 자체적으로 무언가를 고려하고, 무언가를 계산할 때마다 동시에 이것이 다른 지표와 공유하기 위한 것이므로 이 지표는 업데이트되어야 합니다. 매번. 이 데이터베이스는 데이터의 양과 필요한 데이터 전송 속도에 따라 다른 위치에 저장할 수 있습니다. 이 데이터 업데이트는 초기화할 때뿐만 아니라 이 데이터를 변경한 후 필요할 때마다 수행해야 합니다. 그게 요점입니다. 복잡하지 않습니다. 지표의 지역 변수 에 데이터를 저장하는 것은 문제가 없으며, 이 데이터가 다시 계산될 때마다 데이터를 삭제/업데이트하는 것입니다.
예를 들어, 지표의 다른 복사본으로 전송해야 하는 특정 데이터 세트가 있습니다(차트에 던져진 다른 지표인지 또는 기간 변경 시 지표의 새 복사본인지 여부는 중요하지 않음). 지표는 자체적으로 무언가를 고려하고, 무언가를 계산할 때마다 동시에 이것이 다른 지표와 공유하기 위한 것이므로 이 지표는 업데이트되어야 합니다. 매번. 이 데이터베이스는 데이터의 양과 필요한 데이터 전송 속도에 따라 다른 위치에 저장할 수 있습니다. 이 데이터 업데이트는 초기화할 때뿐만 아니라 이 데이터를 변경한 후 필요할 때마다 수행해야 합니다. 그게 요점입니다. 복잡하지 않습니다. 지표의 지역 변수 에 데이터를 저장하는 것은 문제가 없으며, 이 데이터가 다시 계산될 때마다 데이터를 삭제/업데이트하는 것입니다.
그리고 그래픽 개체를 사용하면 매우 간단합니다. 씹을 필요도 없습니다.
복잡하지 않은 것에 대한 매우 논쟁의 여지가 있는 질문입니다. 이 제품에서 구현한 간단한 마우스의 예를 실제로 반복해 보십시오. 마우스에서는 마우스로 기간을 변경한 다음 시간대를 변경할 때 변경 사항을 저장해야 하며 창에서 이러한 여러 표시기를 사용할 수 있습니다. 그리고 당신은 복잡한 것에 대해 이해할 것입니다. 그리고 배열을 전달해야 하는 경우. 그리고 그것이 얼마나 "단순한지" 이해하게 될 것입니다. 아마도 이미 구현하지 않았더라면 나 자신도 그렇게 생각했을 것입니다.
복잡하지 않은 것에 대한 매우 논쟁의 여지가 있는 질문입니다. 이 제품에서 구현한 간단한 마우스의 예를 실제로 반복해 보십시오. 마우스에서는 마우스로 기간을 변경한 다음 시간대를 변경할 때 변경 사항을 저장해야 하며 창에서 이러한 여러 표시기를 사용할 수 있습니다. 그리고 당신은 복잡한 것에 대해 이해할 것입니다. 그리고 배열을 전달해야 하는 경우. 그리고 당신은 그것이 얼마나 "단순한지" 이해하게 될 것입니다.
나는 최근에 EA에서 모든 변수가 재초기화 중에 저장된다는 것을 알았습니다. 조언자들도 같은 방식으로 썼다. 프로그램이 다른 프로그램에 대해 아무것도 모른다는 것을 암시하는 표시기 뿐만 아니라 그들의 init 및 deinit만 있기 때문에 프로그램은 다른 사람의 init 및 deinit에 대해 알 수 없습니다.
따라서 나는 언로드되고 다시 시작된 프로그램의 시간과 init 및 deinit 순서를 정하지 않았으며 가능하면 이 코드가 변경될 수 있다는 사실에 의존하지 않았습니다(1580년에 변경됨). 문서화되지 않은 버그 및 플랫폼 미래에 의존하는 경우 향후 역효과가 날 수 있습니다.
실제로는 사용자의 행동에 따라 시각화가 동적으로 변하는 제품도 있는데, 이벤트부터 파일을 통한 교환까지 모든 것을 사용합니다. 동시에 지표 차트에는 1보다 훨씬 많은 지표가 있는 것이 원칙입니다. 5에는 지표 버퍼가 무제한이고 시작 시 매개변수로 버퍼를 생성할 수 있기 때문입니다. 저것들. 우리는 창의적이고 유연한 접근 방식을 통해 문제를 해결하는 동시에 3가지 유형의 프로그램의 특성을 염두에 두어야 하며 플랫폼 개발자는 다른 문제에 비해 사소한 어려움보다 더 중요한 다른 문제에 대해 우려하고 있습니다. 플랫폼의 글로벌 작업.
플랫폼의 정말 중요한 단점이 있는데, 별로 거론되지 않거나 전혀 언급되지 않습니다. 이것은 "초정의의 순서"라는 터무니없는 문제보다 훨씬 더 중요합니다.
시간 프레임 전환이 중단되면 먼저 낮은(새) 시간 프레임에서 OnInit가 실행되고 더 높은(이전) 시간 프레임에서 OnDeinit가 실행됩니다.
스위치가 올라가면 그 반대입니다. 먼저 낮은(이전) 시간 프레임에서 OnDeinit를 실행한 다음 높은(새) 시간 프레임에서 OnInit를 실행합니다.
여기서 캐시는 더 낮은 시간 프레임에서 더 오래된 시간 프레임으로 처리된다는 점을 염두에 두어야 합니다.
정말 끔찍해요. 애플리케이션 프로그래머는 그러한 시스템에 대해 생각해서는 안 됩니다. 플랫폼은 내부적으로 캐시를 원하는 대로 처리할 수 있지만 MQL 수준에서는 잠재적인 부작용 없이 모든 것을 단일 이벤트 계약으로 투명하게 가져와야 합니다. 모든 사람이 스스로 문제를 우회할 수 있는 효율성 고려 사항 및 기회에 대한 모든 언급은 단순히 지지할 수 없습니다. 이 작업은 효율적이고 편리하게(일반적으로 이 갈퀴를 밟을 가능성을 제거함) 한 번에 모두 수행할 수 있습니다.
Stanislav Korotky : 정말 끔찍해요. 응용 프로그램 프로그래머는 그러한 시스템에 대해 생각해서는 안 됩니다. 플랫폼은 내부적으로 캐시를 원하는 대로 처리할 수 있지만 MQL 수준에서는 잠재적인 부작용 없이 모든 것을 단일 이벤트 계약으로 투명하게 가져와야 합니다. 모든 사람이 스스로 문제를 우회할 수 있는 효율성 고려 사항 및 기회에 대한 모든 언급은 단순히 지지할 수 없습니다. 이 작업은 효율적이고 편리하게(일반적으로 이 갈퀴를 밟을 가능성을 제거함) 한 번에 모두 수행할 수 있습니다.
맞습니다. 그러면 안됩니다. 예를 들어 Total Commander를 실행하십시오. Windows가 op.memory에서 TC 사본을 언로드/로드하는 "올바른" 순서를 처리하도록 Microsoft에서 요구하는 이유는 무엇입니까? 이것이 OS 문제입니까?
OS의 관심사는 TC가 다른 TC와 간섭하지 않고 메모리에서 수행하는 작업, 파일 교환 또는 더 친밀한 것 - 이것이 그들의 비즈니스, 프로그램이라는 것입니다.
중간 결과를 요약하고 위의 모든 내용을 요약하고 싶습니다. 따라서 MT5 빌드 1580(현재 빌드 1571)이 출시되기 전에 우리는 무엇을 가지고 있습니까?
지표에서는 Expert Advisors와 달리 " 이전 복사본에 대해 아무것도 모르는 지표의 새 복사본이 생성됨"으로 인해 기간을 변경할 때 모든 변수가 다시 초기화되고 OnDeinit의 실행 순서가 추가됩니다. 이전 시간 프레임과 새 시간 프레임의 OnInit는 TF를 "위" 또는 "아래로" 전환하는 것과 관계없이 예측할 수 없습니다(지금까지의 연습 은 Slava가 말한 것과 모순됨). 이와 관련하여 프로그래머는 많은 문제와 불확실성에 직면해 있습니다. 예를 들어: - OnInit에서 어떤 것에 대한 표시기를 생성할 때 이 주제를 읽지 않은 프로그래머는 객체를 생성하고, 그 이름을 가진 객체의 존재에 대해 객체를 생성하기 전에 논리적으로 확인합니다. 또한 논리적이기도 하며 OnDeinit에서 이 개체의 제거를 규정합니다. TF를 변경할 때 새로운 TF의 OnInit를 먼저 실행하면 객체의 존재를 확인하고 이미 존재하는 것으로 판명되고 생성되지 않기 때문에 이미 생성되었습니다. 이후 기존 TF의 OnDeinit를 수행하여 객체를 삭제한다. 혼란에 빠진 프로그래머. 내 개체는 어디에 있는데 왜 삭제되었습니까? 그는 다음에 TF를 변경할 때 OnInit과 OnDeinit의 실행 순서가 다를 때 개체가 삭제되지 않을 때 더 큰 혼미에 빠질 것입니다. 삭제되거나 삭제되지 않습니다. .... 오랜 연구 끝에 서비스 데스크에 대한 호소가 시작되고 포럼에서 이전에 대한 새로운 주제가 시작됩니다. 이것은 가장 단순한 상황입니다. 다른 사람들도 있을 것입니다. 이 기능은 설명서에 설명되어 있지 않으며 포럼에서만 읽을 수 있습니다. 이와 같은 것을 생성하고 TF를 변경할 때 표시기의 이전 복사본에서 새 매개변수로 일부 매개변수를 전달하려는 경우 초기화 및 초기화 해제 작업의 순서를 예측할 수 없기 때문에 OnDeinit를 사용할 수 없습니다. 제 생각에는 이 경우에 가장 좋은 해결책은 다음 도구를 사용하여 리소스를 통해 데이터(매개변수)를 전송하는것입니다 . 한 창에서 여러 개의 동일한 표시기를 사용하고 다른 복사본을 위해 전송해야 하는 데이터가 변경될 때마다 충돌 없는 리소스를 다시 초기화되지 않은 리소스에 저장해야 합니다. OnDeinit 사용의 무의미함 때문에 프로그램의 가능한 시간대 변경 시간은 알 수 없습니다. 나는 이것을 오래전에(예를 들어 이 제품 에서) 구현했기 때문에 내가 무슨 말을 하는지 압니다. 파일 및 전역 터미널 변수를 통한 데이터 전송 구현은 덜 성공적인 솔루션(IMHO)입니다.
새 빌드 1580이 출시되면 모든 것이 Slava가 말한 대로 되므로 작업이 단순화되지 않습니다. 표시기의 이전 사본의 초기화 해제는 새 사본의 초기화 후에 발생합니다. 그러나 불확실성은 없을 것입니다.
그럼에도 불구하고 개발자가 뭔가를 수정하려고 하기 때문에 이 문제에 주의를 기울였으면 하는 바램이 있습니다. 우리는 새로운 빌드를 기다리고 있습니다.
나는 문서에서 이 처리 기능을 언급하는 것이 필수라는 데 전적으로 동의합니다. 그렇지 않으면 새로 도착한 프로그래머가 이 문제를 접하고 솔루션을 찾기 위해 포럼에 올 것입니다. (왜, 터미널과 MQL 도크에서 즉시 알릴 수 있다면)
또한 로그에는 무슨 일이 일어나고 있는지 전체 그림이 표시되지 않고 일부만 표시된다는 문서를 추가하십시오. 전체 그림은 전체 로그를 참조하세요.
중간 결과를 요약하고 위의 모든 내용을 요약하고 싶습니다. 따라서 MT5 빌드 1580(현재 빌드 1571)이 출시되기 전에 우리는 무엇을 가지고 있습니까?
지표에서는 Expert Advisors와 달리 " 이전 복사본에 대해 아무것도 모르는 지표의 새 복사본이 생성됨"으로 인해 기간을 변경할 때 모든 변수가 다시 초기화되고 OnDeinit의 실행 순서가 추가됩니다. 이전 시간 프레임과 새 시간 프레임의 OnInit는 TF를 "위" 또는 "아래로" 전환하는 것과 관계없이 예측할 수 없습니다(지금까지의 연습 은 Slava가 말한 것과 모순됨). 이와 관련하여 프로그래머는 많은 문제와 불확실성에 직면해 있습니다. 예를 들어: - OnInit에서 어떤 것에 대한 표시기를 생성할 때 이 주제를 읽지 않은 프로그래머는 객체를 생성하고, 그 이름을 가진 객체의 존재에 대해 객체를 생성하기 전에 논리적으로 확인합니다. 또한 논리적이기도 하며 OnDeinit에서 이 개체의 제거를 규정합니다. TF를 변경할 때 새로운 TF의 OnInit를 먼저 실행하면 객체의 존재를 확인하고 이미 존재하는 것으로 판명되고 생성되지 않기 때문에 이미 생성되었습니다. 이후 기존 TF의 OnDeinit를 수행하여 객체를 삭제한다. 혼수상태에 빠진 프로그래머. 내 개체는 어디에 있는데 왜 삭제되었습니까? 그는 다음에 TF를 변경할 때 OnInit과 OnDeinit의 실행 순서가 다를 때 개체가 삭제되지 않을 때 더 큰 혼미에 빠질 것입니다. 삭제되거나 삭제되지 않습니다. .... 오랜 연구 끝에 서비스 데스크에 대한 호소가 시작되고 포럼에서 이전에 대한 새로운 주제가 시작됩니다. 이것은 가장 단순한 상황입니다. 다른 사람들도 있을 것입니다. 이 기능은 설명서에 설명되어 있지 않으며 포럼에서만 읽을 수 있습니다. 이와 같은 것을 생성하고 TF를 변경할 때 표시기의 이전 복사본에서 새 매개변수로 일부 매개변수를 전달하려는 경우 초기화 및 초기화 해제 작업의 순서를 예측할 수 없기 때문에 OnDeinit를 사용할 수 없습니다. 제 생각에는 이 경우에 가장 좋은 해결책은 다음 도구를 사용하여 리소스를 통해 데이터(매개변수)를 전송하는것입니다 . 한 창에서 여러 개의 동일한 표시기를 사용하고 다른 복사본을 위해 전송해야 하는 데이터가 변경될 때마다 충돌 없는 리소스를 다시 초기화되지 않은 리소스에 저장해야 합니다. OnDeinit 사용의 무의미함 때문에 프로그램의 가능한 시간대 변경 시간은 알 수 없습니다. 나는 이것을 오래전에(예를 들어 이 제품 에서) 구현했기 때문에 내가 무슨 말을 하는지 압니다. 파일 및 전역 터미널 변수를 통한 데이터 전송 구현은 덜 성공적인 솔루션(IMHO)입니다.
새 빌드 1580이 출시되면 모든 것이 Slava가 말한 대로 되므로 작업이 단순화되지 않습니다. 표시기의 이전 사본의 초기화 해제는 새 사본의 초기화 후에 발생합니다. 그러나 불확실성은 없을 것입니다.
그럼에도 불구하고 개발자가 뭔가를 수정하려고 하기 때문에 이 문제에 주의를 기울였으면 하는 바램이 있습니다. 우리는 새로운 빌드를 기다리고 있습니다.
여기에는 실제로 몇 가지 문제가 있습니다. 어드바이저는 시간대를 전환할 때 훌륭하게 작동하며 표시기는 동일한 상황에서 완전히 다른 방식으로 작동합니다.
Nikolai Semko : 이 문서화되지 않은 기능에 대해 알고 그래프를 사용하여 가장 간단한 경우만 처리하면 문제가 없습니다. 사물. 나는 이 기능을 모르는 사람들에 대해 이야기하고 있습니다. 포럼의 이 주제는 아주 적은 수의 프로그래머가 읽을 것이라고 생각하며 모든 뉘앙스를 찾는 데 시간을 들인 것이 유감스럽습니다 . 나는 그것을 이해하기 전에 그런 상황에 처한 적이 있습니다.
나는 분명히 썼습니다. 사본으로 전송하는 데 필요한 데이터를 항상 최신 상태로 유지하십시오. init에서만 이 작업을 수행할 필요는 없으며 항상 최신 상태로 유지하십시오.
Andrey, 당신은 모든 손실과 함께 표시기 사본의 파괴로 인해 시간 프레임을 변경할 때 표시기의 변수 및 배열에 저장된 모든 현재 데이터가 무의미해진다는 것을 농담하거나 정말로 이해하지 못합니다. 물론 전문가의 경우 모든 것이 간단하기 때문입니다. 재초기화는 없습니다.
Andrey, 당신은 모든 손실과 함께 표시기 사본의 소멸로 인해 시간 프레임을 변경할 때 표시기의 변수 및 배열에 저장된 모든 현재 데이터가 무의미해진다는 것을 농담하거나 정말로 이해하지 못합니다. 물론 전문가의 경우 모든 것이 간단하기 때문입니다. 재초기화는 없습니다.
아니, 농담이 아니야.
당신은 내가 말한 것을 이해하지 못합니다.
예를 들어, 지표의 다른 복사본으로 전송해야 하는 특정 데이터 세트가 있습니다(차트에 던져진 다른 지표인지 또는 기간 변경 시 지표의 새 복사본인지 여부는 중요하지 않음). 지표는 자체적으로 무언가를 고려하고, 무언가를 계산할 때마다 동시에 이것이 다른 지표와 공유하기 위한 것이므로 이 지표는 업데이트되어야 합니다. 매번. 이 데이터베이스는 데이터의 양과 필요한 데이터 전송 속도에 따라 다른 위치에 저장할 수 있습니다. 이 데이터 업데이트는 초기화할 때뿐만 아니라 이 데이터를 변경한 후 필요할 때마다 수행해야 합니다. 그게 요점입니다. 복잡하지 않습니다. 지표의 지역 변수 에 데이터를 저장하는 것은 문제가 없으며, 이 데이터가 다시 계산될 때마다 데이터를 삭제/업데이트하는 것입니다.
그리고 그래픽 개체를 사용하면 매우 간단합니다. 씹을 필요도 없습니다.
물론 전문가의 경우 모든 것이 간단하기 때문입니다. 재초기화는 없습니다.
아니, 농담이 아니야.
당신은 내가 말한 것을 이해하지 못합니다.
예를 들어, 지표의 다른 복사본으로 전송해야 하는 특정 데이터 세트가 있습니다(차트에 던져진 다른 지표인지 또는 기간 변경 시 지표의 새 복사본인지 여부는 중요하지 않음). 지표는 자체적으로 무언가를 고려하고, 무언가를 계산할 때마다 동시에 이것이 다른 지표와 공유하기 위한 것이므로 이 지표는 업데이트되어야 합니다. 매번. 이 데이터베이스는 데이터의 양과 필요한 데이터 전송 속도에 따라 다른 위치에 저장할 수 있습니다. 이 데이터 업데이트는 초기화할 때뿐만 아니라 이 데이터를 변경한 후 필요할 때마다 수행해야 합니다. 그게 요점입니다. 복잡하지 않습니다. 지표의 지역 변수 에 데이터를 저장하는 것은 문제가 없으며, 이 데이터가 다시 계산될 때마다 데이터를 삭제/업데이트하는 것입니다.
그리고 그래픽 개체를 사용하면 매우 간단합니다. 씹을 필요도 없습니다.
복잡하지 않은 것에 대한 매우 논쟁의 여지가 있는 질문입니다. 이 제품에서 구현한 간단한 마우스의 예를 실제로 반복해 보십시오. 마우스에서는 마우스로 기간을 변경한 다음 시간대를 변경할 때 변경 사항을 저장해야 하며 창에서 이러한 여러 표시기를 사용할 수 있습니다. 그리고 당신은 복잡한 것에 대해 이해할 것입니다. 그리고 배열을 전달해야 하는 경우. 그리고 그것이 얼마나 "단순한지" 이해하게 될 것입니다. 아마도 이미 구현하지 않았더라면 나 자신도 그렇게 생각했을 것입니다.
복잡하지 않은 것에 대한 매우 논쟁의 여지가 있는 질문입니다. 이 제품에서 구현한 간단한 마우스의 예를 실제로 반복해 보십시오. 마우스에서는 마우스로 기간을 변경한 다음 시간대를 변경할 때 변경 사항을 저장해야 하며 창에서 이러한 여러 표시기를 사용할 수 있습니다. 그리고 당신은 복잡한 것에 대해 이해할 것입니다. 그리고 배열을 전달해야 하는 경우. 그리고 당신은 그것이 얼마나 "단순한지" 이해하게 될 것입니다.
나는 최근에 EA에서 모든 변수가 재초기화 중에 저장된다는 것을 알았습니다. 조언자들도 같은 방식으로 썼다. 프로그램이 다른 프로그램에 대해 아무것도 모른다는 것을 암시하는 표시기 뿐만 아니라 그들의 init 및 deinit만 있기 때문에 프로그램은 다른 사람의 init 및 deinit에 대해 알 수 없습니다.
따라서 나는 언로드되고 다시 시작된 프로그램의 시간과 init 및 deinit 순서를 정하지 않았으며 가능하면 이 코드가 변경될 수 있다는 사실에 의존하지 않았습니다(1580년에 변경됨). 문서화되지 않은 버그 및 플랫폼 미래에 의존하는 경우 향후 역효과가 날 수 있습니다.
실제로는 사용자의 행동에 따라 시각화가 동적으로 변하는 제품도 있는데, 이벤트부터 파일을 통한 교환까지 모든 것을 사용합니다. 동시에 지표 차트에는 1보다 훨씬 많은 지표가 있는 것이 원칙입니다. 5에는 지표 버퍼가 무제한이고 시작 시 매개변수로 버퍼를 생성할 수 있기 때문입니다. 저것들. 우리는 창의적이고 유연한 접근 방식을 통해 문제를 해결하는 동시에 3가지 유형의 프로그램의 특성을 염두에 두어야 하며 플랫폼 개발자는 다른 문제에 비해 사소한 어려움보다 더 중요한 다른 문제에 대해 우려하고 있습니다. 플랫폼의 글로벌 작업.
플랫폼의 정말 중요한 단점이 있는데, 별로 거론되지 않거나 전혀 언급되지 않습니다. 이것은 "초정의의 순서"라는 터무니없는 문제보다 훨씬 더 중요합니다.
시간 프레임 전환이 중단되면 먼저 낮은(새) 시간 프레임에서 OnInit가 실행되고 더 높은(이전) 시간 프레임에서 OnDeinit가 실행됩니다.
스위치가 올라가면 그 반대입니다. 먼저 낮은(이전) 시간 프레임에서 OnDeinit를 실행한 다음 높은(새) 시간 프레임에서 OnInit를 실행합니다.
여기서 캐시는 더 낮은 시간 프레임에서 더 오래된 시간 프레임으로 처리된다는 점을 염두에 두어야 합니다.
정말 끔찍해요. 응용 프로그램 프로그래머는 그러한 시스템에 대해 생각해서는 안 됩니다. 플랫폼은 내부적으로 캐시를 원하는 대로 처리할 수 있지만 MQL 수준에서는 잠재적인 부작용 없이 모든 것을 단일 이벤트 계약으로 투명하게 가져와야 합니다. 모든 사람이 스스로 문제를 우회할 수 있는 효율성 고려 사항 및 기회에 대한 모든 언급은 단순히 지지할 수 없습니다. 이 작업은 효율적이고 편리하게(일반적으로 이 갈퀴를 밟을 가능성을 제거함) 한 번에 모두 수행할 수 있습니다.
맞습니다. 그러면 안됩니다. 예를 들어 Total Commander를 실행하십시오. Windows가 op.memory에서 TC 사본을 언로드/로드하는 "올바른" 순서를 처리하도록 Microsoft에서 요구하는 이유는 무엇입니까? 이것이 OS 문제입니까?
OS의 관심사는 TC가 다른 TC와 간섭하지 않고 메모리에서 수행하는 작업, 파일 교환 또는 더 친밀한 것 - 이것이 그들의 비즈니스, 프로그램이라는 것입니다.
"그렇게 생각해요!" (c) 미미노, 1977
중간 결과를 요약하고 위의 모든 내용을 요약하고 싶습니다. 따라서 MT5 빌드 1580(현재 빌드 1571)이 출시되기 전에 우리는 무엇을 가지고 있습니까?
지표에서는 Expert Advisors와 달리 " 이전 복사본에 대해 아무것도 모르는 지표의 새 복사본이 생성됨"으로 인해 기간을 변경할 때 모든 변수가 다시 초기화되고 OnDeinit의 실행 순서가 추가됩니다. 이전 시간 프레임과 새 시간 프레임의 OnInit는 TF를 "위" 또는 "아래로" 전환하는 것과 관계없이 예측할 수 없습니다(지금까지의 연습 은 Slava가 말한 것과 모순됨). 이와 관련하여 프로그래머는 많은 문제와 불확실성에 직면해 있습니다. 예를 들어:
- OnInit에서 어떤 것에 대한 표시기를 생성할 때 이 주제를 읽지 않은 프로그래머는 객체를 생성하고, 그 이름을 가진 객체의 존재에 대해 객체를 생성하기 전에 논리적으로 확인합니다. 또한 논리적이기도 하며 OnDeinit에서 이 개체의 제거를 규정합니다. TF를 변경할 때 새로운 TF의 OnInit를 먼저 실행하면 객체의 존재를 확인하고 이미 존재하는 것으로 판명되고 생성되지 않기 때문에 이미 생성되었습니다. 이후 기존 TF의 OnDeinit를 수행하여 객체를 삭제한다. 혼란에 빠진 프로그래머. 내 개체는 어디에 있는데 왜 삭제되었습니까? 그는 다음에 TF를 변경할 때 OnInit과 OnDeinit의 실행 순서가 다를 때 개체가 삭제되지 않을 때 더 큰 혼미에 빠질 것입니다. 삭제되거나 삭제되지 않습니다. .... 오랜 연구 끝에 서비스 데스크에 대한 호소가 시작되고 포럼에서 이전에 대한 새로운 주제가 시작됩니다.
이것은 가장 단순한 상황입니다. 다른 사람들도 있을 것입니다. 이 기능은 설명서에 설명되어 있지 않으며 포럼에서만 읽을 수 있습니다.
이와 같은 것을 생성하고 TF를 변경할 때 표시기의 이전 복사본에서 새 매개변수로 일부 매개변수를 전달하려는 경우 초기화 및 초기화 해제 작업의 순서를 예측할 수 없기 때문에 OnDeinit를 사용할 수 없습니다. 제 생각에는 이 경우에 가장 좋은 해결책은 다음 도구를 사용하여 리소스를 통해 데이터(매개변수)를 전송하는 것 입니다 . 한 창에서 여러 개의 동일한 표시기를 사용하고 다른 복사본을 위해 전송해야 하는 데이터가 변경될 때마다 충돌 없는 리소스를 다시 초기화되지 않은 리소스에 저장해야 합니다. OnDeinit 사용의 무의미함 때문에 프로그램의 가능한 시간대 변경 시간은 알 수 없습니다. 나는 이것을 오래전에(예를 들어 이 제품 에서) 구현했기 때문에 내가 무슨 말을 하는지 압니다. 파일 및 전역 터미널 변수를 통한 데이터 전송 구현은 덜 성공적인 솔루션(IMHO)입니다.
새 빌드 1580이 출시되면 모든 것이 Slava가 말한 대로 되므로 작업이 단순화되지 않습니다. 표시기의 이전 사본의 초기화 해제는 새 사본의 초기화 후에 발생합니다. 그러나 불확실성은 없을 것입니다.
그럼에도 불구하고 개발자가 뭔가를 수정하려고 하기 때문에 이 문제에 주의를 기울였으면 하는 바램이 있습니다.
우리는 새로운 빌드를 기다리고 있습니다.
나는 문서에서 이 처리 기능을 언급하는 것이 필수라는 데 전적으로 동의합니다. 그렇지 않으면 새로 도착한 프로그래머가 이 문제를 접하고 솔루션을 찾기 위해 포럼에 올 것입니다. (왜, 터미널과 MQL 도크에서 즉시 알릴 수 있다면)
또한 로그에는 무슨 일이 일어나고 있는지 전체 그림이 표시되지 않고 일부만 표시된다는 문서를 추가하십시오. 전체 그림은 전체 로그를 참조하세요.
나머지는 나중에...
중간 결과를 요약하고 위의 모든 내용을 요약하고 싶습니다. 따라서 MT5 빌드 1580(현재 빌드 1571)이 출시되기 전에 우리는 무엇을 가지고 있습니까?
지표에서는 Expert Advisors와 달리 " 이전 복사본에 대해 아무것도 모르는 지표의 새 복사본이 생성됨"으로 인해 기간을 변경할 때 모든 변수가 다시 초기화되고 OnDeinit의 실행 순서가 추가됩니다. 이전 시간 프레임과 새 시간 프레임의 OnInit는 TF를 "위" 또는 "아래로" 전환하는 것과 관계없이 예측할 수 없습니다(지금까지의 연습 은 Slava가 말한 것과 모순됨). 이와 관련하여 프로그래머는 많은 문제와 불확실성에 직면해 있습니다. 예를 들어:
- OnInit에서 어떤 것에 대한 표시기를 생성할 때 이 주제를 읽지 않은 프로그래머는 객체를 생성하고, 그 이름을 가진 객체의 존재에 대해 객체를 생성하기 전에 논리적으로 확인합니다. 또한 논리적이기도 하며 OnDeinit에서 이 개체의 제거를 규정합니다. TF를 변경할 때 새로운 TF의 OnInit를 먼저 실행하면 객체의 존재를 확인하고 이미 존재하는 것으로 판명되고 생성되지 않기 때문에 이미 생성되었습니다. 이후 기존 TF의 OnDeinit를 수행하여 객체를 삭제한다. 혼수상태에 빠진 프로그래머. 내 개체는 어디에 있는데 왜 삭제되었습니까? 그는 다음에 TF를 변경할 때 OnInit과 OnDeinit의 실행 순서가 다를 때 개체가 삭제되지 않을 때 더 큰 혼미에 빠질 것입니다. 삭제되거나 삭제되지 않습니다. .... 오랜 연구 끝에 서비스 데스크에 대한 호소가 시작되고 포럼에서 이전에 대한 새로운 주제가 시작됩니다.
이것은 가장 단순한 상황입니다. 다른 사람들도 있을 것입니다. 이 기능은 설명서에 설명되어 있지 않으며 포럼에서만 읽을 수 있습니다.
이와 같은 것을 생성하고 TF를 변경할 때 표시기의 이전 복사본에서 새 매개변수로 일부 매개변수를 전달하려는 경우 초기화 및 초기화 해제 작업의 순서를 예측할 수 없기 때문에 OnDeinit를 사용할 수 없습니다. 제 생각에는 이 경우에 가장 좋은 해결책은 다음 도구를 사용하여 리소스를 통해 데이터(매개변수)를 전송하는 것 입니다 . 한 창에서 여러 개의 동일한 표시기를 사용하고 다른 복사본을 위해 전송해야 하는 데이터가 변경될 때마다 충돌 없는 리소스를 다시 초기화되지 않은 리소스에 저장해야 합니다. OnDeinit 사용의 무의미함 때문에 프로그램의 가능한 시간대 변경 시간은 알 수 없습니다. 나는 이것을 오래전에(예를 들어 이 제품 에서) 구현했기 때문에 내가 무슨 말을 하는지 압니다. 파일 및 전역 터미널 변수를 통한 데이터 전송 구현은 덜 성공적인 솔루션(IMHO)입니다.
새 빌드 1580이 출시되면 모든 것이 Slava가 말한 대로 되므로 작업이 단순화되지 않습니다. 표시기의 이전 사본의 초기화 해제는 새 사본의 초기화 후에 발생합니다. 그러나 불확실성은 없을 것입니다.
그럼에도 불구하고 개발자가 뭔가를 수정하려고 하기 때문에 이 문제에 주의를 기울였으면 하는 바램이 있습니다.
우리는 새로운 빌드를 기다리고 있습니다.
여기에는 실제로 몇 가지 문제가 있습니다. 어드바이저는 시간대를 전환할 때 훌륭하게 작동하며 표시기는 동일한 상황에서 완전히 다른 방식으로 작동합니다.
이 문서화되지 않은 기능에 대해 알고 그래프를 사용하여 가장 간단한 경우만 처리하면 문제가 없습니다. 사물. 나는 이 기능을 모르는 사람들에 대해 이야기하고 있습니다. 포럼의 이 주제는 아주 적은 수의 프로그래머가 읽을 것이라고 생각하며 모든 뉘앙스를 찾는 데 시간을 들인 것이 유감스럽습니다 . 나는 그것을 이해하기 전에 그런 상황에 처한 적이 있습니다.