Canvas is cool! - page 22

New comment
 
Nikolai Semko:

Note, Peter, how I have implemented a multigradient of 6 colours.

where p changes from 0 to 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));
  }

ZS But there's one problem with the outermost colour, which I haven't gotten around to fixing yet.

Very original. ) p is an arbitrary user number, or is it tied to some parameter?

What is this for?

p=p*5;

You can send the right number at once. After this line p does not return to the initial value.

Here:

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

you can write:

double k=1-p+n;

and why don't you use instead of

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

?

Is the ARGB function a standard CCanvas function, or is it yours?

 
Nikolai Semko:

There is, however, a fault with the outermost colour, which has not yet been corrected.

Fixed it:

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));
  }

The code above has been corrected.

 
Реter Konow:

Is the ARGB function an in-house function of CCanvas, or is it yours?

ARGB is a defin from CCanvas. To find out, you click the mouse pointer on the name and press Alt+G

ReTag Konow:

What's this for?

5 is the number of colours -1

 
Реter Konow:

and why don't you use it instead of

When I don't need double, I prefer this option because it's much faster.
 
Nikolai Semko:

ARGB is a defin from CCanvas. To find out, press the mouse pointer over the name and press Alt+G

5 is the number of colours -1

Ok. I wasn't criticising, just asking. You're great at working with colour.

 
Реter Konow:

You're great with colour.

It's just a hobby :)
 
Artyom Trishkin:

I agree. But there is a category of users who need it differently.

And what if the returned data of the kanvas indicator exceeds 512? The buffers won't help in this case. And users just want to receive data from the indicators in their programs. And they don't want to embed them in the body of the Expert Advisor (I will spare an owl - let it fly without rattles in the ...). And they want to receive data on any bar requested, not only on the visible ones. And this is justified. And it is justified not only by laziness and desire to get everything easy and simple, but also by the requirements of TS.

Nikolai Semko:

If we are talking about the vast majority of users who are not programmers, they need either the owl or the indicator. They don't need an indicator for the owl.

I just gave some information to think about, I am not imposing anything. Let programmers decide for themselves what is convenient and what is not. However, I personally do not think that I will use iCustom function in my EAs.

Perhaps, I am not quite right.

It is quite logical to assume that a user who bought or downloaded such a canvas bufferless indicator from the Market will want to use its data in his EA.

Then the most reasonable to me would be the exchange through a specially created structure created by the producer of this indicator, which is read through a resource.

The programmer should take care in his/her kanoval bufferless indicator that this structure is kept in the resource up to date, and provide the user with the inclu-file, in which this structure is read using the users events or at coming of each tick (it's not reasonable to use the timer, I think).

And the user would only have to include one line of code #include... and then this structure will be always available with actual data from the indicator.

You know, it would be more convenient than the classic use of iCustom, because this structure can contain conveniently named variables and data arrays of different types (not only of double type, as in the buffers of the classic indicator).

I'm pretty sure that MQ's resources are implemented in the same way as indicator's buffers.

 
Nikolai Semko:

I guess I'm not quite right.

It's quite logical to assume that a user who bought or downloaded such a canva indicator from the Market will want to use its data in his EA.

In this case, the most reasonable to me would be the exchange through a specially created structure created by the producer of this indicator, which is read through a resource.

The programmer should take care in his/her canva bufferless indicator that this structure is kept in the resource up to date, and provide the user with the inclu-file that reads this structure using the user events.

And the user would only have to include one line of code #include... and this structure will be always available with actual data from the indicator.

I think it's even more convenient than the classic use of iCustom because it can contain conveniently named variables and data arrays and the user won't have to bother with what buffer number means and include only one line of code in his program to have full convenient access to indicator data.

I'm pretty sure that the MQ's resources are implemented in the same way as indicator buffers.

The mechanism of transferring data through the resource itself is extremely simple. It's more about the method of "communication" between the two programs. One program writes, the other program reads. Therefore, the program that writes data (indicator) into the resource must adhere to the specified message format and the program that reads must "know" this format. Then the communication between the programs will be universal and efficient.

 
Реter Konow:

The mechanism for transferring data through the resource itself is extremely simple. It is more about the method of "communication" between the two programmes. One programme writes and the other reads. Consequently, the program that writes its data (indicator) to the resource must adhere to the message format, and the program that reads must "know" this format. Then the communication will be universal and applicable.

Of course it will. After all, the receiving and transmitting part is done by the only developer who designed the indicator itself.

The mechanism of sharing via a resource is not that simple. It requires certain skills. That's what I see as an advantage of this method, because it will be a privilege for more advanced programmers.

ZS Peter, a month ago it didn't seem to you that it's extremely simple and necessary. Glad you heard and understood my message. :))

 
Nikolai Semko:

Well, of course it will. After all, the receiving and transmitting part is made by only one developer, who developed this indicator himself.

The mechanism of exchange through the resource is not that simple. It requires certain skills. That's what I see as an advantage of this method, because it will be a privilege for more advanced programmers.

ZS Peter, a month ago it didn't seem to you that it's extremely simple and necessary. Glad you heard and understood my message. :))

Yes, Nikolai, resources proved to be a very effective method of exchanging data between programs, and their use is based on the unions that you told me about (and Vasiliy too). So, thank you both).

The mechanism itself of transferring data into a resource and reading from it, is simple enough, but the message format is a tricky matter if you strive for universality. If we solve the issue for one particular indicator, everything is simple.

1...151617181920212223242526272829...95
New comment
Reason: