속도가 느려지는 이유는 무엇입니까? 표시가 비스듬하게 쓰여지지 않는 한. 일반적으로 작성된 표시기의 경우 DeInit는 상당한 시간이 걸립니다. 게다가, 스위칭 TF는 그렇게 빈번한 작업이 아니다. 일부 특히 심각한 경우(이것은 "잘못된" 표시기에 해당) TF를 변경할 때 1~2초 정도 기다릴 수 있습니다.
따라서 TF를 전환할 때 제동에 대한 논쟁은 의심의 여지가 없습니다. 또한 아직 구축되지 않은 TF로 전환할 때 다소 눈에 띄는 시간 지연도 감지됩니다. 그리고 아무도 터미널의 브레이크에 대해 울지 않습니다.
지표가 다릅니다. 브레이크도. 그리고 전부는 아닙니다 - 그들 자신과 소스 코드에 있습니다.
몇 초 동안 미소를 지었다. 인터페이스에서 수십 밀리 초가 느껴지면 즉시 불편 함이 나타납니다.
그리고 가장 중요한 것은 내 질문에 대한 답이 없다는 것입니다. 어떤 상황에서 그래프로 직접 작업하는 것을 제외하고. 개체(이름에 TF 이름 없음), DeInit - Init 시퀀스가 중요합니까?
지표가 다릅니다. 브레이크도 걸었다. 그리고 전부는 아닙니다 - 그들 자신과 소스 코드에 있습니다.
몇 초 동안 웃었습니다. 인터페이스에서 수십 밀리 초가 느껴지면 즉시 불편 함이 나타납니다.
그리고 가장 중요한 것은 내 질문에 대한 답이 없다는 것입니다. 어떤 상황에서 그래프로 직접 작업하는 것을 제외하고. 개체(이름에 TF 이름 없음), DeInit - Init 시퀀스가 중요합니까?
나는 일반적으로 전역 변수를 사용하지 않지만 가끔 이런 일이 발생합니다.
전역 변수로 작업할 때 도약을 얻습니다. 차트에서 지표를 삭제할 때 스스로 정리하고 전역 변수를 제거 해야 합니다. 지표에서 전역 변수를 삭제할 위치는 어디입니까? 아마 Deinite에서 삭제해야 할 것 같은데, 다른 곳이 생각나지 않습니다. 따라서 기간을 변경하고 새로운 변수를 생성하면 deinite가 와서 모든 것을 지웁니다. 글로벌 변수는 지표에서 사용할 수 없습니다.
전역 변수로 작업할 때 도약을 얻습니다. 차트에서 지표를 삭제할 때 스스로 정리하고 전역 변수를 제거 해야 합니다. 지표에서 전역 변수를 삭제할 위치는 어디입니까? 아마 Deinite에서 삭제해야 할 것 같은데, 다른 곳이 생각나지 않습니다. 따라서 기간을 변경하고 새로운 변수를 생성하면 deinite가 와서 모든 것을 지웁니다. 글로벌 변수는 지표에서 사용할 수 없습니다.
Sergey, 당신의 손가락에서 빨려 들어가지 않은 실제 예가 있습니까? 나는 또한 생각해 낼 수 있지만 실제로는 문제가 발생하지 않았습니다.
지표가 다릅니다. 브레이크도 걸었다. 그리고 전부는 아닙니다 - 그들 자신과 소스 코드에 있습니다.
몇 초 동안 웃었습니다. 인터페이스에서 수십 밀리 초가 느껴지면 즉시 불편 함이 나타납니다.
그리고 가장 중요한 것은 내 질문에 대한 답이 없다는 것입니다. 어떤 상황에서 그래프로 직접 작업하는 것을 제외하고. 개체(이름에 TF 이름 없음), DeInit - Init 시퀀스가 중요합니까?
3페이지에서 나는 연습의 예를 들었습니다.
마음에 오는 첫 번째 일은 내 deinit에 glob에 암기가 있다는 것입니다. 이전 상태의 변수(버튼을 눌렀다 뗐다/떼었다)를 초기화한 다음 초기화 버튼을 저장된 값에 따라 설정합니다. 그리고 내가 항상 올바르게 다시 설치하지 않는 것은 정확히 버튼입니다. 이것이 내가 기억한 첫 번째 것입니다. 아마도 다른 것을 찾을 것입니다 ...
기억하다) 또한 현재 Deinit에서 터미널을 구현하는 경우에는 아무 것도 할 수 없으므로 사용해야 한다는 점을 기억해야 합니다(전역 변수나 쓸 파일에서 모두)...
본질적으로 쓸모없는 기능은 그러한 깨진 시퀀스로 인해
다른 논리가 있음을 이해하십시오. 특히 MT 개발자의 논리. 이것에 따르면 다른 논리는 모든 것이 매우 논리적으로 보입니다. 따라서 결론: 이 논리에 적응하고 당신보다 경험이 많은 사람들을 설득하지 마십시오. 소용없어요... 지표 하나를 위해 기존 논리를 바꾸는 데 아무도 동의하지 않을 것입니다.
Alexey Viktorov : 다른 논리가 있음을 이해하십시오. 특히 MT 개발자의 논리. 이것에 따르면 다른 논리는 모든 것이 매우 논리적으로 보입니다. 따라서 결론: 이 논리에 적응하고 당신보다 경험이 많은 사람들을 설득하지 마십시오. 소용없어요... 지표 하나를 위해 기존 논리를 바꾸는 데 아무도 동의하지 않을 것입니다.
재정과 관련이 없었다면 이런 논의는 없었을 것입니다.
그리고 거래 고문은 하나 또는 다른 지표에 의존하기 때문에 단순한 기간 전환으로 인해 올바르게 작동을 멈춥니다. 그게 가장 짜증난다.
TF를 변경 하기 전에 터미널이 이전 TF에서 모든 표시기가 언로드될 때까지 기다렸다가 새 TF를 빌드하고 초기화하면 차트 속도가 얼마나 느려질지 상상해 보십시오.
어떤 상황에서 그래프로 직접 작업하는 것을 제외하고. 개체(이름에 TF 이름 없음), DeInit - Init 시퀀스가 중요합니까?
여러분, 여러분 모두는 여러 가지를 혼동하고 있습니다. 중요한 소프트웨어로서의 터미널에 대한 최소 두 가지 요구 사항에 동의합시다.
- 동일한 논리(멀티스레딩이 있는 경우에도)를 엄격히 따라 예측 가능하게 작동해야 합니다.
- 그는 빨리 일해야 합니다.
(지표 사본이 다른 사본에 대해 알고 있는지 여부는 중요하지 않지만 저장을 위해 터미널에 할당된 전역 데이터가 일관성 을 유지해야 하는 것이 중요합니다. 이는 개별 지표 개발자가 아니라 단말기의 관심사입니다)
다음 질문은 그것을 구현하는 방법입니다. 현재 요구 사항 2에 대해서만 구현하고 있습니다. 요구 사항 2를 희생하지 않고 요구 사항 1을 고려하여 구현할 것을 제안합니다.
차트의 init/deini와 표시기의 init/deini가 다르다는 점에 주의하면 눈에 띄는 감속은 없을 것입니다. 차트는 기본 새 차트를 즉시 표시하지만 상속된 지표의 경우 이전 OnDeinit가 처리된 후 OnInit 이벤트가 대기열에 추가됩니다. 터미널에 이벤트 대기열이 이미 있습니다.
MQ가 원하면 NDA 조건에 따라 클래스 및 시퀀스 다이어그램을 보낼 수 있습니다. 수정하겠습니다 ;-).
속도가 느려지는 이유는 무엇입니까? 표시가 비스듬하게 쓰여지지 않는 한. 일반적으로 작성된 표시기의 경우 DeInit는 상당한 시간이 걸립니다. 게다가, 스위칭 TF는 그렇게 빈번한 작업이 아니다. 일부 특히 심각한 경우(이것은 "잘못된" 표시기에 해당) TF를 변경할 때 1~2초 정도 기다릴 수 있습니다.
따라서 TF를 전환할 때 제동에 대한 논쟁은 의심의 여지가 없습니다. 또한 아직 구축되지 않은 TF로 전환할 때 다소 눈에 띄는 시간 지연도 감지됩니다. 그리고 아무도 터미널의 브레이크에 대해 울지 않습니다.
지표가 다릅니다. 브레이크도. 그리고 전부는 아닙니다 - 그들 자신과 소스 코드에 있습니다.
몇 초 동안 미소를 지었다. 인터페이스에서 수십 밀리 초가 느껴지면 즉시 불편 함이 나타납니다.
그리고 가장 중요한 것은 내 질문에 대한 답이 없다는 것입니다.
어떤 상황에서 그래프로 직접 작업하는 것을 제외하고. 개체(이름에 TF 이름 없음), DeInit - Init 시퀀스가 중요합니까?
지표가 다릅니다. 브레이크도 걸었다. 그리고 전부는 아닙니다 - 그들 자신과 소스 코드에 있습니다.
몇 초 동안 웃었습니다. 인터페이스에서 수십 밀리 초가 느껴지면 즉시 불편 함이 나타납니다.
그리고 가장 중요한 것은 내 질문에 대한 답이 없다는 것입니다.
어떤 상황에서 그래프로 직접 작업하는 것을 제외하고. 개체(이름에 TF 이름 없음), DeInit - Init 시퀀스가 중요합니까?
나는 일반적으로 전역 변수를 사용하지 않지만 가끔 이런 일이 발생합니다.
전역 변수로 작업할 때 도약을 얻습니다. 차트에서 지표를 삭제할 때 스스로 정리하고 전역 변수를 제거 해야 합니다. 지표에서 전역 변수를 삭제할 위치는 어디입니까? 아마 Deinite에서 삭제해야 할 것 같은데, 다른 곳이 생각나지 않습니다. 따라서 기간을 변경하고 새로운 변수를 생성하면 deinite가 와서 모든 것을 지웁니다. 글로벌 변수는 지표에서 사용할 수 없습니다.
저는 일반적으로 전역 변수를 사용하지 않지만 가끔 이런 일이 발생합니다.
전역 변수로 작업할 때 도약을 얻습니다. 차트에서 지표를 삭제할 때 스스로 정리하고 전역 변수를 제거 해야 합니다. 지표에서 전역 변수를 삭제할 위치는 어디입니까? 아마 Deinite에서 삭제해야 할 것 같은데, 다른 곳이 생각나지 않습니다. 따라서 기간을 변경하고 새로운 변수를 생성하면 deinite가 와서 모든 것을 지웁니다. 글로벌 변수는 지표에서 사용할 수 없습니다.
Sergey, 당신의 손가락에서 빨려 들어가지 않은 실제 예가 있습니까? 나는 또한 생각해 낼 수 있지만 실제로는 문제가 발생하지 않았습니다.
ps: 전역 변수는 TF에 따라 이름을 지정할 수도 있습니다.
지표가 다릅니다. 브레이크도 걸었다. 그리고 전부는 아닙니다 - 그들 자신과 소스 코드에 있습니다.
몇 초 동안 웃었습니다. 인터페이스에서 수십 밀리 초가 느껴지면 즉시 불편 함이 나타납니다.
그리고 가장 중요한 것은 내 질문에 대한 답이 없다는 것입니다.
어떤 상황에서 그래프로 직접 작업하는 것을 제외하고. 개체(이름에 TF 이름 없음), DeInit - Init 시퀀스가 중요합니까?
3페이지에서 나는 연습의 예를 들었습니다.
ch에서 기억하십시오. init / deinit가 아니라 해당 변수가 변경될 때마다 터미널.
ch에서 기억하십시오. init / deinit가 아니라 해당 변수가 변경될 때마다 터미널.
기억하다)
또한 현재 Deinit에서 터미널을 구현하는 경우에는 아무 것도 할 수 없으므로 사용해야 한다는 점을 기억해야 합니다(전역 변수나 쓸 파일 모두에서)...
본질적으로 쓸모없는 기능은 그런 깨진 시퀀스와 함께되었습니다.
나는 그것을 기억할 것입니다 (이 스레드를 우연히 우연히 발견한 것이 좋습니다). 그러나 다른 프로그래머 (여기를 보지 않을 것)는 계속해서 자연 논리 시퀀스를 사용하고 deinit를 사용하여 작동하기를 희망하고 init는 새 TF에서 시작됩니다.
기억하다)
또한 현재 Deinit에서 터미널을 구현하는 경우에는 아무 것도 할 수 없으므로 사용해야 한다는 점을 기억해야 합니다(전역 변수나 쓸 파일에서 모두)...
본질적으로 쓸모없는 기능은 그러한 깨진 시퀀스로 인해
다른 논리가 있음을 이해하십시오. 특히 MT 개발자의 논리. 이것에 따르면 다른 논리는 모든 것이 매우 논리적으로 보입니다. 따라서 결론: 이 논리에 적응하고 당신보다 경험이 많은 사람들을 설득하지 마십시오. 소용없어요... 지표 하나를 위해 기존 논리를 바꾸는 데 아무도 동의하지 않을 것입니다.
재정과 관련이 없었다면 이런 논의는 없었을 것입니다.
그리고 거래 고문은 하나 또는 다른 지표에 의존하기 때문에 단순한 기간 전환으로 인해 올바르게 작동을 멈춥니다. 그게 가장 짜증난다.
그는 어떻게 재정을 신뢰할 수 있습니까?
이 문제에 대해 MT 개발자와 의견이 다를 수 있습니다.TF를 변경 하기 전에 터미널이 이전 TF에서 모든 표시기가 언로드될 때까지 기다렸다가 새 TF를 빌드하고 초기화하면 차트 속도가 얼마나 느려질지 상상해 보십시오.
어떤 상황에서 그래프로 직접 작업하는 것을 제외하고. 개체(이름에 TF 이름 없음), DeInit - Init 시퀀스가 중요합니까?
여러분, 여러분 모두는 여러 가지를 혼동하고 있습니다. 중요한 소프트웨어로서의 터미널에 대한 최소 두 가지 요구 사항에 동의합시다.
- 동일한 논리(멀티스레딩이 있는 경우에도)를 엄격히 따라 예측 가능하게 작동해야 합니다.
- 그는 빨리 일해야 합니다.
(지표 사본이 다른 사본에 대해 알고 있는지 여부는 중요하지 않지만 저장을 위해 터미널에 할당된 전역 데이터가 일관성 을 유지해야 하는 것이 중요합니다. 이는 개별 지표 개발자가 아니라 단말기의 관심사입니다)
다음 질문은 그것을 구현하는 방법입니다. 현재 요구 사항 2에 대해서만 구현하고 있습니다. 요구 사항 2를 희생하지 않고 요구 사항 1을 고려하여 구현할 것을 제안합니다.
차트의 init/deini와 표시기의 init/deini가 다르다는 점에 주의하면 눈에 띄는 감속은 없을 것입니다. 차트는 기본 새 차트를 즉시 표시하지만 상속된 지표의 경우 이전 OnDeinit가 처리된 후 OnInit 이벤트가 대기열에 추가됩니다. 터미널에 이벤트 대기열이 이미 있습니다.
MQ가 원하면 NDA 조건에 따라 클래스 및 시퀀스 다이어그램을 보낼 수 있습니다. 수정하겠습니다 ;-).