캔버스 멋지다! - 페이지 22

 
Nikolai Semko :

Peter, 내가 어떻게 6색의 다중 그라디언트를 구현했는지 주목하십시오.

여기서 p는 0에서 1로 변경됩니다.

 uint Grad( double p)
  {
   static uint Col[ 6 ]={ 0xFFFF0000 , 0xFFFF00FF , 0xFF0000FF , 0xFF00FFFF , 0xFF00FF00 , 0xFFFFFF00 };
   p=p* 5 ;
   int n=( int )p;
   if (n== 5 ) return Col[ 5 ];
   double k= 1 -p+( int )p;
   argb c1,c2;
   c1.clr=Col[n];
   c2.clr=Col[n+ 1 ];
   return ARGB( 255 ,c2.c[ 0 ]+ uchar (k*(( int )c1.c[ 0 ]-( int )c2.c[ 0 ])+ 0.5 ),
               c2.c[ 1 ]+ uchar (k*(( int )c1.c[ 1 ]-( int )c2.c[ 1 ])+ 0.5 ),
               c2.c[ 2 ]+ uchar (k*(( int )c1.c[ 2 ]-( int )c2.c[ 2 ])+ 0.5 ));
  }

극단적 인 색상에는 아직 수정 할 손이 닿지 않은 한 가지 결함이 있지만 위협적입니다.

매우 독창적입니다. ) p는 임의의 사용자 번호입니까, 아니면 일부 매개변수와 연관되어 있습니까?

이것은 무엇을 위한 것입니까?

p=p* 5 ;

필요한 번호를 한번에 보낼 수 있습니다. 이 줄 이후에는 p 가 더 이상 원래 값으로 돌아가지 않습니다.

여기:

 double k= 1 -p+( int )p;

다음과 같이 작성할 수 있습니다.

 double k= 1 -p+n;

대신 사용하지 않으시겠습니까?

 int n=( int )p;
 int n=MathRound(p);

?

ARGB 기능은 일반 CCanvas 기능입니까, 아니면 귀하의 기능입니까?

 
Nikolai Semko :

극단적 인 색상에는 아직 수정 할 손이 닿지 않은 한 가지 결함이 있지만 위협적입니다.

결정된:

 uint Grad( double p)
  {
   static uint Col[ 6 ]={ 0xFF0000FF , 0xFFFF00FF , 0xFFFF0000 , 0xFFFFFF00 , 0xFF00FF00 , 0xFF00FFFF };
   if (p> 0.9999 ) return Col[ 5 ];
   if (p< 0.0001 ) return Col[ 0 ];
   p=p* 5 ;
   int n=( int )p;
   double k=p-n;
   argb c1,c2;
   c1.clr=Col[n];
   c2.clr=Col[n+ 1 ];
   return ARGB( 255 ,c1.c[ 2 ]+ uchar (k*(c2.c[ 2 ]-c1.c[ 2 ])+ 0.5 ),
                   c1.c[ 1 ]+ uchar (k*(c2.c[ 1 ]-c1.c[ 1 ])+ 0.5 ),
                   c1.c[ 0 ]+ uchar (k*(c2.c[ 0 ]-c1.c[ 0 ])+ 0.5 ));
  }

제가 위에 올린 코드입니다.

 
Реter Konow :

ARGB 기능은 일반 CCanvas 기능입니까, 아니면 귀하의 기능입니까?

ARGB는 CCanvas의 정의입니다. 알아보려면 이름을 클릭하고 Alt+G를 누르세요.

피터 코노우 :

이것은 무엇을 위한 것입니까?

5는 색상 수 -1입니다.

 
Реter Konow :

대신 사용하지 않으시겠습니까?

double이 필요하지 않을 때 이 옵션을 선호합니다. 왜냐하면 훨씬 빠르게 작동합니다.
 
Nikolai Semko :

ARGB는 CCanvas의 정의입니다. 알아보려면 이름을 클릭하고 Alt+G를 누르십시오.

5는 색상 수 -1입니다.

확인. 비난하는게 아니라 그냥 물어보는겁니다. 당신은 색상 작업에 능숙합니다.

 
Реter Konow :

당신은 색상 작업에 능숙합니다.

그냥 취미입니다 :)
 
Artyom Trishkin :

동의한다. 그러나 달리 필요한 사용자 범주가 있습니다.

그리고 캔버스 인디케이터의 반환 데이터가 512보다 크면? 버퍼는 여기서 도움이 되지 않습니다. 그리고 사용자는 단순히 프로그램의 지표에서 데이터를 받기를 원합니다. 그리고 그들은 고문의 몸에 그들을 만들고 싶지 않습니다 (나는 올빼미를 후회할 것입니다 - 딸랑이없이 날게하십시오 ...). 그리고 그들은 보이는 바뿐만 아니라 요청된 바에 대한 데이터를 받기를 원합니다. 그리고 그것은 정당합니다. 그리고 그것은 게으름과 모든 것을 쉽고 간단하게 얻으려는 욕구뿐만 아니라 차량의 요구 사항에 의해 정당화됩니다.

니콜라이 셈코 :

프로그래머가 아닌 대다수의 사용자에 대해 이야기하고 있다면 사용자는 올빼미나 지표가 필요합니다. 그들은 올빼미에 대한 지표가 필요하지 않습니다.

나는 반성하기 위한 정보를 제공했을 뿐 아무 것도 부과하지 않았습니다. 무엇이 comme il faut이고 무엇이 comme il faut가 아닌지는 프로그래머가 스스로 결정하게 하십시오. 그러나 개인적으로 몇 가지 점을 깨닫고 나면 Expert Advisors에서 iCustom 기능을 거의 사용하지 않을 것입니다.

아마도 내가 옳지 않을 것입니다.

시장에서 이러한 캔버스 버퍼리스 표시기를 구입하거나 다운로드한 사용자가 자신의 Expert Advisor에서 해당 데이터를 사용하기를 원할 것이라고 가정하는 것은 매우 논리적입니다.

그런 다음 리소스를 통해 읽는이 표시기의 제조업체가 특별히 만든 구조를 통해 교환을 설정하는 것이 가장 합리적인 것 같습니다.

따라서 프로그래머는 캔버스 버퍼리스 표시기에서 이 구조가 리소스에서 지속적으로 최신 상태로 유지된다는 점을 주의하고 사용자 이벤트를 사용하거나 각 이벤트가 도착할 때 이 구조를 읽을 포함 파일을 사용자에게 제공해야 합니다. 틱(타이머를 사용하는 것이 합리적이지 않다고 생각합니다).

그런 다음 사용자는 Expert Advisor에 #include... 코드 한 줄만 포함하면 됩니다. 그러면 이 구조는 항상 표시기의 실제 데이터와 함께 사용할 수 있습니다.

나는 이것이 iCustom의 고전적인 사용 보다 훨씬 더 편리하다고 생각합니다. 왜냐하면 구조는 편리하게 명명된 변수와 다양한 유형의 데이터 배열을 포함할 수 있으며(클래식 표시기의 버퍼에서와 같이 이중 유형뿐 아니라) 사용자는 버퍼 번호가 의미하는 바에 대해 신경 쓸 필요가 없으며 충분합니다. 지표 데이터에 편리하게 액세스할 수 있도록 프로그램에 한 줄의 코드만 포함하도록 합니다.

ZY 특히 MQ의 리소스는 표시기 버퍼와 거의 동일하게 구현된다고 거의 확신합니다.

 
Nikolai Semko :

아마도 내가 옳지 않을 것입니다.

시장에서 이러한 캔버스 지표를 구입하거나 다운로드한 사용자가 자신의 Expert Advisor에서 해당 데이터를 사용하기를 원할 것이라고 가정하는 것은 매우 논리적입니다.

그런 다음 리소스를 통해 읽는이 표시기의 제조업체가 특별히 만든 구조를 통해 교환을 설정하는 것이 가장 합리적인 것 같습니다.

따라서 프로그래머는 이 구조가 리소스에서 지속적으로 최신 상태로 유지되고 사용자 이벤트를 사용하여 이 구조를 읽을 수 있는 포함 파일을 사용자에게 제공한다는 버퍼 없는 캔버스 표시기에 주의해야 합니다.

그런 다음 사용자는 Expert Advisor에 #include... 코드 한 줄만 포함하면 됩니다. 그러면 이 구조는 항상 표시기의 실제 데이터와 함께 사용할 수 있습니다.

나는 이것이 iCustom의 고전적인 사용 보다 훨씬 더 편리하다고 생각합니다. 구조는 편리한 이름의 변수와 데이터 배열을 포함할 수 있으며 사용자는 버퍼 번호가 의미하는 바를 신경 쓸 필요가 없으며 프로그램에 한 줄의 코드만 포함하면 표시기에 완전히 편리하게 액세스할 수 있습니다. 데이터.

ZY 특히 MQ의 리소스는 표시기 버퍼와 거의 동일하게 구현된다고 거의 확신합니다.

리소스를 통해 데이터를 전송하는 메커니즘은 매우 간단합니다. 그것은 두 프로그램 간의 "통신" 방법에 관한 것입니다. 한 프로그램은 쓰고 다른 프로그램은 읽습니다. 따라서 리소스에 데이터(지시자)를 쓰는 프로그램은 지정된 메시지 형식을 준수해야 하고 읽는 프로그램은 이 형식을 "알고" 있어야 합니다. 그러면 프로그램 간의 커뮤니케이션이 보편적이고 효과적일 것입니다.

 
Реter Konow :

리소스를 통해 데이터를 전송하는 메커니즘은 매우 간단합니다. 그것은 두 프로그램 간의 "통신" 방법에 관한 것입니다. 한 프로그램은 쓰고 다른 프로그램은 읽습니다. 따라서 리소스에 데이터(지시자)를 쓰는 프로그램은 메시지 형식을 준수해야 하고 읽는 프로그램은 이 형식을 "알고" 있어야 합니다. 그러면 이 의사소통은 보편적이고 적용될 수 있을 것입니다.

글쎄, 물론 그럴 것이다. 결국 수신 및 전송 부품은 이 표시기를 직접 개발한 한 명의 개발자가 만들었습니다.

자원을 통한 교환 메커니즘은 그렇게 간단하지 않습니다. 이것은 특정 기술이 필요합니다. 이것에서도 이 방법의 장점이 보입니다. 왜냐하면. 이것은 고급 프로그래머의 특권이 될 것입니다.

Peter를 위협하십시오. 한 달 전에는 이것이 매우 간단하고 필요한 것 같지 않았습니다. 당신이 내 메시지 를 듣고 주의를 기울인 것을 기쁘게 생각합니다. :))

 
Nikolai Semko :

글쎄, 물론 그럴 것이다. 결국 수신 및 전송 부품은 이 표시기를 직접 개발한 한 명의 개발자가 만들었습니다.

자원을 통한 교환 메커니즘은 그렇게 간단하지 않습니다. 이것은 특정 기술이 필요합니다. 이것에서도 이 방법의 장점이 보입니다. 왜냐하면. 이것은 고급 프로그래머의 특권이 될 것입니다.

Peter를 위협하십시오. 한 달 전에는 이것이 매우 간단하고 필요한 것 같지 않았습니다. 당신이 내 메시지를 듣고 주의를 기울인 것을 기쁘게 생각합니다. :))

예, Nikolai, 리소스는 프로그램 간에 데이터를 교환하는 매우 효율적인 방법으로 입증되었으며 리소스 사용은 귀하가 나에게 말한(그리고 Vasily도) 통합을 기반으로 합니다. 그래서 둘 다 감사합니다.

데이터를 리소스로 전송하고 리소스에서 읽는 메커니즘 자체는 매우 간단하지만 보편성을 추구한다면 메시지 형식은 복잡한 문제입니다. 하나의 특정 지표에 대한 문제를 해결하면 모든 것이 간단합니다.