Sugiro adicionar o status do botão do mouse. Isso não afetará a velocidade, mas pode ser útil)
struct Window
{
long ChartId; // identificador da janela atualuint Color; // cor de fundo da janelaint Width; // largura da janelaint Height; // altura da janelaint height[]; // altura das subjanelasint Left_bar; // número da barra mais à esquerda na janeladouble Right_bar; // número da barra mais à direita na janeladouble Total_bars; // o número máximo de barras na janelaint BarsInWind; // número de barras visíveis na janeladouble Y_min; // O valor mínimo do preço na janeladouble Y_max; // O valor máximo do preço na janeladouble dy_pix; // mudança de preço para um pixelint dx_pix; // alteração do número de barras por pixelint MouseX; // coordenada X da posição atual do ponteiro do mouseint MouseY; // coordenada Y da posição atual do ponteiro do mouseint MouseStatus; // status dos botões do mousedouble MouseBar; // a posição atual da barra do ponteiro do mouse double MousePrice; // o preço atual do ponteiro do mousedatetime MouseTime; // a hora atual do ponteiro do mouseint MouseSubWin; // número da subjanela na qual o ponteiro do mouse está localizadoint WindowsTotal;// total de subjanelas, incluindo a janela principalint SubWin; // subjanela atualdatetime time[]; // matriz do horário de abertura de todas as barras visíveis na janela
};
Sugiro adicionar o status do botão do mouse. Isso não afetará a velocidade, mas pode ser útil)
Não posso concordar, pois não vejo muito sentido nisso.
A questão é que o status dos botões e das teclas do mouse é um modelo de evento, que deve ser processado somente onde a ocorrência desse evento é capturada, ou seja, em OnChartEvent. Você não vai limitar um loop infinito de sondagem da ocorrência de algum evento fora do manipulador de eventos. Então, qual é o sentido de colocar esse status fora de OnChartEvent, quando todo o processamento desses cliques deve ser feito em OnChartEvent, cujo status está em lparam e sparam.
Exceto pelo propósito de introduzir uma nova estrutura de identificadores de eventos de mouse para melhorar a legibilidade do código.
Não posso concordar, pois não vejo muito sentido nisso.
A questão é que o status dos botões e das teclas do mouse é um modelo de evento, que deve ser tratado somente onde a ocorrência desse evento é capturada, ou seja, em OnChartEvent. Você não vai limitar um loop infinito de sondagem da ocorrência de algum evento fora do manipulador de eventos. Então, qual é o sentido de colocar esse status fora de OnChartEvent, quando todo o processamento desses cliques deve ser feito em OnChartEvent, cujo status está em lparam e sparam.
Exceto pelo propósito de introduzir uma nova estrutura de identificadores de eventos de mouse para melhorar a legibilidade do código.
E por que armazenar as coordenadas do mouse, então? ) Também orientado por eventos )
Eu não entendi sobre o loop...
Em particular, eu precisava do status para evitar desenhar uma parte do objeto ao arrastar com o mouse.
Então, por que armazenar as coordenadas do mouse? ) Também orientado por eventos )
As coordenadas do mouse são uma questão diferente. As coordenadas atuais do mouse não são informações de evento. O evento é a sua alteração.
Pode haver momentos em que as coordenadas do mouse sejam necessárias fora do OnChartEvent. Por exemplo, aqui.
Oleksii Chepurnyi:
Não entendi sobre o loop...
Em particular, o status era necessário para evitar o desenho de uma parte do objeto ao arrastá-lo com o mouse.
Bem, ao arrastar o mouse, o comando para redesenhar parte do objeto é chamado a partir do OnChartEvent no momento em que a coordenada do mouse muda e enquanto o mouse é pressionado, e o OnChartEvent tem esse status, por que incorporá-lo à estrutura do Window?
Se você fizesse a mesma coisa sem ser em OnChartEvent e, ao mesmo tempo, na instância W da estrutura Window houvesse MouseStatus, você teria que organizar um loop infinito de sondagem desse parâmetro (MouseStatus) para capturar o momento de soltar o botão do mouse, o que travaria a CPU.
Esse loop não é necessário apenas em OnChartEvent.
Quero apenas dizer que você pode e deve usar o status do botão somente em OnChartEvent, onde ele já está presente.
Se eu estiver errado, forneça um exemplo concreto em que esse status seria necessário não em OnChartEvent.
Se eu estiver errado, forneça um exemplo concreto em que esse status seria exigido de algo diferente de OnChartEvent.
Escrevi um exemplo acima e tudo funciona bem.)
Em OnChartEvent, ao mover o mouse, alteramos os parâmetros e damos o comando para redesenhar a tela. Sem um parâmetro na estrutura, teríamos que passar sparam para um objeto, de lá para outro objeto, e de lá para o método Draw().
As coordenadas do mouse são uma questão diferente. As coordenadas atuais do mouse não são informações do evento. O evento é sua alteração.
Pode haver momentos em que as coordenadas do mouse sejam necessárias fora do OnChartEvent. Por exemplo, aqui.
Bem, ao arrastar o mouse, o comando para redesenhar parte do objeto é chamado de OnChartEvent no momento em que a coordenada do mouse muda e enquanto o botão do mouse está pressionado, e OnChartEvent tem esse status, por que incorporá-lo à estrutura Window?
Se você fizesse a mesma coisa não a partir de OnChartEvent e, ao mesmo tempo, na instância W da estrutura Window houvesse MouseStatus, você teria que organizar um loop infinito de sondagem desse parâmetro (MouseStatus) para capturar o momento de soltar o botão do mouse, o que travaria a CPU.
Esse loop não é necessário apenas em OnChartEvent.
Quero apenas dizer que você pode e deve usar o status do botão somente em OnChartEvent, que já o possui.
Se eu estiver errado, dê-me um exemplo concreto em que esse status seria necessário não em OnChartEvent.
Raciocínio muito estranho. Não há lógica alguma.
Tanto as coordenadas do mouse quanto as teclas pressionadas são estados externos. Ele é passado por meio de parâmetros para o manipulador, onde, se for colocado nas variáveis internas do objeto (o que certamente é útil), deverá estar lá como um todo, não em partes. Uma biblioteca é, por definição, algo que não é feito para as próprias necessidades, mas de forma generalizada, levando em conta as possíveis necessidades de outras pessoas. Não é possível conhecer todas as necessidades com antecedência, portanto, não se deve criar restrições artificiais como essa.
Em OnChartEvent, ao mover o mouse, alteramos os parâmetros e damos o comando para redesenhar a tela. Sem um parâmetro na estrutura, teríamos que passar sparam para um objeto, daí para outro objeto e daí para o método Draw().
Esse é um clássico do gênero - em todas as bibliotecas de janelas, os estados dos botões do mouse são passados em uma única estrutura com as coordenadas do cursor.
porque todos eles juntos descrevem uma entidade e não podem ser separados.
Sugiro adicionar o status do botão do mouse. Isso não afetará a velocidade, mas pode ser útil)
Sugiro adicionar o status do botão do mouse. Isso não afetará a velocidade, mas pode ser útil)
Não posso concordar, pois não vejo muito sentido nisso.
A questão é que o status dos botões e das teclas do mouse é um modelo de evento, que deve ser processado somente onde a ocorrência desse evento é capturada, ou seja, em OnChartEvent.
Você não vai limitar um loop infinito de sondagem da ocorrência de algum evento fora do manipulador de eventos. Então, qual é o sentido de colocar esse status fora de OnChartEvent, quando todo o processamento desses cliques deve ser feito em OnChartEvent, cujo status está em lparam e sparam.
Exceto pelo propósito de introduzir uma nova estrutura de identificadores de eventos de mouse para melhorar a legibilidade do código.
Não posso concordar, pois não vejo muito sentido nisso.
A questão é que o status dos botões e das teclas do mouse é um modelo de evento, que deve ser tratado somente onde a ocorrência desse evento é capturada, ou seja, em OnChartEvent.
Você não vai limitar um loop infinito de sondagem da ocorrência de algum evento fora do manipulador de eventos. Então, qual é o sentido de colocar esse status fora de OnChartEvent, quando todo o processamento desses cliques deve ser feito em OnChartEvent, cujo status está em lparam e sparam.
Exceto pelo propósito de introduzir uma nova estrutura de identificadores de eventos de mouse para melhorar a legibilidade do código.
E por que armazenar as coordenadas do mouse, então? ) Também orientado por eventos )
Eu não entendi sobre o loop...
Em particular, eu precisava do status para evitar desenhar uma parte do objeto ao arrastar com o mouse.
Então, por que armazenar as coordenadas do mouse? ) Também orientado por eventos )
As coordenadas do mouse são uma questão diferente. As coordenadas atuais do mouse não são informações de evento. O evento é a sua alteração.
Pode haver momentos em que as coordenadas do mouse sejam necessárias fora do OnChartEvent. Por exemplo, aqui.
Não entendi sobre o loop...
Em particular, o status era necessário para evitar o desenho de uma parte do objeto ao arrastá-lo com o mouse.
Bem, ao arrastar o mouse, o comando para redesenhar parte do objeto é chamado a partir do OnChartEvent no momento em que a coordenada do mouse muda e enquanto o mouse é pressionado, e o OnChartEvent tem esse status, por que incorporá-lo à estrutura do Window?
Se você fizesse a mesma coisa sem ser em OnChartEvent e, ao mesmo tempo, na instância W da estrutura Window houvesse MouseStatus, você teria que organizar um loop infinito de sondagem desse parâmetro (MouseStatus) para capturar o momento de soltar o botão do mouse, o que travaria a CPU.
Esse loop não é necessário apenas em OnChartEvent.
Quero apenas dizer que você pode e deve usar o status do botão somente em OnChartEvent, onde ele já está presente.
Se eu estiver errado, forneça um exemplo concreto em que esse status seria necessário não em OnChartEvent.
Se eu estiver errado, forneça um exemplo concreto em que esse status seria exigido de algo diferente de OnChartEvent.
Escrevi um exemplo acima e tudo funciona bem.)
Em OnChartEvent, ao mover o mouse, alteramos os parâmetros e damos o comando para redesenhar a tela. Sem um parâmetro na estrutura, teríamos que passar sparam para um objeto, de lá para outro objeto, e de lá para o método Draw().
As coordenadas do mouse são uma questão diferente. As coordenadas atuais do mouse não são informações do evento. O evento é sua alteração.
Pode haver momentos em que as coordenadas do mouse sejam necessárias fora do OnChartEvent. Por exemplo, aqui.
Bem, ao arrastar o mouse, o comando para redesenhar parte do objeto é chamado de OnChartEvent no momento em que a coordenada do mouse muda e enquanto o botão do mouse está pressionado, e OnChartEvent tem esse status, por que incorporá-lo à estrutura Window?
Se você fizesse a mesma coisa não a partir de OnChartEvent e, ao mesmo tempo, na instância W da estrutura Window houvesse MouseStatus, você teria que organizar um loop infinito de sondagem desse parâmetro (MouseStatus) para capturar o momento de soltar o botão do mouse, o que travaria a CPU.
Esse loop não é necessário apenas em OnChartEvent.
Quero apenas dizer que você pode e deve usar o status do botão somente em OnChartEvent, que já o possui.
Se eu estiver errado, dê-me um exemplo concreto em que esse status seria necessário não em OnChartEvent.
Raciocínio muito estranho. Não há lógica alguma.
Tanto as coordenadas do mouse quanto as teclas pressionadas são estados externos. Ele é passado por meio de parâmetros para o manipulador, onde, se for colocado nas variáveis internas do objeto (o que certamente é útil), deverá estar lá como um todo, não em partes. Uma biblioteca é, por definição, algo que não é feito para as próprias necessidades, mas de forma generalizada, levando em conta as possíveis necessidades de outras pessoas. Não é possível conhecer todas as necessidades com antecedência, portanto, não se deve criar restrições artificiais como essa.
Escrevi um exemplo acima e tudo funciona bem.)
Em OnChartEvent, ao mover o mouse, alteramos os parâmetros e damos o comando para redesenhar a tela. Sem um parâmetro na estrutura, teríamos que passar sparam para um objeto, daí para outro objeto e daí para o método Draw().
Esse é um clássico do gênero - em todas as bibliotecas de janelas, os estados dos botões do mouse são passados em uma única estrutura com as coordenadas do cursor.
porque todos eles juntos descrevem uma entidade e não podem ser separados.
atualizado para a versão 1.29
Novo:
1. Adicionadas as seguintes definições para simplificar a escrita do código e melhorar a legibilidade:
2. Adicionado o parâmetro MouseStatus à estrutura Window, que pode assumir 4 valores, conforme solicitado pelos trabalhadores: