터미널의 전역 변수 에 바이트 배열을 보낼 수 있는 일반 함수(int 배열이 더 좋으므로 변환 방법에 대한 질문이 적음) 및 이에 따라 이를 허용하는 역함수 다른 Expert Advisor에서 읽을 어레이
터미널의 전역 변수만으로는 데이터 교환에 충분하지 않습니다. 하나의 double 형식으로 큰 변수 이름 필드와 데이터용 작은 필드가 있습니다. 반대로 필요합니다 ;)
추신: 구문 분석 결정 그래프의 그물에 많은 예가 있습니다. 주로 인터페이스가 유연한 코드 구조를 달성하기 때문에 MQL이 아닌 모든 곳에 인터페이스가 있습니다((
여기에 전적으로 동의합니다. 터미널 전역 변수는 비참합니다. 배열이 아닌 WCF에서와 같이 클래스 인스턴스만 저장합니다. 한때 나는 이 기회에 그저 충격을 받았습니다. 네트워크를 통해 바이트 스트림을 grazing하는 대신 불필요한 제스처 없이 클래스의 인스턴스를 보낼 수 있으며 .NET이 나를 위해 모든 더러운 작업을 수행했으며 이진 형식으로 전송된 경우 신속하게 처리했습니다.
흠, 클라우디아를 누르는 중에 이런 라이브러리를 만들 생각이 떠올랐는데...
---
나는 의사결정 그래프와 인터페이스를 접하지 못했을 뿐이고, 프로그래밍의 세계는 방대합니다))
복잡한 솔루션은 불가능하고 대량 문자가 없으며 누구나 배열을 읽고 쓸 수 있습니다. 더 복잡한 경우 데이터 교환 솔루션 에 대해 위의 KB에서 적절하게 썼지만 IMHO, GlobalArrayWrite(문자열 이름, int out[]) 및 GlobalArrayRead(문자열 이름, int &in[]) - 그게 다야 사용자에게 더 이상 필요하지 않습니다.
자원. 서로 다른 차트에 배치하려는 두 EA(또는 지표 또는 EA와 지표)에서 여러 유형의 배열을 사용하여 공용체를 선언합니다. 각 프로그램에서 문자열 변수(폴더, 하위 폴더, 프로그램 이름)에 반대쪽 주소를 기록합니다. 통신을 위해 두 가지 기능을 사용합니다. 첫 번째 기능은 메시지 읽기이고 두 번째 기능은 메시지 쓰기입니다. 함수는 타이머의 빈도로 두 프로그램 모두에서 호출됩니다.
각 프로그램의 기능은 문자열 변수로 전송해야 하는 모든 데이터를 기록해야 합니다. 그런 다음 타이머 기능이 끝나면 메시지 전달 기능이 호출 되어 수집된 문자열을 리소스에 저장합니다. 다른 차트의 다른 프로그램은 다음 타이머 기간에 다른 프로그램의 주소에 있는 리소스를 읽는 기능을 호출하고 메시지의 압축을 풉니다. 또한 필요한 데이터를 리소스에 쓰기만 하면 동일한 방식으로 메시지를 첫 번째 프로그램에 작성하고 전송할 수도 있습니다.
저는 여기서 13년 동안 핸디캡을 하고 2006년에 MT4로 시작했습니다. 당시 여자 친구가 터미널 처리를 도와달라고 요청했기 때문에이 주제에 들어갔고 C와 같은 특정 언어 인 MQL4를 행복하게 발견하고 막혔습니다. 기억하는 것이 재미있습니다. 저는 터미널에 포함된 영어로 작업했고 이것이 서양식 개발이라고 확신했습니다. 카잔 출신이라는 걸 알았을 때 인지 부조화를 겪었다))
그렇게 13년이 지났고 MT * 터미널 개발의 여러 단계를 간략하게 설명할 수 있습니다.
1. 2009년과 같이 MT5 개발 시작. 나는 그때 알프스의 포럼에서 풀을 뜯고 있었는데, 나는 아직도 Renat가 그의 선전으로 그곳을 습격했던 것을 기억합니다. 나는 핸디캡에 상업적으로 그물을 놓는 계획이 죽었다고 반대했습니다.
2. 저에게 매우 중요한 단계인 2013년 초, 새로운 MT4 빌드 > 600이 출시되었습니다. 젠장, C++에서와 같이 구조, 클래스, 뉴 노멀 정의가 있어서 기뻤습니다. 마지막으로 버그가 제거되었고 편집기가 복사-붙여넣기 중 떨어지는 것을 멈췄으며 기타 버그도 수정되었습니다. 결국 그전에는 브릿지를 통해 C#으로 모든 전략을 C++로 작성했지만, 이후에는 샤먼을 하지 않는 것이 가능해지면서 점점 더 MQL4로 코드를 옮기기 시작했습니다. 하지만 잘 작동합니다.
3. 기억이 안나는데 아마 2016년? 올바른 plz. 마침내 MT5의 헤지 버전이 출시되었습니다. 저에게는 개인적으로 MT5로 크롤링할 동기가 있었습니다.
4. 저도 기억이 안나는데 2018년쯤? 단일 컴파일러 및 MT5에서 하나의 다중 플랫폼 프로젝트를 작성하는 기능. 그 이후로 나는 나 자신을 위해 글을 쓰고 있다. 고객에게 이 기회를 제공하면 90%가 즉시 동의합니다. 절대 모두가 그것에 대해 알지 못합니다. 멀티플랫포머의 경우 fxsaber의 MT4Orders 라이브러리를 권장합니다. 코드베이스에서 검색하여 찾을 수 있습니다.
5. 여기 잡담이 있습니다. MT5는 끊임없이 진화하고 있기 때문에 매우 기쁘게 생각합니다.
13년 동안 플랫폼 개발을 대략적으로 설명했지만, 앞으로의 10년은 어떻게 될까요? 꿈을 꾸어 볼까요? 당신은 미래의 발전에 일부 환상이 반영 될 것입니다))
게다가 ... 한 번에 10 명의 친구가 한 번에 터미널을 처리하기 위해 합창으로 무릎을 꿇고 ... 그리고 나는 그들에게 대답했습니다. 부끄러운 일, 나는 자유로운 사람이 아닙니다. 나는 이미 50 명의 여자 친구가 있습니다. 지도 아래 내가 당신을 어디로 데려갈 수 있습니까? 그러면 상트 페테르부르크에는 3 루블 지폐 만 있고 하루 종일 시간이 없습니다. 밤낮으로 나는 체첸 인을 화나게합니다 ...
복잡한 솔루션은 불가능하고 대량 문자가 없으며 누구나 어레이를 읽고 쓸 수 있습니다. 더 어려운 것이 있으면 데이터 교환 솔루션에 대해 위의 KB에서 적절하게 쓴 것처럼 단순히 수요가 없을 것입니다. 그러나 IMHO, GlobalArrayWrite(문자열 이름, int out[]) 및 GlobalArrayRead(문자열 이름, int &in[]) - 그게 다야 사용자에게 더 이상 필요하지 않습니다.
예, 파일 작업에서도 오랫동안
단위FileWriteStruct( 정수file_handle,// 파일 핸들 const 무효 &struct_object,// 객체 참조 정수크기=-1// 바이트 단위로 쓸 크기 );
단순한 유형의 스트림을 구문 분석하는 것보다 구조 또는 클래스 객체 를 읽고 쓰는 것이 훨씬 더 편리합니다. 나이가 들면서 게을러진 건 아닐까? 예, 더 많이 하는 것을 선호합니다.
...
서로 다른 차트에서 실행되는 어드바이저 간에 데이터를 교환하는 방법이 있을 것입니다.
이미 구현했고 작동합니다. 다중 상속이 무엇인지 이해하는 사람은 누구나 이 작업을 수행할 수 있습니다. 그렇지 않으면 그의 지식은 가치가 없습니다.))
터미널의 전역 변수 에 바이트 배열을 보낼 수 있는 일반 함수(int 배열이 더 좋으므로 변환 방법에 대한 질문이 적음) 및 이에 따라 이를 허용하는 역함수 다른 Expert Advisor에서 읽을 어레이
터미널의 전역 변수만으로는 데이터 교환에 충분하지 않습니다. 하나의 double 형식으로 큰 변수 이름 필드와 데이터용 작은 필드가 있습니다. 반대로 필요합니다 ;)
추신: 구문 분석 결정 그래프의 그물에 많은 예가 있습니다. 주로 인터페이스가 유연한 코드 구조를 달성하기 때문에 MQL이 아닌 모든 곳에 인터페이스가 있습니다((
여기에 전적으로 동의합니다. 터미널 전역 변수는 비참합니다. 배열이 아닌 WCF에서와 같이 클래스 인스턴스만 저장합니다. 한때 나는 이 기회에 그저 충격을 받았습니다. 네트워크를 통해 바이트 스트림을 grazing하는 대신 불필요한 제스처 없이 클래스의 인스턴스를 보낼 수 있으며 .NET이 나를 위해 모든 더러운 작업을 수행했으며 이진 형식으로 전송된 경우 신속하게 처리했습니다.
흠, 클라우디아를 누르는 중에 이런 라이브러리를 만들 생각이 떠올랐는데...
---
나는 의사결정 그래프와 인터페이스를 접하지 못했을 뿐이고, 프로그래밍의 세계는 방대합니다))
이미 구현했고 작동합니다. 다중 상속이 무엇인지 이해하는 사람은 누구나 이 작업을 수행할 수 있습니다. 그렇지 않으면 그의 지식은 가치가 없습니다.))
그리고 값싼 과시와 비즈니스 없이?
이미 구현했고 작동합니다.
그리고?
KB에 이미 기성 솔루션이 있는데 솔루션도 추가하셨나요? 아니면 ...지나 갔습니까?
그리고?
KB에 이미 기성 솔루션이 있는데 솔루션도 추가하셨나요? 아니면 ...지나 갔습니까?
다중 상속에 대한 언급으로 판단하면 비어 있습니다 ...
그러나 WCF에서와 같이 클래스 인스턴스
복잡한 솔루션은 불가능하고 대량 문자가 없으며 누구나 배열을 읽고 쓸 수 있습니다. 더 복잡한 경우 데이터 교환 솔루션 에 대해 위의 KB에서 적절하게 썼지만 IMHO, GlobalArrayWrite(문자열 이름, int out[]) 및 GlobalArrayRead(문자열 이름, int &in[]) - 그게 다야 사용자에게 더 이상 필요하지 않습니다.
과시하지 않고 비즈니스에?
자원. 서로 다른 차트에 배치하려는 두 EA(또는 지표 또는 EA와 지표)에서 여러 유형의 배열을 사용하여 공용체를 선언합니다. 각 프로그램에서 문자열 변수(폴더, 하위 폴더, 프로그램 이름)에 반대쪽 주소를 기록합니다. 통신을 위해 두 가지 기능을 사용합니다. 첫 번째 기능은 메시지 읽기이고 두 번째 기능은 메시지 쓰기입니다. 함수는 타이머의 빈도로 두 프로그램 모두에서 호출됩니다.
각 프로그램의 기능은 문자열 변수로 전송해야 하는 모든 데이터를 기록해야 합니다. 그런 다음 타이머 기능이 끝나면 메시지 전달 기능이 호출 되어 수집된 문자열을 리소스에 저장합니다. 다른 차트의 다른 프로그램은 다음 타이머 기간에 다른 프로그램의 주소에 있는 리소스를 읽는 기능을 호출하고 메시지의 압축을 풉니다. 또한 필요한 데이터를 리소스에 쓰기만 하면 동일한 방식으로 메시지를 첫 번째 프로그램에 작성하고 전송할 수도 있습니다.
저는 여기서 13년 동안 핸디캡을 하고 2006년에 MT4로 시작했습니다. 당시 여자 친구가 터미널 처리를 도와달라고 요청했기 때문에이 주제에 들어갔고 C와 같은 특정 언어 인 MQL4를 행복하게 발견하고 막혔습니다. 기억하는 것이 재미있습니다. 저는 터미널에 포함된 영어로 작업했고 이것이 서양식 개발이라고 확신했습니다. 카잔 출신이라는 걸 알았을 때 인지 부조화를 겪었다))
그렇게 13년이 지났고 MT * 터미널 개발의 여러 단계를 간략하게 설명할 수 있습니다.
1. 2009년과 같이 MT5 개발 시작. 나는 그때 알프스의 포럼에서 풀을 뜯고 있었는데, 나는 아직도 Renat가 그의 선전으로 그곳을 습격했던 것을 기억합니다. 나는 핸디캡에 상업적으로 그물을 놓는 계획이 죽었다고 반대했습니다.
2. 저에게 매우 중요한 단계인 2013년 초, 새로운 MT4 빌드 > 600이 출시되었습니다. 젠장, C++에서와 같이 구조, 클래스, 뉴 노멀 정의가 있어서 기뻤습니다. 마지막으로 버그가 제거되었고 편집기가 복사-붙여넣기 중 떨어지는 것을 멈췄으며 기타 버그도 수정되었습니다. 결국 그전에는 브릿지를 통해 C#으로 모든 전략을 C++로 작성했지만, 이후에는 샤먼을 하지 않는 것이 가능해지면서 점점 더 MQL4로 코드를 옮기기 시작했습니다. 하지만 잘 작동합니다.
3. 기억이 안나는데 아마 2016년? 올바른 plz. 마침내 MT5의 헤지 버전이 출시되었습니다. 저에게는 개인적으로 MT5로 크롤링할 동기가 있었습니다.
4. 저도 기억이 안나는데 2018년쯤? 단일 컴파일러 및 MT5에서 하나의 다중 플랫폼 프로젝트를 작성하는 기능. 그 이후로 나는 나 자신을 위해 글을 쓰고 있다. 고객에게 이 기회를 제공하면 90%가 즉시 동의합니다. 절대 모두가 그것에 대해 알지 못합니다. 멀티플랫포머의 경우 fxsaber의 MT4Orders 라이브러리를 권장합니다. 코드베이스에서 검색하여 찾을 수 있습니다.
5. 여기 잡담이 있습니다. MT5는 끊임없이 진화하고 있기 때문에 매우 기쁘게 생각합니다.
13년 동안 플랫폼 개발을 대략적으로 설명했지만, 앞으로의 10년은 어떻게 될까요? 꿈을 꾸어 볼까요? 당신은 미래의 발전에 일부 환상이 반영 될 것입니다))
게다가 ... 한 번에 10 명의 친구가 한 번에 터미널을 처리하기 위해 합창으로 무릎을 꿇고 ... 그리고 나는 그들에게 대답했습니다. 부끄러운 일, 나는 자유로운 사람이 아닙니다. 나는 이미 50 명의 여자 친구가 있습니다. 지도 아래 내가 당신을 어디로 데려갈 수 있습니까? 그러면 상트 페테르부르크에는 3 루블 지폐 만 있고 하루 종일 시간이 없습니다. 밤낮으로 나는 체첸 인을 화나게합니다 ...
그리고 MT는 앞으로도 계속 될 것입니다.
그리고?
KB에 이미 기성 솔루션이 있는데 솔루션도 추가하셨나요? 아니면 ...지나 갔습니까?
복잡한 솔루션은 불가능하고 대량 문자가 없으며 누구나 어레이를 읽고 쓸 수 있습니다. 더 어려운 것이 있으면 데이터 교환 솔루션에 대해 위의 KB에서 적절하게 쓴 것처럼 단순히 수요가 없을 것입니다. 그러나 IMHO, GlobalArrayWrite(문자열 이름, int out[]) 및 GlobalArrayRead(문자열 이름, int &in[]) - 그게 다야 사용자에게 더 이상 필요하지 않습니다.
예, 파일 작업에서도 오랫동안
단위 FileWriteStruct (
정수 file_handle , // 파일 핸들
const 무효 & struct_object , // 객체 참조
정수 크기=-1 // 바이트 단위로 쓸 크기
);
단순한 유형의 스트림을 구문 분석하는 것보다 구조 또는 클래스 객체 를 읽고 쓰는 것이 훨씬 더 편리합니다. 나이가 들면서 게을러진 건 아닐까? 예, 더 많이 하는 것을 선호합니다.