Fazendo um projeto de crowdsourced em Tela - página 36
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
Qualquer elemento de um diálogo (forma, controle (botão, lista, imagem)) tem algumas propriedades. A programação processual não define o conceito de "propriedade" ou "campo". Na programação de procedimentos, temos funções e variáveis (globais ou locais). Mas as variáveis são comuns, portanto não podem ser usadas para descrever as propriedades de cada controle individual. Então qual é a solução? Uma simples - estruturas!
Sim, uma estrutura pode ter uma descrição das propriedades necessárias de um controle, bem como um conjunto de controles aninhados (até o infinito).
Todo este material é armazenado em uma série de caixas de diálogo.
Podemos torná-la mais universal: a estrutura de descrição de controle consiste em duas matrizes: matriz de propriedades e matriz de elementos escravos. Um conjunto de propriedades é um conjunto de estruturas de um par de bens de valor de propriedade. Com esta abordagem, cada novo controle pode ter qualquer conjunto arbitrário de propriedades. Mas isto não é conveniente para o processamento. Seria mais lógico especificar as propriedades específicas do controle na estrutura: dimensões, localização, cor, moldura, etc., etc. - tudo o que qualquer controle necessita.
E a estrutura também conterá um conjunto de pixels do controle.
Quando um evento do mouse é recebido, todas as arrays são em loop para verificar se o cursor atinge um determinado controle. A verificação é feita desde o último até o primeiro controle.
Uma vez determinado qual controle tem o cursor, então o elemento dado da matriz é enviado para a função de repintura e então a matriz de recursos é atualizada e a imagem no gráfico é atualizada.
Não sei o que ele postou e o que fez nos assuntos da GUI, mas em meus tópicos ele não fez nenhuma sugestão técnica, nenhuma solução e nenhuma discussão sobre o assunto. Somente trolling vazio, apontando soluções de terceiros e exortando a não reinventar a roda.
Voltar ao tema em questão.
Até onde eu estou familiarizado com a biblioteca padrão (muito pouco na verdade), há elementos e janelas compostas de objetos MT. Isto é, em nosso contexto - eles não são desenhados sobre a tela. Claro que eles são desenhados, mas não em nossa tela, o que nos impede de controlar as cores dos pixels, criando gradientes de superfície e muito mais.
Em teoria, poderíamos pegar a estrutura da biblioteca, copiar e fazer um análogo no kanvas. Em teoria...
O problema é que o próprio CCanvas não é adequado para fazer uma GUI sobre ele. Por quê? Porque o sistema kanvas é utilizado principalmente para primitivas gráficas. Portanto, em essência, esta classe não fornece nada além de primitivos. O arquétipo GUI tem que ser construído por você mesmo. E, neste caso, a classe não é necessária. É mais conveniente se contentar com suas próprias soluções. Afinal, você pode desenhar um marcador retangular sem a classe. Assim como você pode criar ou carregar uma lona. É muito simples. Portanto, eu preferia minha própria solução.
Mas alguém não pode passar sem o CCanvas. É por isso que eu não insisto nisso.
O problema com o CCanvas é que sua GUI está estritamente vinculada à janela do gráfico.
Ou seja, você não pode fazer uma janela completa como um módulo de interface terminal.
E seria muito legal escrever seus próprios módulos de interface.
ligeiramente errado, é claro :-)
Eu postei uma interface para a DLL Tcl (que é Tool Common Language), que tem gráficos Tk que são compartilhados como uma GUI em Python/Ruby/etc
o objetivo não era obter uma GUI, mas um bom subproduto :-)
tcl.Eval("button .pressme -text {Hello Peter}; pack .pressme") ;
em minha opinião conveniente e, o mais importante, curto :-)
Eu não estou agitando ninguém - eu sei tcl/tk, eu uso, eu compartilho minha experiência (ver sourceforge atcl)
Sim Max, é exatamente isso que estou falando do TCL e de seu protótipo que estávamos discutindo na época. A limitação ali era que o usuário tinha que ter a biblioteca apropriada instalada em seu computador. Não parecia ser difícil, mas ainda é uma certa limitação.
Vamos deixar isso para o passado. Max, junte-se a nós na discussão. Roman, junte-se também )))).
Do exposto acima, pode-se entender que um elemento da estrutura é um controle de diálogo específico, contém suas próprias propriedades e pode conter controles aninhados. O conjunto de propriedades de tal controle universal é limitado apenas pela imaginação do desenvolvedor.
É claro que podemos evitar a estrutura e descrever as propriedades dos controles em uma matriz multidimensional, mas não é inicialmente econômico porque precisamos lembrar claramente qual índice de alguma propriedade é armazenado. E a matriz não pode conter tipos de dados heterogêneos. Acontece que a descrição do elemento de controle na programação processual só é possível através das estruturas. Ou seja, o elemento da estrutura é um controle concreto, ou seja, o objeto concreto do diálogo com suas propriedades.
O problema com o CCanvas é que sua GUI está estritamente vinculada à janela do gráfico.
Ou seja, você não pode fazer uma janela completa como um módulo de interface terminal.
E seria muito legal escrever seus próprios módulos de interface.
Depois haverá o inverso - ligando a interface com o gráfico. Por exemplo, faça um botão que esteja estritamente ligado ao tempo e ao preço.
Uma GUI separada pode ser escrita em pouco tempo - com todas as tabelas, abas, menus e apitos. Em C# ou mesmo BASIC. E dentro da tabela é um problema significativo para aplicações externas.
Qualquer elemento de um diálogo (forma, controle (botão, lista, imagem)) tem algumas propriedades. A programação processual não define o conceito de "propriedade" ou "campo". Na programação de procedimentos, temos funções e variáveis (globais ou locais). Mas as variáveis são comuns, portanto não podem ser usadas para descrever as propriedades de cada controle individual. Então qual é a solução? Uma simples - estruturas!
Sim, uma estrutura pode ter uma descrição das propriedades necessárias de um controle, bem como um conjunto de controles aninhados (até o infinito).
Todo este material é armazenado em uma série de caixas de diálogo.
Podemos torná-la mais universal: a estrutura de descrição de controle consiste em duas matrizes: matriz de propriedades e matriz de elementos escravos. Um conjunto de propriedades é um conjunto de estruturas de um par de bens de valor de propriedade. Com esta abordagem, cada novo controle pode ter qualquer conjunto arbitrário de propriedades. Mas isto não é conveniente para o processamento. Seria mais lógico especificar as propriedades específicas do controle na estrutura: dimensões, localização, cor, moldura, etc., etc. - tudo o que qualquer controle necessita.
E a estrutura também conterá um conjunto de pixels do controle.
Quando um evento do mouse é recebido, todas as arrays são em loop para verificar se o cursor atinge um determinado controle. A verificação é feita desde o último controle até o primeiro.
Uma vez determinado qual controle tem o cursor, então o elemento na matriz envia para a função de repintura e então atualiza a matriz de recursos e atualiza a figura na tabela.
1. Suponha que você tenha projetado uma estrutura simples de controles básicos - uma janela, um botão, uma caixa de seleção. Cada um deles consiste em um conjunto de componentes - objetos. Caixa de seleção - base, texto, ícone. Botão - base, texto, ícone, e assim por diante. Cada objeto de cada elemento deve ter seu próprio conjunto de propriedades. Você pode escrevê-los em uma estrutura ou classe, mas, em minha opinião, não é conveniente. Por quê? - Porque quando você os coloca em uma janela, você precisa encontrá-los na tela com o cursor. Quando você move o cursor, eles têm que entrar em foco. Para isso, suas coordenadas atuais devem estar em uma matriz. E é mais conveniente se todas as suas propriedades (incluindo as coordenadas atuais) estiverem na mesma matriz. Desta forma, você pode acessar imediatamente qualquer propriedade de qualquer elemento na tela que é o foco do cursor. Também é mais fácil percorrer uma série de itens.
Ou seja, é mais fácil atravessar UM array em um loop para encontrar o elemento que o cursor atingiu. É ainda mais conveniente se esta matriz for global. Então, em qualquer função, você pode retirar dela as informações necessárias e alterar os valores das propriedades necessárias, dos elementos necessários.
Este é o acesso mais curto e mais eficiente aos elementos e seu processamento mais rápido. Este é o meu "núcleo".
No entanto, conhecendo os caprichos dos profissionais para lutar pela imitação máxima do padrão OOP, eu não proponho esta tecnologia.
3. uma matriz de pixels não precisa ser armazenada em nenhum lugar. É construído no momento da necessidade, de acordo com os parâmetros dos elementos da matriz. Por exemplo: você precisa redesenhar a janela. Chamamos a função de repintura. A função chama o conjunto de elementos, vê todas as suas propriedades, declara o conjunto de pixels, calcula seu tamanho, desenha seus objetos sucessivamente no loop, chama ResourceCreate(). É isso aí.
Um elemento preso sob o cursor é enviado para a mesma função para ser redesenhado. Ela recebe uma notificação (bandeira de repintura) e seu número na matriz de itens. Em seguida, a função chama o recurso requerido via ResourceReadImage(), coloca-o na matriz de pixels e depois, dentro da matriz de pixels, encontra a área do elemento requerido e pinta novamente todos os seus objetos. É isso aí.
1. Suponha que você tenha projetado uma estrutura simples de controles básicos - uma janela, um botão, uma caixa de seleção. Cada um consiste de um conjunto de partes constituintes - objetos. Caixa de seleção - base, texto, ícone. Botão - base, texto, ícone, e assim por diante. Cada objeto de cada elemento deve ter seu próprio conjunto de propriedades. Você pode escrevê-los em uma estrutura ou classe, mas, em minha opinião, não é conveniente. Por quê? - Porque quando você os coloca em uma janela, você precisa encontrá-los na tela com o cursor. Quando você move o cursor, eles têm que entrar em foco. Para isso, suas coordenadas atuais têm que estar em uma matriz. E é mais conveniente se todas as suas propriedades (incluindo as coordenadas atuais) estiverem na mesma matriz. Desta forma, você pode acessar imediatamente qualquer propriedade de qualquer elemento na tela que é o foco do cursor. Também é mais fácil percorrer uma série de itens.
Ou seja, é mais fácil atravessar UM array em um loop para encontrar o elemento que o cursor atingiu. É ainda mais conveniente se esta matriz for global. Então, em qualquer função, você pode retirar dela as informações necessárias e alterar os valores das propriedades necessárias, dos elementos necessários.
Este é o acesso mais curto e mais eficiente aos elementos e seu processamento mais rápido. Este é o meu "núcleo".
No entanto, conhecendo os caprichos dos profissionais para lutar pela imitação máxima do padrão OOP, eu não proponho esta tecnologia.
3. uma matriz de pixels não precisa ser armazenada em nenhum lugar. É construído no momento da necessidade, de acordo com os parâmetros dos elementos da matriz. Por exemplo: você precisa redesenhar a janela. Chamamos a função de repintura. A função chama o conjunto de elementos, vê todas as suas propriedades, declara o conjunto de pixels, calcula seu tamanho, desenha seus objetos sucessivamente no loop, chama ResourceCreate(). É isso aí.
Um elemento preso sob o cursor é enviado para a mesma função para ser redesenhado. Ela recebe uma notificação (bandeira de repintura) e seu número na matriz de itens. Em seguida, a função chama o recurso requerido via ResourceReadImage(), coloca-o na matriz de pixels e depois, dentro da matriz de pixels, encontra a área do elemento requerido e pinta novamente todos os seus objetos. É isso aí.
Na verdade, isto deve funcionar independentemente da tecnologia de construção. Mas pode ser percebido de forma diferente. No seu caso, você passa um array no loop e determina qual controle tem o cursor naquele momento. Assim, quando você define o índice, você vê imediatamente as propriedades do item encontrado. Mas como você pode armazenar diferentes tipos de dados em uma grande variedade?
Na verdade, isto deve acontecer independentemente da tecnologia de construção. Você só pode percebê-lo de maneiras diferentes. No seu caso, você percorre a matriz e determina qual controle tem o cursor no momento. Assim, quando você define o índice, você vê imediatamente as propriedades do item encontrado. Mas como você pode armazenar diferentes tipos de dados em uma grande variedade?
Em princípio, é possível generalizar os tipos. Cheguei à conclusão de que nada de ruim acontecerá, se a grande maioria das propriedades dos objetos forem do tipo int. Todos os outros (o dobro está praticamente ausente nas propriedades dos objetos gráficos) tipos abreviados que eu desconsiderei por uma questão de simplificação. A memória "invadida" é tão insignificante que não faz sentido pensar sobre isso. Naturalmente, não podemos ir por tal sacrilégio em nome do profissionalismo))))). Mas estamos no século XXI e não estou ameaçado por fogueiras).
Eu fiz os nomes dos objetos como números, e os coloquei na série geral de propriedades dos objetos.
O único lugar onde eu precisava de um tipo diferente de dados era o dos parâmetros de controle. Lá criei um segundo núcleo, que armazena as propriedades dos parâmetros, e os próprios valores no tipo de string, que eu posso facilmente lançar para qualquer coisa (ou melhor, para o que está prescrito nas propriedades dos parâmetros).
SUGESTÃO: Por "parâmetro do elemento de controle" entende-se o PARÂMETRO GERIDO PELO EQUIPAMENTO.1. Suponha que você tenha projetado uma estrutura simples de controles básicos - uma janela, um botão, uma caixa de seleção. Cada um consiste de um conjunto de partes constituintes - objetos. Caixa de seleção - base, texto, ícone. Botão - base, texto, ícone, e assim por diante. Cada objeto de cada elemento deve ter seu próprio conjunto de propriedades. Você pode escrevê-los em uma estrutura ou classe, mas, em minha opinião, não é conveniente. Por quê? - Porque quando você os coloca em uma janela, você precisa encontrá-los na tela com o cursor. Quando você move o cursor, eles têm que entrar em foco. Para isso, suas coordenadas atuais devem estar em uma matriz. E é mais conveniente se todas as suas propriedades (incluindo as coordenadas atuais) estiverem na mesma matriz. Desta forma, você pode acessar imediatamente qualquer propriedade de qualquer elemento na tela que é o foco do cursor. Também é mais fácil percorrer uma série de itens.
Ou seja, é mais fácil atravessar UM array em um loop para encontrar o elemento que o cursor atingiu. É ainda mais conveniente se esta matriz for global. Então, em qualquer função, você pode retirar dela as informações necessárias e alterar os valores das propriedades necessárias, dos elementos necessários.
Este é o acesso mais curto e mais eficiente aos elementos e seu processamento mais rápido. Este é o meu "núcleo".
No entanto, conhecendo os caprichos dos profissionais para lutar pela imitação máxima do padrão OOP, eu não proponho esta tecnologia.
3. uma matriz de pixels não precisa ser armazenada em nenhum lugar. É construído no momento da necessidade, de acordo com os parâmetros dos elementos da matriz. Por exemplo: você precisa redesenhar a janela. Chamamos a função de repintura. A função chama o conjunto de elementos, vê todas as suas propriedades, declara o conjunto de pixels, calcula seu tamanho, desenha seus objetos sucessivamente no loop, chama ResourceCreate(). É isso aí.
Um elemento preso sob o cursor é enviado para a mesma função para ser repintado. Ela recebe uma notificação (bandeira de repintura) e seu número na matriz de itens. Em seguida, a função chama o recurso requerido via ResourceReadImage(), coloca-o na matriz de pixels e, além disso, dentro da matriz de pixels, encontra a área do elemento requerido e pinta novamente todos os seus objetos. É isso aí.
ugh esta eterna negatividade de oop, bem do outro lado da linha
Você já se perguntou como isso aconteceu? A questão é que muitas pessoas que escrevem em estilo procedural e não conhecem o OOP enfrentam o desejo de agrupar funções, e então este desejo se desenvolve em um desejo de combinar estas funções em uma área de memória e se referir a ela, ou seja, se referir fisicamente à área com funções que são armazenadas em uma variável. Depois queremos mudar nosso grupo de funções selecionadas sem duplicar o código (recebemos herança). Assim, uma pessoa que inicialmente está familiarizada apenas com o estilo de procedimento algum tempo depois pergunta por que há tantas restrições em um mql (referência a herança múltipla).
Em geral, acredita-se que é mais fácil ensinar o OOP de uma vez, porque se uma pessoa está familiarizada com o estilo procedimental, será muito difícil reciclar mais tarde (para a maioria das pessoas), mas existem outros, já que inicialmente havia apenas o estilo procedimental... descrita acima.
ZS Há uma variação no OOP em geral, um pouco familiarizado com o OOP no nível do código de procedimento, e realmente usando o OOP em sua totalidade.
Uma classe é uma referência a uma memória (tabela) de funções, que pode ser reescrita e ampliada mantendo a matriz principal + referência a variáveis. e eu esqueço o que mais.... (como 32 bytes)
Com o eterno problema da busca, eu comparei recentemente a função de classificação embutida com a classificação vermelha (uma das classificações do modelo), perda de velocidade de 3-6 vezes em certas condições (perda embutida =)
Na GUI eu acho que existem métodos padrão.
,
Ugh, esta eterna negatividade em relação ao OOP, bem do outro lado da linha.
Você já se perguntou como isso aconteceu? A questão é que muitas pessoas que escrevem em estilo processual e não sabem sobre o OOP enfrentam o desejo de agrupar funções, então esse desejo cresce e se torna um desejo de combinar essas funções em uma área de memória e se referir a ela, ou seja, se referir fisicamente à área com funções que são armazenadas em uma variável. Depois queremos mudar nosso conjunto de funções selecionadas sem duplicar o código (recebemos herança). Assim, uma pessoa que inicialmente está familiarizada apenas com o estilo de procedimento algum tempo depois pergunta por que há tantas restrições em um mql (referência a herança múltipla).
Em geral, acredita-se que é mais fácil ensinar o OOP de uma vez, porque se uma pessoa se familiariza com o estilo procedimental, então será muito difícil se reciclar (para a maioria das pessoas), mas existem outros, já que inicialmente só havia estilo procedimental... descrita acima.
ZS Há uma variação no OOP em geral, um pouco familiarizado com o OOP no nível do código de procedimento, e realmente usando o OOP em sua totalidade.
Uma classe é uma referência a uma memória (tabela) de funções, que pode ser reescrita e ampliada mantendo a matriz principal + referência a variáveis. e eu esqueço o que mais.... (como 32 bytes)
Com o eterno problema da busca, comparei recentemente a função de classificação embutida com a classificação vermelha (um dos modelos), perda de velocidade de 3-6 vezes em certas condições (built-in lost =)
Na GUI eu acho que existem métodos padrão.
,
Eu não tenho nenhuma negatividade para o conceito de OOP. Eu mesmo sou um adepto disso. Eu tenho uma negativa para as normas. Para ser mais preciso, para segui-los desapercebidamente).
Além disso, eu sou a favor do OOP. Mas eu sou a favor da OOP simplificada.