Fazendo um projeto de crowdsourced em Tela - página 6
Você está perdendo oportunidades de negociação:
- Aplicativos de negociação gratuitos
- 8 000+ sinais para cópia
- Notícias econômicas para análise dos mercados financeiros
Registro
Login
Você concorda com a política do site e com os termos de uso
Se você não tem uma conta, por favor registre-se
Há uma questão fundamental.
Digamos que há duas aplicações, painéis, indicadores, em um único gráfico. Cada um deles deve desenhar em sua própria tela ou ambos em uma tela comum?
Há perguntas em ambos os casos.
Agora eu sugiro que simplesmente desenhemos alguma tela. Com todos os elementos.
De qualquer forma, não seremos capazes de controlar o número de instâncias em execução com tela (ou entraremos profundamente nas funções do sistema operacional para "interface multijanela" em tela). Pode chegar a isso em algum momento, mas ainda não).
Como conseqüência - proponho não fazer interações entre kanvas no nível de envio de "eventos de janela" entre eles agora mesmo.
Também não consigo imaginar agora como vários ex5's trocariam dados sobre o conteúdo de um único kanvas compartilhado.
Com o teclado, tudo fica mais ou menos claro. Você tem o evento de pressionar uma tecla, você tem o código para essa tecla. O que mais você quer?
Infelizmente não há completude no código. hoje em dia os eventos do gráfico não fazem distinção entre A e um
Já escrevi sobre este assunto no SD
A propósito, acho que facilitaria muito a vida em termos de DND normal ao introduzir o evento OnMouseDown.
CHART_MOUSE_MOVE evento em sparam envia estado dos botões e teclado. = esquerda, direita, ctrl, turno, alt.
Em outras palavras, a DND é implementada agora.
Em outras palavras, podemos implementar a DND agora.
Sim, estou ciente disso, porque eu o implementei em meu projeto recente. Portanto, agora a DND só pode ser implementada através de um idiota.
Antes de tudo, para o arrasto e queda normal é necessário ativar ou desativar algumas propriedades do gráfico, caso contrário o gráfico é arrastado junto com a tela, é claro que em quase todos os casos devemos desativá-los.
Em segundo lugar, MouseMove não está vinculado a um objeto, como Click, por exemplo, então se houver dois objetos sob o mouse, ambos serão arrastados. Na biblioteca padrão, a propósito, é assim que as coisas são.
E assim será se não houver lógica interna, selecionando qual objeto puxar.
Portanto, o segundo problema do evento MoseDown parece estar efetivamente resolvido.
Há também um terceiro ponto. O MouseMove é um evento de spam. Deve ser forçado a habilitar e, quando habilitado, será enviado a todos os códigos da tabela e pode ser a causa de bons freios devido ao número de mensagens, portanto, se houver uma maneira de não usá-lo, é melhor não usá-lo.
Há também um terceiro ponto. O MouseMove é um evento de spam. Ele tem que ser ativado com força e quando ativado será enviado para todos os códigos no gráfico e pode causar bons atrasos devido ao número de mensagens, então se houver uma maneira de não usá-lo, é melhor não usá-lo.
Sim, estou ciente disso, porque eu o implementei em meu projeto recente. Portanto, agora a DND só pode ser implementada através de um idiota.
O primeiro, para o arrasto e queda normal, precisamos desativar e habilitar algumas propriedades do gráfico, caso contrário, o gráfico é arrastado junto com a tela, é claro que em quase todos os casos é preciso desativá-los.
Em segundo lugar, o MouseMove não está amarrado a um objeto, como o Click, por exemplo, então se houver dois objetos sob o mouse, ambos serão puxados. Na biblioteca padrão, a propósito, é assim que as coisas são.
E assim será se não houver lógica interna, selecionando qual objeto puxar.
Portanto, o segundo problema do evento MoseDown parece estar efetivamente resolvido.
Há também um terceiro ponto. O MouseMove é um evento de spam. Deve ser forçado a habilitar e, quando habilitado, será enviado a todos os códigos da tabela e pode ser a causa de bons freios devido ao número de mensagens, portanto, se houver uma maneira de não usá-lo, é melhor não usá-lo.
Você percebe que se formos kanvas - estamos por nossa conta. Não há mais eventos de alto nível. Nenhum objeto mt que possa recebê-los
Se apenas os movimentos do mouse e o botão diz. eu não lhe chamaria de idiota ). é apenas um evento de baixo nível.
Se houver algum atraso, ele é invisível a olho nu. Em meu painel de uma vez a MouseMove estava enviando milhares de itens, inclusive invisíveis, então eu fiz um envio mais inteligente, mas visualmente não acrescentava velocidade.
Não sei dizer o quão rápido vai ser.
Milhares de objetos não fazem diferença na velocidade.
você percebe que, se entrarmos em uma pesquisa, estamos por nossa conta. Não há mais eventos de alto nível. Nenhum mt se opõe a recebê-los.
Se apenas os movimentos do mouse e o botão diz. eu não lhe chamaria de asno ). é apenas um evento de baixo nível.
Há também o nível de interação com outros códigos. Pelo menos, entre várias instâncias de um indicador, por exemplo. Você deve levar isso em conta.
Mas sim, tudo isso é claro.
Há também um nível de interação com outros códigos. Por exemplo, entre várias instâncias de um indicador. É preciso levá-lo em conta.
Honestamente, não tenho idéia do tipo de interação de que você está falando.
Várias instâncias de um indicador saem para uma tela?