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
Por favor, diga-me, a visualização em agentes remotos, acho eu, não é possível? Ou será possível?
Não é possível porque não é necessário, o agente remoto está em modo de processo, não tem janela (excepto a janela de ajustes).
Só pode ser visto através do gestor de tarefas (mas apenas o processo, não o que está a fazer).
Não é possível porque não precisa dele, o agente remoto está em modo de processo, não tem janela (além da janela de ajustes). Entendido! De facto!
Para o relógio, gostaria de utilizar uma fonte não normalizada, se fosse possível armazená-la directamente em recursos, por exemplo.
o texto significa não arrastar um ficheiro ttf separado, mas incorporá-lo directamente no ex5 como um recurso.
Ou seja, apenas para desenhar num bitmap/canvas gráfico?
As fontes não serão definitivamente incorporadas, mas podemos permitir a utilização das fontes padrão do Windows para desenho em kanvas.
Quer dizer exclusivamente para desenhar num bitmap/canvas gráfico?
Não, para um desenho eficiente do rótulo. A questão é permitir que o terminal tire uma fonte dos recursos e a instale ele próprio.
Então, exclusivamente para desenhar em bitmap/canvas gráfico?
Definitivamente não iremos incorporar fontes, mas podemos deixar-lhe utilizar fontes regulares do Windows para desenhar na tela.
Segundo sei, abrirá algum GDI para Kanvas. Isso é óptimo.
mas há um problema, penso eu, que reside a um nível ideológico nos princípios do desenho gráfico.
Deixem-me explicar com dois exemplos.
Para utilizar a tela mais activamente, é necessária uma mudança de moldura. Mas no terminal qualquer objecto não é desenhado até ser escondido de todos os prazos(OBJ_NO_PERIODS). Isto leva ao facto de não poder preparar a localização e tamanho do objecto se este ainda não tiver sido desenhado.
Eu trouxe este tópico à colação tanto para o tamanho do texto estático de saída como para o tamanho do bmp de saída - a resposta foi esta - desenha-se com largura = 1, e depois pergunta-se o tamanho do próprio objecto e sabe-se exactamente o tamanho. E acrescente aqui uma pausa mínima e a necessidade de chamar ChartRedraw... Concordará que se trata de uma muleta.
E não precisamos de encher apenas uma estática ou bmp, mas sim dúzias delas. E se houver muita actividade, é preciso observar as pausas na renderização.
--------------------
Quanto aos kanvas omnipresentes como alternativa aos objectos existentes- isso é utopia // embora agradável num mundo ideal
Ninguém no seu perfeito juízo desenharia um bitmap de 10 megabytes e o abrandaria apenas por uma linha diagonal através de um gráfico de 2096 por 1080 pixels
Eu apoio totalmente o desenvolvimento de kanvas // Eu apoio qualquer desenvolvimento.
Mas os objectos existentes cobrem 95% de todas as necessidades empresariais na interface. Kanvas é um apêndice a estruturas empresariais complicadas // muito bem demonstrado por Kohonen Maps. Mas eles não querem substituir completamente os objectos.
( -5% é o esforço dos criadores para evitar a introdução de uma linha de coordenadas. :) // mas um diálogo já começou, esperemos que cheguemos a um consenso)
2012.10.20 14:21:46 Ficheiro de peritos em testes C:\Users\Micha\AppData\Roaming\MetaQuotes\Terminal\FF783873B20D7FA177754FFD85AFB6\MQL5\Experts\Final.ex5 alloc allocator error
2012.10.20 14:21:31 Core 2 autorizado (agente build 695)
2012.10.20 14:21:16 Core 2 ligando a 127.0.0.1:3001
2012.10.20 14:11:10 Dispositivo Core 1 OpenCL: NVIDIA Corporation GeForce 9600 GSO 1GB GPU com OpenCL 1.0 (12 unidades, 1375 MHz, 2048MB, versão 301.42)
Desculpe, o que é que isto diz? Compreendo que o erro. O que é que lhe falta? ??
Em geral, o teste está quase completamente suspenso. Muitas vezes desliga-se... Mas nessa mesma noite, há jogos muito animados e bonitos, mundo dos tanques, perseguidor, etc... !
Mas há um problema, parece-me, colocado ao nível ideológico nos princípios de elaboração de uma carta.
Para utilizar mais activamente o Kanvas, é necessário alterar os quadros. E qualquer objecto no terminal não é desenhado até ser escondido de todos os prazos(OBJ_NO_PERIODS). Isto leva ao facto de não poder preparar a localização do objecto e saber o seu tamanho, se ainda não tiver sido desenhado.
Conhece a dica perfeita de backbuffering nas nossas telas e ligação a um objecto no ecrã?
Podemos desenhar quadros na perfeição, rapidamente e sem artefactos. Veja o exemplo do vídeo baseado na geração de sequência de fotogramas no Teste OpenCL.
Usar uma boa táctica:
É aqui que a magia acontece. O objecto gráfico recebe uma ligação directa ao recurso gráfico. E esta encadernação é inteligente com o cache, uma vez que foi especialmente criada para paginação rápida e manipulação de backbuffer.
//--- рисуем что хотим в buf ....
Para tal, "reconstruímos" o recurso (nenhuma reconstrução acontece de facto, porque todos os tamanhos são iguais), copiamos o novo bitmap para ele, e os contadores de mudança deste recurso são incrementados.
Note-se que o objecto gráfico em si não é tocado de forma alguma, uma vez que já está associado ao recurso.
Depois chamamos Screen Redraw via ChartRedraw que requer o desenho do objecto gráfico. Está ligado ao nosso recurso que controla utilizando o contador de alterações do bitmap. Se o contador de mudança de bitmap guardado no objecto gráfico não coincidir com o contador de recurso, o bitmap será automaticamente copiado para o objecto gráfico e visualizado de uma forma protegida. Se os contadores forem os mesmos, então a imagem é mostrada sem quaisquer alterações.
Aqui está um método simples de trabalho seguro (a partir do acesso simultâneo da MQL5 e do próprio sistema de renderização do terminal) e rápido com as estruturas de renderização.