이것이 진정한 분인지, 아니면 더 높은 TF의 특별하고 의식적으로 설정된 바인지를 결정하는 식별자, 분명히 생각해 낼 수 없었습니까?
다른 DC의 경우 PRESENCE 자체가
SERIES_BARS_COUNT개
현재 기호-마침표별 막대 수
긴
SERIES_FIRSTDATE
현재 기호-마침표별 첫 번째 날짜
날짜 시간
이는 다른 TF의 초기 과거 날짜가 다를 수 있음을 의미합니다. 이것이 "모든 것이 몇 분 안에 저장되는 경우 첫 번째 막대의 날짜로 시작 날짜를 가져오는 것은 작동하지 않습니다. 식별자를 벼락치기할 수 있습니까?"라는 질문을 제기하지 않을 수 있습니다. 그건 그렇고, 개발자의 서버에서 모든 것이 시계처럼 작동해야하며 제 3 자 DC에서도 잼이 허용되는 것처럼 보입니다. 왜 "여기는 촌스러워, DC가 알아서 잘하게 놔둬"라는 문구를 버려?
그리고 그것이 가능하더라도 사실은 남아 있습니다-함수는 선언 된 설명과 일치하지 않습니다 ...
내가 이해하는 한, 누군가는 의도적으로 "분 대신에 뭔가 다른 것이 있을 수 있다"는 생각으로 히스테리를 일으키게 됩니다.
사실은 다음과 같습니다.
시장에 출시되는 제품은 타협의 집합이라는 점을 명심하십시오.
한 이론의 순수성을 옹호하는 극단주의는 필연적으로 다른 수십 가지 입장과 충돌하게 된다. 그리고 결국, 대부분의 경우 누적 타협 옵션이 승리합니다. 여기서 양측은 조금씩 무언가를 희생해야 합니다.
특별히 의식적으로 작동하지 않는 기능을 만들기 위해
SERIES_BARS_COUNT개
기호별 막대 수 - 현재 시점
긴
SERIES_FIRSTDATE
현재 기호-마침표별 첫 번째 날짜
날짜 시간
이것이 진정한 분인지, 아니면 더 높은 TF의 특별하고 의식적으로 설정된 바인지를 결정하는 식별자, 분명히 생각해 낼 수 없었습니까?
다른 DC의 경우 PRESENCE 자체가
SERIES_BARS_COUNT개
현재 기호-마침표별 막대 수
긴
SERIES_FIRSTDATE
현재 기호-마침표별 첫 번째 날짜
날짜 시간
이는 다른 TF의 초기 과거 날짜가 다를 수 있음을 의미합니다. 이것이 "모든 것이 몇 분 안에 저장되는 경우 첫 번째 막대의 날짜로 시작 날짜를 가져오는 것은 작동하지 않습니다. 식별자를 벼락치기할 수 있습니까?"라는 질문을 제기하지 않을 수 있습니다. 그건 그렇고, 개발자의 서버에서 모든 것이 시계처럼 작동해야하며 제 3 자 DC에서도 잼이 허용되는 것처럼 보입니다. 왜 "여기는 촌스러워, DC가 알아서 잘하게 놔둬"라는 문구를 버려?
그리고 그것이 가능하더라도 사실은 남아 있습니다-함수는 선언 된 설명과 일치하지 않습니다 ...
나는 자폭한다.
가입하겠습니다. MK 측의 오만과 침략에 대한 이유는 명확하지 않습니다. 그건 그렇고, 회사가 많은 돈을 절약 할 수있게 해주는 훌륭한 피드백이있었습니다.
그리고 포럼 사용자가 많이 고려하지 않는 것이 아니라, 말할 것도 없이 이번 주말에 마이너스 2 정도입니다. 컴포스터는 오해로 인해 켜졌고 Expert는 부드럽게 쓰레기였습니다.
최근 몇 년 동안 포럼의 이 두 회원의 기여를 과소평가하기는 어렵습니다. 그러나 gopota는 기분이 좋으며 공개 중재자에게 안전하게 맡길 수 있습니다.
물론 '불만' 버튼을 누를 수도 있지만 지금은 작동하지 않거나 파티 진행 상황에 따라 변동한다. 그러나 gopota는 다른 양초의 한 기간의 차트에 마침내 어떻게 포함될 수 있는지 묻지 않을 것입니다.
정보 콘텐츠를 늘리기 위해 다른 악기에서 촛불을 방송할 수도 있습니다.
나는 가입할 것이다. MK 측의 오만과 침략에 대한 이유는 명확하지 않습니다. 그건 그렇고, 회사가 많은 돈을 절약 할 수있게 해주는 훌륭한 피드백이있었습니다.
제 입장에서는 사람들이 모여서 소리를 지르는 사소한 문제의 확대가 있었습니다.
우리의 결정은 의식적이었습니다. 설명은 내가 해주었지만 누군가는 "끝까지 이론"을 하는 것을 정말 좋아합니다.
그리고 포럼 사용자가 많이 고려하지 않는 것이 아니라, 말할 것도 없이 이번 주말에 마이너스 2 정도입니다. 컴포스터는 오해로 인해 켜졌고 Expert는 부드럽게 쓰레기였습니다.
최근 몇 년 동안 포럼의 이 두 회원의 기여를 과소평가하기는 어렵습니다.
첫째, 당신은 내가 말하지 않은 것을 나에게 돌립니다. 둘째, 그들은 한 면에만 집중된 매우 적은 양의 정보를 확실히 소유하고 있습니다.
또한 주제의 표현과 우리 방향에서 주어진 관대 한 별명에주의를 기울이십시오.불분명?
옵션 1) 히스토리 파일 Base TF에 추가 매개변수를 추가합니다. 막대가 실제로 1분이면 0분, 예를 들어 1시간이면 0이면 일간이면 매개변수 = 60이면 매개변수 = 1440입니다.
Anton, 모든 막대는 분입니다. 전체 이력은 서버에 분 단위로만 저장됩니다. 나머지 TF는 터미널에 로드될 때 분 단위로 구축됩니다.
99년까지 분 단위로 일일 막대를 볼 수 있다는 사실은 이 "일" 막대가 분 단위로 포함된다는 것을 의미합니다. 그는 그들 안에 있습니다. 이해했나요?
a) 차트 로딩 시 이를 확인하여 non-native bar 등의 표시를 금지한다. seriesinfointeger에 대한 최신 정보 ...
b) 한 번 확인하고 모든 스티칭 포인트를 별도로 기록 (결국 히스토리는 어디에도 가지 않을 것입니다)
옵션 2) 스티칭 포인트에 대한 정보만 저장합니다(공간을 절약하기 위해, 비록 우리 시대에는 옵션 1이 주석을 기록하지 않을 것이라고 생각하지만)
솔기 포인트??? 어디에 보관할까요? 수동으로 제어하는 방법? 기록 파일을 채우는 방법?
제 입장에서는 사람들이 한마음으로 모여 외치는 사소한 문제의 확대가 있었습니다 .
우리의 결정은 의식적이었습니다. 설명은 내가 해주었지만 누군가는 "끝까지 이론"을 하는 것을 정말 좋아합니다.
첫째, 당신은 내가 말하지 않은 것을 나에게 돌립니다. 둘째, 그들은 한 면에만 집중된 매우 적은 양의 정보를 확실히 소유하고 있습니다.
또한 주제의 표현과 우리 방향에서 주어진 관대 한 별명에주의를 기울이십시오.당신은 여전히 문제가 있음을 인정합니다. 사소한 문제 하나를 수정하고 다른 문제를 수정한 다음 세 번째 문제를 해결하면 터미널이 여전히 더 좋아질 것입니다.
많은 사람들로 대표되는 커뮤니티는 처음에 개발을 위한 개념적 아이디어(무료, 즉, 무료)를 제공했으며, 해당 개념에 들어가지 말아야 한다고 선언하기 시작했습니다. 우리는 광범위한 계획을 가지고 있습니다. 등을 알지 못한다.
좋습니다. 우리는 세부 사항, 마음에 들지 않는 부분, 개선할 수 있는 부분을 식별하는 작업으로 넘어갔습니다.
이제 구체적으로 들어갈 필요가 없다고 하시지만 실제로는 아무데도 가지 않으시고 터미널을 그대로 사용하시고 MQ 브레인은 걱정하지 않으셔도 됩니다.
글쎄, 카이사르에게 카이사르의 것이다.
나는 이것에 대해 고개를 숙인다. 여기에서는 지루하다.
그리고 누가 01.01이 아닌 분에 주간 바를 발견 했습니까?
히스토리 파일의 크기를 볼 수 있도록
그리고 누가 01.01이 아닌 분에 주간 바를 발견 했습니까?
히스토리 파일의 크기를 볼 수 있도록
MQL5 언어 에서 히스토리 파일의 크기에 액세스할 수 없으며 이는 모두 간접 정의입니다.
뭐, 당일치기가 아니라서 M5가 완성되겠죠. 결국, 추가는 더 젊은 사람에서 나이가 많은 사람까지 다양한 TF의 사다리에서 발생합니다.
질문은 명확하게 제기됩니다. MQL5를 사용한 접착 날짜가 필요합니다. 그리고 프로거는 접착이 중요하지 않은 TF를 이미 선택할 것입니다.
당신은 여전히 문제가 있음을 인정합니다. 사소한 문제 하나를 수정하고 다른 문제를 수정한 다음 세 번째 문제를 해결하면 터미널이 여전히 더 좋아질 것입니다.
질문은 명확하게 제기됩니다. MQL5를 사용하여 접착하는 날짜가 필요합니다. 그리고 프로거는 접착이 중요하지 않은 TF를 이미 선택할 것입니다.
글쎄, 그것들을 어디에 저장하고, 어떻게 기록하고, 어떻게 제어/변경합니까?
스티커는 몇 개까지 가능한가요? 왜 모든 것이 막내에서 맏이로 갈 것이라고 생각합니까?
하기가 어렵습니다.
내 조언 - MK 서버의 기록과 터미널을 사용하지 마십시오. 이 바보 같은 접착제가없는 중개인을 찾으십시오.
글쎄, 그것들을 어디에 저장하고, 어떻게 기록하고, 어떻게 제어/변경합니까?
스티커는 몇 개까지 가능한가요? 왜 모든 것이 막내에서 맏이로 갈 것이라고 생각합니까?
하기가 어렵습니다.
내 조언 - MK 서버의 기록과 터미널을 사용하지 마십시오. 이 바보 같은 접착제가없는 중개인을 찾으십시오.
처음에 역사는 거래를 통해 주어지며, 그는 또한 그것을 지배합니다. MQ는 다른 형식에서 이러한 스토리를 생성하기 위한 메커니즘을 만들기만 하면 되는데, 이 메커니즘은 결함입니다.
스토리가 막내부터 맏이까지 사다리로 엮여있다는 사실을 가정해 보았지만, 논리적이다(그렇지 않다면 정정).
이 파일에 접착 지점이 있다는 추가 정보를 히스토리 파일에 도입하는 것은 추가 기능일 뿐이며 모든 것이 이전과 같이 사용되지만 프로그램이 필요로 하는 위치를 식별하는 간단한 방법도 있을 것입니다.
솔직히 MQ가 왜 그렇게 긴장하는지 이해가 안됩니다.
추신: 저장 위치를 알려드릴 수 있습니다. 파일에는 여기에서 도구 이름을 암호화하고 이 정보를 암호화하는 영역이 있습니다.