내 접근 방식. 코어 - 엔진. - 페이지 97

새 코멘트
 
Vasiliy Sokolov :

피터, 도대체 무슨 대사야?! double, int, color와 같은 매개변수가 많이 있으며 이를 문자열로 변환하여 차트의 개체에 씁니다. 그러나 Union으로 작업할 때는 문자열이 필요하지 않습니다. 예제를 다시 보면 문자열 없이 double로 직접 작업하고 데이터가 완벽하게 전송됩니다.

Vasily, 수치 데이터 외에도 커스텀 어드바이저는 엔진에 많은 문자열 데이터를 설치합니다. 이름, 메시지 등 따라서 숫자만으로는 불가능합니다.

예를 들어, Oleg Papkov의 Expert Advisor는 "Trend가 올라갔고, Trend가 down..."과 같은 텍스트를 창으로 보냅니다. 다른 사람들은 테이블 셀에 텍스트를 전달하기를 원할 것입니다. 입력 필드 에 .

숫자만 가지고는 안되죠...

 

텍스트를 정확히 전송해야 하는 경우 문자열을 바이트 배열로 변환합니다.

 StringToCharArray ( "text" , u. char );

여기서 u는 합집합이고 u.char는 각각 char[]의 배열입니다. Union 배열은 고정된 크기를 가지므로 문자열이 맞지 않으면 u.char를 늘리거나 문자열을 부분적으로 전달합니다.

 
Vasiliy Sokolov :

텍스트를 정확히 전송해야 하는 경우 문자열을 바이트 배열로 변환합니다.

여기서 u는 합집합이고 u.char는 각각 char[]의 배열입니다. Union 배열은 고정된 크기를 가지므로 문자열이 맞지 않으면 u.char를 늘리거나 문자열을 부분적으로 전달합니다.

알았습니다. 고맙습니다. 나는 노력할 것이다. (단, 단순히 객체 설명으로 모든 것이 가능하겠지만) 자원은 끝까지 다루고 싶다. 유용할 수도 있습니다.

추가 기능은 항상 유용합니다. 예, 새로운 지식은 아프지 않습니다 ...

요컨대, 귀하와 다른 모든 사람을 개인적으로 도와주셔서 대단히 감사합니다.

 
Реter Konow :

알았습니다. 고맙습니다. 나는 노력할 것이다. (단, 단순히 객체 설명으로 모든 것이 가능하겠지만) 자원은 끝까지 다루고 싶다. 유용할 수도 있습니다.

추가 기능은 항상 유용합니다. 예, 새로운 지식은 아프지 않습니다 ...

요컨대, 귀하와 다른 모든 사람을 개인적으로 도와주셔서 대단히 감사합니다.

빠른 연결을 원하신다면 Union보다 빠른 것은 없습니다. 매개변수가 있는 라인을 객체를 통해 매우 빠르게 전달합니다. ResourceCreate를 통한 것보다 더 빠를 수도 있지만 이 라인을 구문 분석하면 모든 속도가 중단됩니다. 사실, MQL은 매우 빠른 언어이며 여기에서 느린 구문 분석도 비교적 빠릅니다.

 
Vasiliy Sokolov :

빠른 연결을 원하신다면 Union보다 빠른 것은 없습니다. 매개변수가 있는 라인을 객체를 통해 매우 빠르게 전달합니다. ResourceCreate를 통한 것보다 더 빠를 수도 있지만 이 라인을 구문 분석하면 모든 속도가 중단됩니다. 사실, MQL은 매우 빠른 언어이며 여기에서 느린 구문 분석도 비교적 빠릅니다.

문제는 어쨌든 구문 분석이 필요하다는 것입니다. 결국 리소스에 문자열을 쓴 후에도 거기에서 추출하고 수집한 다음 " 매개변수 번호 / 매개변수 값 " 부분으로 분할해야 합니다.

즉, 리소스에서 즉시 파선을 얻을 가능성은 거의 없습니다. 따라서 구문 분석이 여전히 필요합니다 ... ((

 
Реter Konow :

문제는 어쨌든 구문 분석이 필요하다는 것입니다. 결국 리소스에 문자열을 쓴 후에도 거기에서 추출하고 수집한 다음 " 매개변수 번호 / 매개변수 값 " 부분으로 분할해야 합니다.

즉, 리소스에서 즉시 파선을 얻을 가능성은 거의 없습니다. 따라서 구문 분석이 여전히 필요합니다 ... ((

피터, 당신은 예전 방식으로 돌아왔습니다. 글쎄, 당신은 이미 얼마나 할 수 있습니까? 이미 여러 번 말했습니다. 문자열을 사용하지 않고 값과 매개변수 번호를 전송하고 수신합니다. 귀하의 예에서는 문자열 구문 분석 없이 double을 전달하고 받았습니다. 그렇다면 왜 이 double을 다시 문자열로 밀어 넣으려고 합니까? 사용자에게 메시지를 보내야 하는 경우 구문 분석 없이 텍스트로 보냅니다. 모두.

 
Vasiliy Sokolov :

피터, 당신은 예전 방식으로 돌아왔습니다. 글쎄, 당신은 이미 얼마나 할 수 있습니까? 이미 여러 번 말했습니다. 문자열을 사용하지 않고 값과 매개변수 번호를 전송하고 수신합니다. 귀하의 예에서는 문자열 구문 분석 없이 double을 전달하고 받았습니다. 그렇다면 왜 이 double을 다시 문자열로 밀어 넣으려고 합니까? 사용자에게 메시지를 보내야 하는 경우 구문 분석 없이 텍스트로 보냅니다. 모두.

바질, 내가 설명하려고 노력할게.

매개변수 값은 단순한 숫자가 아닙니다. 매개변수 값은 텍스트일 수 있습니다. 예를 들어, 사용자가 입력 필드에 텍스트를 입력했습니다. 이 텍스트는 엔진에서 EA로 전달됩니다. 또는 특정 이벤트의 어드바이저가 " 거래 세션 이 시작되었습니다!"라는 내용의 텍스트를 GUI에 보냅니다.

Expert Advisor 또는 엔진의 각 이벤트에서 모든 유형의 데이터를 앞뒤로(int, double, long, string...) 전송해야 하므로 모든 것을 한 방향으로 문자열을 통해 전달하는 것이 더 편리합니다. 그런 다음 원하는 유형으로 캐스팅하십시오.

그렇지 않으면 한 가지 방법으로 하나의 데이터를 전송하고 다른 하나는 다른 방식으로 전송해야 합니다.

사용자가 어떤 데이터를 더 보내거나 받을지 아무도 모릅니다. 아마도 텍스트가 주요 데이터가 될 것입니다. 모든면에서 문자열은 정보를 송수신하기 위한 범용 캐리어임이 밝혀졌습니다.

 
Vasiliy Sokolov :


그건 그렇고, 어제의 결정(그리고 당신의 도움) 덕분에 내가 어떤 진전을 이뤘는지 확인하세요.

특히 이 예에서는 모든 것이 리소스를 통해 전달됩니다.



그리고 이 모든 작업은 EA의 다음 코드를 통해 수행됩니다.

 void OnTimer ()
  { 
   static int q1,q2,q3,a,b,c,d; 
   //------------------------------------
   LOAD_CANVAS_Last_10_bars();
   //---------------------------------
   if (!a) { q1++;}
   if (q1 == 200 )a = 1 ;
   if (a)q1--;
   if (!q1)a = 0 ;
   //------------------------------------  
   CIRCLE(q1,q2,q3, clrGreen );  
   TRIANGLE(q1,q1,q1 + 100 ,q1 + 10 ,q1 + 50 ,q1 + 200 , clrRed );  
   ELLIPSE(q1,q1,q1 + q1* 2 ,q1 +  q1, clrBlue );  
   FILLED_CIRCLE(q1, 20 , 20 , clrBlue ); 
   TRIANGLE(q1 + 10 ,q1,q1 + 10 ,q1 + 100 ,q1 + 50 ,q1 + 200 , clrAqua );  
   ELLIPSE(q1 + 50 ,q1,q1 + q1* 2 ,q1 * q1- 30 , clrBlack );  
   ELLIPSE(q1 + 52 ,q1,q1 + q1* 3 ,q1 * q1- 32 , clrMagenta ); 
   ELLIPSE(q1 + 54 ,q1,q1 + q1* 4 ,q1 * q1- 34 , clrOrange ); 
   FILLED_CIRCLE(q1 + 70 ,q1+ 20 , 20 , clrDarkCyan );        
   FILLED_CIRCLE(q3,q2, 40 , clrGreen ); 
   //------------------------------------
   REDRAW_CANVAS();
  }
 
Реter Konow :

그건 그렇고, 어제의 결정(그리고 당신의 도움) 덕분에 내가 어떤 진전을 이뤘는지 확인하세요.

특히 이 예에서는 모든 것이 리소스를 통해 전달됩니다.

예, 인상적으로 보입니다.

 
Реter Konow :

모든면에서 문자열은 정보를 송수신하기 위한 범용 캐리어임이 밝혀졌습니다.

나는 여전히 여기에 동의하지 않습니다. 정보 전송을 위한 보편적인 도구는 바이트 배열입니다.

나는 당신이 텍스트를 전송해야한다는 데 동의합니다. 그리고 텍스트를 한 줄로 옮기는 것이 가장 편리하다는 데도 동의합니다. 그러나 실제로 문자열은 추상화일 뿐입니다. 차트의 개체를 통해 텍스트를 전달할 때 이 텍스트의 길이는 64자로 제한되었습니다. 이것은 실제로 "뒤에서" 64바이트 배열을 전달하고 있음을 의미합니다(MQL은 명시적으로가 아니라 문자열을 배열로 변환하고 다시 배열로 변환하는 모든 작업을 수행했습니다). MQL 프로그램 간의 정보 교환이 전체 프로젝트의 중요하고 기본적인 위치에 있는 프로젝트를 만들고 있다면 이 기능을 일반화된 솔루션에 맡기는 것은 문제의 여지가 없습니다. 내가 당신이라면 엄격한 변환 제어와 함께 문자열을 포함한 임의의 유형을 전달하기 위한 일반 시스템을 개발할 것입니다. 이것은 통합 및 리소스 읽기를 기반으로 수행할 수 있습니다. 그러나 문자열 구문 분석을 기반으로 하면 이는 문제가 됩니다. 구문 분석된 문자열이 유효하다는 보장은 없습니다.

1...90919293949596979899100101102103104...184
새 코멘트