얘들아, 너희 둘은 나를 완전히 혼란스럽게 했다. 요약하자면: 1. 새(추가) 프로그램(터미널)을 설치할 필요가 없습니다. 2. 기존(이미 설치된) 터미널에서 MQ에 대한 새 데모 계정을 열어야 하며 모든 것이 이 터미널(설치된 프로그램 사본)에서 업데이트됩니다. 3. 프로그램(터미널)의 다른 복사본에서는 아무것도 업데이트되지 않습니다.
얘들 아, 너희 둘은 나를 완전히 혼란스럽게했다. 요약하자면: 1. 새(추가) 프로그램(터미널)을 설치할 필요가 없습니다. 2. 기존(이미 설치된) 터미널에서 MQ에 대한 새 데모 계정을 열어야 하며 모든 것이 이 터미널(설치된 프로그램 사본)에서 업데이트됩니다. 3. 프로그램(터미널)의 다른 복사본에서는 아무것도 업데이트되지 않습니다.
그래서?
그리고 당신은 시도합니다. 또는 MQ에서 새 터미널을 설치하고 데모 MQ 서버에 연결합니다. 또는 기존 터미널을 연결합니다 . 그러나 (저에게는) 각 서버에 대해 별도의 터미널이 있는 것이 좋습니다.
MQ에 연결된 터미널이 업데이트되자마자 다른 모든 터미널도 업데이트를 원할 것입니다. 업데이트를 허용할지 거부할지 결정하는 것은 사용자의 몫입니다.
MQL5: Расширен формат структуры MqlTick. Теперь в ней передается время прихода тика в миллисекундах, а также флаги, позволяющие определить, какой именно параметр тика изменился.
이러한 솔루션은 datetimetime 과 함께 longtime_msc 도 구조에 추가될 때 매우 유용해 보입니다. 문제는 그렇다면 여기에 시간 이 필요한 이유는 무엇입니까? 무의미한 자원 낭비.
uint 플래그 에도 동일하게 적용되지만 uchar 는 충분하거나 적어도 ushort 입니다(이는 이미 미래에 상당한 여유가 있습니다). 그리고 거기에 대한 것은 - 마음에 이해할 수 없습니다. 개발자들이 합리적인 데이터 저장에 대한 생각을 완전히 멈춘 것이 안타깝습니다. 틱 배열은 그 자체로 거대한 볼륨입니다. 그리고 거기에 너무 무심코 낭비되는 기억이...
글쎄, 시간에 관한 한. 밀리초를 포함하는 일반 시간 유형을 MQL에 도입할 때가 되었습니까? 그렇지 않으면 이러한 목발이 쌓일 것입니다. 게다가 현재 형태의 datetime 자체는 매우 비합리적입니다. 초만 포함되어 있지만 8바이트를 소비합니다. 누가 그것을 필요로 할까요? 이 작업을 위해 4바이트( uint )는 향후 90년 동안 충분합니다(우리 중에는 Duncan MacLeods가 없습니다).
얘들아, 너희 둘은 나를 완전히 혼란스럽게 했다. 요약하자면: 1. 새(추가) 프로그램(터미널)을 설치할 필요가 없습니다. 2. 기존(이미 설치된) 터미널에서 MQ에 대한 새 데모 계정을 열어야 하며 모든 것이 이 터미널(설치된 프로그램 사본)에서 업데이트됩니다. 3. 프로그램(터미널)의 다른 복사본에서는 아무것도 업데이트되지 않습니다.
그래서?
얘들 아, 너희 둘은 나를 완전히 혼란스럽게했다. 요약하자면: 1. 새(추가) 프로그램(터미널)을 설치할 필요가 없습니다. 2. 기존(이미 설치된) 터미널에서 MQ에 대한 새 데모 계정을 열어야 하며 모든 것이 이 터미널(설치된 프로그램 사본)에서 업데이트됩니다. 3. 프로그램(터미널)의 다른 복사본에서는 아무것도 업데이트되지 않습니다.
그래서?
그리고 당신은 시도합니다. 또는 MQ에서 새 터미널을 설치하고 데모 MQ 서버에 연결합니다. 또는 기존 터미널을 연결합니다 . 그러나 (저에게는) 각 서버에 대해 별도의 터미널이 있는 것이 좋습니다.
MQ에 연결된 터미널이 업데이트되자마자 다른 모든 터미널도 업데이트를 원할 것입니다. 업데이트를 허용할지 거부할지 결정하는 것은 사용자의 몫입니다.
MQ에 연결된 터미널이 업데이트되자마자 다른 모든 터미널도 업데이트를 원할 것입니다.
그들은 원하지 않는다
"달력" 탭 MetaQuotes-Demo의 잘못된 이벤트
그리고 OBJ_EVENT에서도 표시됩니다.
새로운 빌드 1200의 발표와 관련하여.
MQL5: Расширен формат структуры MqlTick. Теперь в ней передается время прихода тика в миллисекундах, а также флаги, позволяющие определить, какой именно параметр тика изменился.
이러한 솔루션은 datetime time 과 함께 long time_msc 도 구조에 추가될 때 매우 유용해 보입니다. 문제는 그렇다면 여기에 시간 이 필요한 이유는 무엇입니까? 무의미한 자원 낭비.
uint 플래그 에도 동일하게 적용되지만 uchar 는 충분하거나 적어도 ushort 입니다(이는 이미 미래에 상당한 여유가 있습니다). 그리고 거기에 대한 것은 - 마음에 이해할 수 없습니다. 개발자들이 합리적인 데이터 저장에 대한 생각을 완전히 멈춘 것이 안타깝습니다. 틱 배열은 그 자체로 거대한 볼륨입니다. 그리고 거기에 너무 무심코 낭비되는 기억이...
글쎄, 시간에 관한 한. 밀리초를 포함하는 일반 시간 유형을 MQL에 도입할 때가 되었습니까? 그렇지 않으면 이러한 목발이 쌓일 것입니다. 게다가 현재 형태의 datetime 자체는 매우 비합리적입니다. 초만 포함되어 있지만 8바이트를 소비합니다. 누가 그것을 필요로 할까요? 이 작업을 위해 4바이트( uint )는 향후 90년 동안 충분합니다(우리 중에는 Duncan MacLeods가 없습니다).
OnTesterInit, OnTesterPass, OnTesterDeinit 함수에서 거래 함수 를 호출할 수 있다는 정보를 받았습니다. 이 함수는 호출될 경우 테스터가 아닌 거래 계정에서 실행됩니다 . 코드는 테스터에서 시작되지만.
그렇습니까?
그렇다면 시장의 Expert Advisors에서 이러한 호출이 금지되거나 테스트 중에 Market의 제품이 예기치 않게 실제 계정에서 거래를 시작할 수 있습니까?
그리고 당신은 시도합니다. 또는 MQ에서 새 터미널을 설치하고 데모 MQ 서버에 연결하십시오. 또는 기존 터미널을 연결하십시오. 그러나 (저에게는) 각 서버에 대해 별도의 터미널이 있는 것이 좋습니다.
MQ에 연결된 터미널이 업데이트되자마자 다른 모든 터미널도 업데이트를 원할 것입니다. 업데이트를 허용할지 거부할지 결정하는 것은 사용자의 몫입니다.
결과:
1. 기존 터미널에 MQ 데모 계정을 추가하면 실제로 최신 빌드로 업그레이드되었습니다.
2. 설치된 다른 터미널(MQ의 데모 계정 없음)이 업데이트되지 않았습니다.
도움을 주셔서 감사합니다! :-)
결과:
1. 기존 터미널에 MQ 데모 계정을 추가하면 실제로 최신 빌드로 업그레이드되었습니다.
2. 설치된 다른 터미널(MQ의 데모 계정 없음)이 업데이트되지 않았습니다.
도움을 주셔서 감사합니다! :-)
결과:
1. 기존 터미널에 MQ 데모 계정을 추가하면 실제로 최신 빌드로 업그레이드되었습니다.
2. 설치된 다른 터미널(MQ의 데모 계정 없음)이 업데이트되지 않았습니다.
도움을 주셔서 감사합니다! :-)