그런 헛소리가 많이 있습니다. 2005년 8월 MT4 출시와 함께 지그재그 인디케이터가 등장했습니다. 거기에는 많은 실수가 있습니다. 그는 터미널을 패스트 마켓에서 한 번에 걸 수 있었습니다. 그리고 그는 종종 막대의 저점/고점에 묶이지 않고 허공에 극한값을 표시했습니다.
어느 쪽지에서 이 지그재그 개발자는 이것이 (감정없이 더 받아주세요) 이것이 퍼지 논리의 표현이라고 말했습니다........
하지만 MT4가 철수한지 14년이 지난 지금도 지그재그 인디케이터 에는 아무런 동작도 일으키지 않는 편차(Deviation)라는 매개변수가 있습니다. 즉, 이 매개변수의 값을 아무리 설정해도 차트의 지그재그 그리기는 바뀌지 않습니다.
수많은 프로그램이 이 지표를 기반으로 합니다. 대부분의 개발자는 프로그램에 이 매개변수를 포함합니다. 단서없는 매개 변수. 그리고 개발자들은 단순히 이것에 대한 환상적인 무관심입니다. 그런데 매개 변수는 컴퓨터 리소스를 먹습니다.
공중에 매달려 있는 지그재그 극한값은 시계열에 액세스할 때 가지고 있는 것과 공통된 특성을 가지고 있습니다.
MT4에서는 시계열에 대한 액세스 거부가 없었습니다. 일부 기능이 제대로 작동하지 않았습니다(지금도 작동할 수 있음). 내부 사용에 대한 설명을 들었습니다. 자신의 방식대로 억지로 하기도 했다. 그리고 프로세서에 부하가 걸리지 않고 모든 것이 오류없이 작동하기 시작했습니다. 수십 개의 지그재그를 차트에 표시해도 터미널이 멈 춥니 다 ...
논리가 터미널 사용자가 마스터할 준비가 된 것보다 더 복잡하다는 것이 밝혀졌을 뿐입니다. 네, 그리고 아마도 오류가 있을 수 있지만 개발자가 그것을 찾는 것은 여가 시간이 아니며 누구도 사용자로부터 복제하고 증명하고 싶어하지 않습니다.
Andrei, 나는 우리가 가진 것에서 진행할 것을 제안합니다. 그리고 우리는 당신이 말하는 것을 가지고 있기 때문에 이야기하는 것이 더 낫습니까, 아니면 여전히 돌아 다니는 것이 더 낫습니까?
나는 문제가 충분하다고 생각하지만 분기에서 분기로 이야기하는 것보다 (이것도 유용합니다-때로는 수정됨) 우회합니다.
나는 완전한 가용성의 순간에 필요한 시계열을 캐시하는 좋은 옵션을 제안했습니다. 그런 다음 - 기성품 및 항상 사용 가능한 시계열에서 필요한 모든 데이터를 수신합니다. 그리고 새로운 데이터로 보완하십시오. 동시에 사용할 수 있을 때 천천히 그리고 필요한 순간에 반드시 그런 것은 아닙니다.
그래서 최소한 일이 움직일 것입니다. 그리고 나중에 할 일이 없을 때 대화를 남길 수 있습니다.
공중에 매달려 있는 지그재그 극한값은 시계열에 액세스할 때 가지고 있는 것과 공통된 특성을 가지고 있습니다.
MT4에서는 시계열에 대한 액세스 거부가 없었습니다. 일부 기능이 제대로 작동하지 않았습니다(지금도 작동할 수 있음). 내부 사용에 대한 설명을 들었습니다. 그것도 억지로 했다. 그리고 프로세서에 부하가 걸리지 않고 모든 것이 오류없이 작동하기 시작했습니다. 수십 개의 지그재그를 차트에 표시해도 터미널이 멈 춥니 다 ...
시계열에 대한 액세스가 거부되면 동기화 단계에 있음을 의미합니다. 다음 틱까지 기다려야 합니다.
귀하의 상황에서는 시계열을 캐시하는 것이 더 좋습니다. 시계열은 항상 기다리지 않고 첫 번째 요청에서 사용할 수 있습니다.
표시기가 실행되는 순간의 캐시 - "동기화 대기" 시간이 있고 대기하는 동안 다음 시계열의 데이터를 요청합니다.
Andrei, 나는 우리가 가진 것에서 진행할 것을 제안합니다. 그리고 우리는 당신이 말하는 것을 가지고 있기 때문에 이야기하는 것이 더 낫습니까, 아니면 여전히 돌아 다니는 것이 더 낫습니까?
나는 문제가 충분하다고 생각하지만 분기에서 분기로 이야기하는 것보다 (이것도 유용합니다-때로는 수정됨) 우회합니다.
나는 완전한 가용성의 순간에 필요한 시계열을 캐시하는 좋은 옵션을 제안했습니다. 그런 다음 - 기성품 및 항상 사용 가능한 시계열에서 필요한 모든 데이터를 수신합니다. 그리고 새로운 데이터로 보완하십시오. 동시에 사용할 수 있을 때 천천히 그리고 필요한 순간에 반드시 그런 것은 아닙니다.
그래서 최소한 일이 움직일 것입니다. 그리고 나중에 할 일이 없을 때 대화를 남길 수 있습니다.
그런 다음 개발자가 수정할 수 있도록 재현 가능한 예제를 만드는 것이 이미 더 효율적입니다.
Andrei, 나는 우리가 가진 것에서 진행할 것을 제안합니다. 그리고 우리는 당신이 말하는 것을 가지고 있기 때문에 이야기하는 것이 더 낫습니까, 아니면 여전히 돌아 다니는 것이 더 낫습니까?
나는 문제가 충분하다고 생각하지만 지점에서 지점으로 문제에 대해 이야기하는 것보다 (이것도 유용합니다-때로는 문제를 해결함) 우회합니다.
나는 완전한 가용성의 순간에 필요한 시계열을 캐시하는 좋은 옵션을 제안했습니다. 그런 다음 - 기성품 및 항상 사용 가능한 시계열에서 필요한 모든 데이터를 수신합니다. 그리고 새로운 데이터로 보완하십시오. 동시에 사용할 수 있을 때 천천히 그리고 필요한 순간에 반드시 그런 것은 아닙니다.
그래서 최소한 일이 움직일 것입니다. 그리고 나중에 할 일이 없을 때 대화를 남길 수 있습니다.
터미널 개발자는 왜 이것을 할 수 없습니까? 어쨌든 시계열 업데이트 시에는 시계열에 대한 액세스 권한이 없습니다. 모든 사람이 캐시된 기록에 액세스할 수 있도록 합니다. 이것으로부터 무엇이 바뀔까요? 즉, 액세스가 중단되지 않도록 합니다. 글쎄요, 아마도 제로 바에 약간의 지연이 있을 것입니다. 나머지 이야기는 항상 사용할 수 있습니다.
나는 완전한 가용성의 순간에 필요한 시계열을 캐시하는 좋은 옵션을 제안했습니다. 그런 다음 - 기성품 및 항상 사용 가능한 시계열에서 필요한 모든 데이터를 수신합니다. 그리고 새로운 데이터로 보완하십시오.
이것은 나쁜 옵션입니다. 터미널에서 시계열을 빌드하고 동기화하는 논리를 완전히 반복해야 합니다. 그런 다음 새 틱이 오고 동기화가 끝나지 않았습니다... 그런 다음 연결이 끊어졌습니다.
추신: 그리고 왜 합니까? -누군가는 모르겠고 핸드폰도 하나, 차도 하나 있고 지갑도 하나 가지고 다니는데 인생에 케이스가 많다? - 보험이 필요합니까? ...."녹음기 3대, 외국 필름 카메라 3대, 국산 담배 케이스 3대, 자켓...스웨이드...삼대. 자켓"))))
Artyom Trishkin :
시계열에 대한 액세스가 거부되면 동기화 단계에 있음을 의미합니다. 다음 틱까지 기다려야 합니다.
모든 것이 정확합니다! 그러나 MQL 프로그램의 계산을 아무 곳에서나 중지하고 다음 틱 전에 터미널로 종료해야 합니다. 델파이에서 "Abort() 또는 Halt()"와 같은 것을 주기적으로 제안합니다. - 시계열 액세스에 오류가 한 번 발생했습니다. 이것은 터미널이 MQL 프로그램과 상호 작용을 설정할 때까지 여러 번 처리하는 것이 의미가 없는 치명적인 오류 입니다. "사업이 없을 것입니다" )))
추신: 이 오류(시계열 액세스 오류)를 생성하지 않습니다. - 터미널에 의해 생성되지만 모든 MQL 프로그래머는 터미널에서 생성된 오류를 완벽하게 분류할 준비가 되어 있어야 합니다 ???... 예(코드가 다음과 같을 때 몇백줄) 원칙적으로 이기기 쉽고 코드가 크고 프로그램의 다른 부분에서 시계열에 대한 액세스를 사용하는 것이 편리할 때 - 그리고 ? 프로그램의 일부를 종료하고 이전 계산을 잃지 않는 999가지 방법을 생성해야 합니까? - 네, 가능합니다만, 소스코드를 작성하게 될 명확한 계획(알고리즘)이 필요하고... 그리고 기성품 기능(클래스)을 추가하여 소스코드가 완성된다면? - 즉. 매번 내부에 무엇이 들어 있는지 알아낼 필요가 있습니다 ... 모든 것을 제공하기 위해 일반적으로 큰 프로젝트의 힘든 작업, IMHO
Igor Makanu : ... 모든 것을 예측하기 위한 대규모 프로젝트의 경우 일반적으로 힘든 작업, IMHO
14년 동안 만든 프로그램이라면 새로운 디자인 방식으로 번역하면 더 쉽게 자신을 촬영할 수 있다. 그리고 다중 연결을 디버깅하는 것도 어렵습니다. 시간 프레임에 대한 가용성을 확인하면 액세스가 부족한 경우 심각한 지연이 발생합니다. 자동 그래픽 구성 이 켜져 있으면 좋을 것입니다. 자동 모드에서 구조 조정은 드문 현상입니다. 여기서 지연을 알 수 없습니다. 사실, 이 경우에도 시계열에 대한 액세스가 중단되면 그래픽 구성이 잘린 형태로 표시되는 경우가 있습니다. 일부 요소는 구축할 시간이 있지만 일부는 그렇지 않습니다... 또는 일부 TF에 대해 프랙탈 필터링에 의한 가지치기가 있습니다.
14년 동안 만든 프로그램이라면 새로운 디자인 방식으로 번역하면 더 쉽게 자신을 촬영할 수 있다. 그리고 다중 연결을 디버깅하는 것도 어렵습니다. 시간 프레임에 대한 가용성을 확인하면 액세스가 부족한 경우 심각한 지연이 발생합니다. 자동 그래픽 구성 이 켜져 있으면 좋을 것입니다. 자동 모드에서 구조 조정은 드문 현상입니다. 여기서 지연을 알 수 없습니다.
그러나 문제는 구성이 그래픽 인터페이스를 통해 수행될 때입니다. 사용자가 버튼을 누르고... 다음 틱을 기다려야 합니다. 또는 원하는 프로그램 반응이 나타날 때까지 버튼을 여러 번 누르십시오. 유저들의 반응은?... -***
그러나 MT4에는 그러한 문제가 없습니다.
나는 당신을 완벽하게 이해합니다. 그래서 토론을 지원하기로 결정했습니다.
글쎄, 그리고 한 가지 더 제안: 얼마 전에 우리는 시계열 iClose()..iXXX()에 접근하기 위한 함수를 추가했습니다 - 훌륭합니다!
이것들을 동기 함수로 둡니다. 시계열에 대한 액세스는 더 오래 걸릴 수 있지만 터미널 수준에서 보장되거나 uv.developers는 터미널이 기록 데이터( OHLC )에 대한 액세스를 제공할 준비가 된 경우에만 MQL 프로그램에 틱을 제공하는 사전 컴파일러 지시문을 추가합니다. 준비되지 않은 경우 틱이 없습니다. 이 프리컴파일러 지시문을 사용자가 포함하도록 합니다.
....
그러나 목표는 동일합니다. 사용자가 OHLC 차트의 준비 상태를 끝없이 확인하지 않도록 하기 위해 이 문제는 MQL 프로그램 내부의 확인 수준에서만 MT5의 출현 이후로 해결되었습니다. 이것은 힘든 과정이며 제 생각에는 사용자는 문제 없이 터미널에서 기대하며 코드 시계열 데이터의 모든 부분에서 언제든지 수신을 보장합니다.
이것은 나쁜 옵션입니다. 터미널에서 시계열을 빌드하고 동기화하는 논리를 완전히 반복해야 합니다. 그런 다음 새 틱이 오고 동기화가 끝나지 않았습니다... 그런 다음 연결이 끊어졌습니다.
추신: 그리고 왜 합니까? -누군가는 모르겠고 핸드폰도 하나, 차도 하나 있고 지갑도 하나 가지고 다니는데 인생에 케이스가 많다? - 보험이 필요합니까? ...."녹음기 3대, 외국 필름 카메라 3대, 국산 담배 케이스 3대, 자켓...스웨이드...삼대. 자켓"))))
모든 것이 정확합니다! 그러나 MQL 프로그램의 계산을 아무 곳에서나 중지하고 다음 틱 전에 터미널로 종료해야 합니다. 델파이에서 "Abort() 또는 Halt()"와 같은 것을 주기적으로 제안합니다. - 시계열 액세스에 오류가 한 번 발생했습니다. 이것은 터미널이 MQL 프로그램과 상호 작용을 설정할 때까지 여러 번 처리하는 것이 의미가 없는 치명적인 오류 입니다. "사업이 없을 것입니다" )))
추신: 이 오류(시계열 액세스 오류)를 생성하지 않습니다. - 터미널에 의해 생성되지만 모든 MQL 프로그래머는 터미널에서 생성된 오류를 완벽하게 분류할 준비가 되어 있어야 합니다 ???... 예(코드가 다음과 같을 때 몇백줄) 원칙적으로 이기기 쉽고 코드가 크고 프로그램의 다른 부분에서 시계열에 대한 액세스를 사용하는 것이 편리할 때 - 그리고 ? 프로그램의 일부를 종료하고 이전 계산을 잃지 않는 999가지 방법을 생성해야 합니까? - 네, 가능합니다만, 소스코드를 작성하게 될 명확한 계획(알고리즘)이 필요하고... 그리고 기성품 기능(클래스)을 추가하여 소스코드가 완성된다면? - 즉. 매번 내부에 무엇이 들어 있는지 알아낼 필요가 있습니다 ... 모든 것을 제공하기 위해 일반적으로 큰 프로젝트의 힘든 작업, IMHO
프로그램 작업이 마우스 클릭으로 정렬된 경우 액세스가 있거나 아직 없는 경우에는 중요하지 않습니다. 반응해야 합니다. 모든 것이 어떻게 잘못되었는지에 대해 많이 쓸 수 있지만, 이 경우 항상 요청 시 액세스할 수 있는 자체 캐시를 갖는 것이 좋습니다.
마우스 클릭으로 오랜 시간 계산된 과거 데이터에 대해 무언가를 제공하는 대신 지금 필요하지 않은 현재 데이터를 얻고 시계열을 다시 작성하는 동안 ...
당신이 좋아하는 것을 말하지만 우리가 가지고 있는 것으로 만들어야 한다면 캐시에 있는 것을 제공하고 시계열에 대한 액세스를 잠금 해제한 후 다시 빌드하는 것이 좋습니다.
넌센스 - 터미널에서 이미 사용 가능한 데이터 사본 구성.
그런 헛소리가 많이 있습니다. 2005년 8월 MT4 출시와 함께 지그재그 인디케이터가 등장했습니다. 거기에는 많은 실수가 있습니다. 그는 터미널을 패스트 마켓에서 한 번에 걸 수 있었습니다. 그리고 그는 종종 막대의 저점/고점에 묶이지 않고 허공에 극한값을 표시했습니다.
어느 쪽지에서 이 지그재그 개발자는 이것이 (감정없이 더 받아주세요) 이것이 퍼지 논리의 표현이라고 말했습니다........
하지만 MT4가 철수한지 14년이 지난 지금도 지그재그 인디케이터 에는 아무런 동작도 일으키지 않는 편차(Deviation)라는 매개변수가 있습니다. 즉, 이 매개변수의 값을 아무리 설정해도 차트의 지그재그 그리기는 바뀌지 않습니다.
수많은 프로그램이 이 지표를 기반으로 합니다. 대부분의 개발자는 프로그램에 이 매개변수를 포함합니다. 단서없는 매개 변수. 그리고 개발자들은 단순히 이것에 대한 환상적인 무관심입니다. 그런데 매개 변수는 컴퓨터 리소스를 먹습니다.
그리고 다른 여러 경우에도 그러한 순간이 많이 있었습니다.
나는 계속할 것이다.
공중에 매달려 있는 지그재그 극한값은 시계열에 액세스할 때 가지고 있는 것과 공통된 특성을 가지고 있습니다.
MT4에서는 시계열에 대한 액세스 거부가 없었습니다. 일부 기능이 제대로 작동하지 않았습니다(지금도 작동할 수 있음). 내부 사용에 대한 설명을 들었습니다. 자신의 방식대로 억지로 하기도 했다. 그리고 프로세서에 부하가 걸리지 않고 모든 것이 오류없이 작동하기 시작했습니다. 수십 개의 지그재그를 차트에 표시해도 터미널이 멈 춥니 다 ...
모든 것이 효과가 있었다면 이 문제에 대한 백만 가지 주제가 없었을 것입니다.
논리가 터미널 사용자가 마스터할 준비가 된 것보다 더 복잡하다는 것이 밝혀졌을 뿐입니다.
네, 그리고 아마도 오류가 있을 수 있지만 개발자가 그것을 찾는 것은 여가 시간이 아니며 누구도 사용자로부터 복제하고 증명하고 싶어하지 않습니다.
Andrei, 나는 우리가 가진 것에서 진행할 것을 제안합니다. 그리고 우리는 당신이 말하는 것을 가지고 있기 때문에 이야기하는 것이 더 낫습니까, 아니면 여전히 돌아 다니는 것이 더 낫습니까?
나는 문제가 충분하다고 생각하지만 분기에서 분기로 이야기하는 것보다 (이것도 유용합니다-때로는 수정됨) 우회합니다.
나는 완전한 가용성의 순간에 필요한 시계열을 캐시하는 좋은 옵션을 제안했습니다. 그런 다음 - 기성품 및 항상 사용 가능한 시계열에서 필요한 모든 데이터를 수신합니다. 그리고 새로운 데이터로 보완하십시오. 동시에 사용할 수 있을 때 천천히 그리고 필요한 순간에 반드시 그런 것은 아닙니다.
그래서 최소한 일이 움직일 것입니다. 그리고 나중에 할 일이 없을 때 대화를 남길 수 있습니다.
나는 계속할 것이다.
공중에 매달려 있는 지그재그 극한값은 시계열에 액세스할 때 가지고 있는 것과 공통된 특성을 가지고 있습니다.
MT4에서는 시계열에 대한 액세스 거부가 없었습니다. 일부 기능이 제대로 작동하지 않았습니다(지금도 작동할 수 있음). 내부 사용에 대한 설명을 들었습니다. 그것도 억지로 했다. 그리고 프로세서에 부하가 걸리지 않고 모든 것이 오류없이 작동하기 시작했습니다. 수십 개의 지그재그를 차트에 표시해도 터미널이 멈 춥니 다 ...
시계열에 대한 액세스가 거부되면 동기화 단계에 있음을 의미합니다. 다음 틱까지 기다려야 합니다.
귀하의 상황에서는 시계열을 캐시하는 것이 더 좋습니다. 시계열은 항상 기다리지 않고 첫 번째 요청에서 사용할 수 있습니다.
표시기가 실행되는 순간의 캐시 - "동기화 대기" 시간이 있고 대기하는 동안 다음 시계열의 데이터를 요청합니다.
Andrei, 나는 우리가 가진 것에서 진행할 것을 제안합니다. 그리고 우리는 당신이 말하는 것을 가지고 있기 때문에 이야기하는 것이 더 낫습니까, 아니면 여전히 돌아 다니는 것이 더 낫습니까?
나는 문제가 충분하다고 생각하지만 분기에서 분기로 이야기하는 것보다 (이것도 유용합니다-때로는 수정됨) 우회합니다.
나는 완전한 가용성의 순간에 필요한 시계열을 캐시하는 좋은 옵션을 제안했습니다. 그런 다음 - 기성품 및 항상 사용 가능한 시계열에서 필요한 모든 데이터를 수신합니다. 그리고 새로운 데이터로 보완하십시오. 동시에 사용할 수 있을 때 천천히 그리고 필요한 순간에 반드시 그런 것은 아닙니다.
그래서 최소한 일이 움직일 것입니다. 그리고 나중에 할 일이 없을 때 대화를 남길 수 있습니다.
그런 다음 개발자가 수정할 수 있도록 재현 가능한 예제를 만드는 것이 이미 더 효율적입니다.
Andrei, 나는 우리가 가진 것에서 진행할 것을 제안합니다. 그리고 우리는 당신이 말하는 것을 가지고 있기 때문에 이야기하는 것이 더 낫습니까, 아니면 여전히 돌아 다니는 것이 더 낫습니까?
나는 문제가 충분하다고 생각하지만 지점에서 지점으로 문제에 대해 이야기하는 것보다 (이것도 유용합니다-때로는 문제를 해결함) 우회합니다.
나는 완전한 가용성의 순간에 필요한 시계열을 캐시하는 좋은 옵션을 제안했습니다. 그런 다음 - 기성품 및 항상 사용 가능한 시계열에서 필요한 모든 데이터를 수신합니다. 그리고 새로운 데이터로 보완하십시오. 동시에 사용할 수 있을 때 천천히 그리고 필요한 순간에 반드시 그런 것은 아닙니다.
그래서 최소한 일이 움직일 것입니다. 그리고 나중에 할 일이 없을 때 대화를 남길 수 있습니다.
터미널 개발자는 왜 이것을 할 수 없습니까? 어쨌든 시계열 업데이트 시에는 시계열에 대한 액세스 권한이 없습니다. 모든 사람이 캐시된 기록에 액세스할 수 있도록 합니다. 이것으로부터 무엇이 바뀔까요? 즉, 액세스가 중단되지 않도록 합니다. 글쎄요, 아마도 제로 바에 약간의 지연이 있을 것입니다. 나머지 이야기는 항상 사용할 수 있습니다.
나는 완전한 가용성의 순간에 필요한 시계열을 캐시하는 좋은 옵션을 제안했습니다. 그런 다음 - 기성품 및 항상 사용 가능한 시계열에서 필요한 모든 데이터를 수신합니다. 그리고 새로운 데이터로 보완하십시오.
이것은 나쁜 옵션입니다. 터미널에서 시계열을 빌드하고 동기화하는 논리를 완전히 반복해야 합니다. 그런 다음 새 틱이 오고 동기화가 끝나지 않았습니다... 그런 다음 연결이 끊어졌습니다.
추신: 그리고 왜 합니까? -누군가는 모르겠고 핸드폰도 하나, 차도 하나 있고 지갑도 하나 가지고 다니는데 인생에 케이스가 많다? - 보험이 필요합니까? ...."녹음기 3대, 외국 필름 카메라 3대, 국산 담배 케이스 3대, 자켓...스웨이드...삼대. 자켓"))))
시계열에 대한 액세스가 거부되면 동기화 단계에 있음을 의미합니다. 다음 틱까지 기다려야 합니다.
모든 것이 정확합니다! 그러나 MQL 프로그램의 계산을 아무 곳에서나 중지하고 다음 틱 전에 터미널로 종료해야 합니다. 델파이에서 "Abort() 또는 Halt()"와 같은 것을 주기적으로 제안합니다. - 시계열 액세스에 오류가 한 번 발생했습니다. 이것은 터미널이 MQL 프로그램과 상호 작용을 설정할 때까지 여러 번 처리하는 것이 의미가 없는 치명적인 오류 입니다. "사업이 없을 것입니다" )))
추신: 이 오류(시계열 액세스 오류)를 생성하지 않습니다. - 터미널에 의해 생성되지만 모든 MQL 프로그래머는 터미널에서 생성된 오류를 완벽하게 분류할 준비가 되어 있어야 합니다 ???... 예(코드가 다음과 같을 때 몇백줄) 원칙적으로 이기기 쉽고 코드가 크고 프로그램의 다른 부분에서 시계열에 대한 액세스를 사용하는 것이 편리할 때 - 그리고 ? 프로그램의 일부를 종료하고 이전 계산을 잃지 않는 999가지 방법을 생성해야 합니까? - 네, 가능합니다만, 소스코드를 작성하게 될 명확한 계획(알고리즘)이 필요하고... 그리고 기성품 기능(클래스)을 추가하여 소스코드가 완성된다면? - 즉. 매번 내부에 무엇이 들어 있는지 알아낼 필요가 있습니다 ... 모든 것을 제공하기 위해 일반적으로 큰 프로젝트의 힘든 작업, IMHO
14년 동안 만든 프로그램이라면 새로운 디자인 방식으로 번역하면 더 쉽게 자신을 촬영할 수 있다. 그리고 다중 연결을 디버깅하는 것도 어렵습니다. 시간 프레임에 대한 가용성을 확인하면 액세스가 부족한 경우 심각한 지연이 발생합니다. 자동 그래픽 구성 이 켜져 있으면 좋을 것입니다. 자동 모드에서 구조 조정은 드문 현상입니다. 여기서 지연을 알 수 없습니다. 사실, 이 경우에도 시계열에 대한 액세스가 중단되면 그래픽 구성이 잘린 형태로 표시되는 경우가 있습니다. 일부 요소는 구축할 시간이 있지만 일부는 그렇지 않습니다... 또는 일부 TF에 대해 프랙탈 필터링에 의한 가지치기가 있습니다.
***
14년 동안 만든 프로그램이라면 새로운 디자인 방식으로 번역하면 더 쉽게 자신을 촬영할 수 있다. 그리고 다중 연결을 디버깅하는 것도 어렵습니다. 시간 프레임에 대한 가용성을 확인하면 액세스가 부족한 경우 심각한 지연이 발생합니다. 자동 그래픽 구성 이 켜져 있으면 좋을 것입니다. 자동 모드에서 구조 조정은 드문 현상입니다. 여기서 지연을 알 수 없습니다.
그러나 문제는 구성이 그래픽 인터페이스를 통해 수행될 때입니다. 사용자가 버튼을 누르고... 다음 틱을 기다려야 합니다. 또는 원하는 프로그램 반응이 나타날 때까지 버튼을 여러 번 누르십시오. 유저들의 반응은?... -***
그러나 MT4에는 그러한 문제가 없습니다.
나는 당신을 완벽하게 이해합니다. 그래서 토론을 지원하기로 결정했습니다.
글쎄, 그리고 한 가지 더 제안: 얼마 전에 우리는 시계열 iClose()..iXXX()에 접근하기 위한 함수를 추가했습니다 - 훌륭합니다!
이것들을 동기 함수로 둡니다. 시계열에 대한 액세스는 더 오래 걸릴 수 있지만 터미널 수준에서 보장되거나 uv.developers는 터미널이 기록 데이터( OHLC )에 대한 액세스를 제공할 준비가 된 경우에만 MQL 프로그램에 틱을 제공하는 사전 컴파일러 지시문을 추가합니다. 준비되지 않은 경우 틱이 없습니다. 이 프리컴파일러 지시문을 사용자가 포함하도록 합니다.
....
그러나 목표는 동일합니다. 사용자가 OHLC 차트의 준비 상태를 끝없이 확인하지 않도록 하기 위해 이 문제는 MQL 프로그램 내부의 확인 수준에서만 MT5의 출현 이후로 해결되었습니다. 이것은 힘든 과정이며 제 생각에는 사용자는 문제 없이 터미널에서 기대하며 코드 시계열 데이터의 모든 부분에서 언제든지 수신을 보장합니다.
이것은 나쁜 옵션입니다. 터미널에서 시계열을 빌드하고 동기화하는 논리를 완전히 반복해야 합니다. 그런 다음 새 틱이 오고 동기화가 끝나지 않았습니다... 그런 다음 연결이 끊어졌습니다.
추신: 그리고 왜 합니까? -누군가는 모르겠고 핸드폰도 하나, 차도 하나 있고 지갑도 하나 가지고 다니는데 인생에 케이스가 많다? - 보험이 필요합니까? ...."녹음기 3대, 외국 필름 카메라 3대, 국산 담배 케이스 3대, 자켓...스웨이드...삼대. 자켓"))))
모든 것이 정확합니다! 그러나 MQL 프로그램의 계산을 아무 곳에서나 중지하고 다음 틱 전에 터미널로 종료해야 합니다. 델파이에서 "Abort() 또는 Halt()"와 같은 것을 주기적으로 제안합니다. - 시계열 액세스에 오류가 한 번 발생했습니다. 이것은 터미널이 MQL 프로그램과 상호 작용을 설정할 때까지 여러 번 처리하는 것이 의미가 없는 치명적인 오류 입니다. "사업이 없을 것입니다" )))
추신: 이 오류(시계열 액세스 오류)를 생성하지 않습니다. - 터미널에 의해 생성되지만 모든 MQL 프로그래머는 터미널에서 생성된 오류를 완벽하게 분류할 준비가 되어 있어야 합니다 ???... 예(코드가 다음과 같을 때 몇백줄) 원칙적으로 이기기 쉽고 코드가 크고 프로그램의 다른 부분에서 시계열에 대한 액세스를 사용하는 것이 편리할 때 - 그리고 ? 프로그램의 일부를 종료하고 이전 계산을 잃지 않는 999가지 방법을 생성해야 합니까? - 네, 가능합니다만, 소스코드를 작성하게 될 명확한 계획(알고리즘)이 필요하고... 그리고 기성품 기능(클래스)을 추가하여 소스코드가 완성된다면? - 즉. 매번 내부에 무엇이 들어 있는지 알아낼 필요가 있습니다 ... 모든 것을 제공하기 위해 일반적으로 큰 프로젝트의 힘든 작업, IMHO
프로그램 작업이 마우스 클릭으로 정렬된 경우 액세스가 있거나 아직 없는 경우에는 중요하지 않습니다. 반응해야 합니다. 모든 것이 어떻게 잘못되었는지에 대해 많이 쓸 수 있지만, 이 경우 항상 요청 시 액세스할 수 있는 자체 캐시를 갖는 것이 좋습니다.
마우스 클릭으로 오랜 시간 계산된 과거 데이터에 대해 무언가를 제공하는 대신 지금 필요하지 않은 현재 데이터를 얻고 시계열을 다시 작성하는 동안 ...
당신이 좋아하는 것을 말하지만 우리가 가지고 있는 것으로 만들어야 한다면 캐시에 있는 것을 제공하고 시계열에 대한 액세스를 잠금 해제한 후 다시 빌드하는 것이 좋습니다.