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
Реter Konow:
Você cria um array e escreve os valores das propriedades do botão que você deseja criar nele.
Um botão consiste em três objetos: Base, Texto, Imagem.
Cada objeto existe dentro de um Elemento de Botão, portanto, a matriz deve ser bidimensional.
Então, por que se preocupar com todas essas matrizes quando você pode (e deve) usar uma estrutura para isso. E podemos abordar estes valores humanamente - por nome de campo, não por índice (o que pode causar muitos erros bobos).
Como resultado, em vez de uma matriz bidimensional, haverá uma série de estruturas. A declaração é a mesma concisa, mas a simplicidade e confiabilidade é muito maior, além do uso racional da memória, pois cada campo tem seu próprio tipo. E o OOP não tem nada a ver com isso.
Aqui está um exemplo:
O resultado é um conjunto de estruturas em vez de um conjunto bidimensional. A declaração é a mesma, mas a conveniência e a confiabilidade são muito maiores, além do uso racional da memória, pois cada campo tem seu próprio tipo. E o OOP não tem nada a ver com isso.
É meio ambíguo... o que é melhor - um conjunto de estruturas ou uma estrutura de matrizes?
mas a MQL foi projetada para trabalhar com matrizes Forthran, isso é um fato...
Há um pouco de dilema aqui... o que é melhor - um conjunto de estruturas ou uma estrutura de matriz?
De que tipo de estrutura de matriz estamos falando? O autor tem apenas matrizes
Acho que Peter nunca viu como criar um modelo DialogBox em Visual C++, arrastar e soltar quaisquer Controles nele, tais como Botão, CheckBox, EditBox, ComboBox, etc.
Em outras palavras, os elementos que você pode ver no Windows, incluindo diferentes opções de exibição de strings DB com ajustes de campo e string.
E com o uso do MFC você pode fazer caixas de diálogo bastante complexas em poucos minutos e muito rapidamente.
E por que todas estas perversões com uma matriz, quando você pode (e deve) usar uma estrutura para este fim. É inicializada exatamente da mesma forma - com valores, separados por vírgulas. E estes valores podem ser acessados humanamente - por nome de campo, não por índice (o que pode levar a muitos erros bobos).
Como resultado, em vez de uma matriz bidimensional, haverá uma série de estruturas. A declaração é a mesma concisa, mas a simplicidade e confiabilidade é muito maior, além do uso racional da memória, pois cada campo tem seu próprio tipo. E o OOP não tem nada a ver com isso.
Aqui está um exemplo:
É uma boa solução. Mas esta estrutura não pode ser integrada no núcleo. Se ao construir um núcleo de acordo com minha tecnologia, você só precisa fazer um loop na matriz com os elementos do protótipo e reescrevê-los no núcleo, no caso de sua solução, o loop é impossível.
Embora isso pudesse ser possível, mas cada elemento deve ser envolto em uma estrutura separada. E como exibi-la no âmbito global? Onde declarar tudo isso... Não está claro.
O meu é simples. Um conjunto de protótipos de elementos. Todas as propriedades dos objetos estão dentro dele. A matriz em si é global. O acesso é o mais simples e de qualquer lugar do programa.
Seu instinto não resiste ao uso de duplas? Afinal de contas, é também um objeto composto com seus próprios métodos. Não há lugar para eles nas matrizes ortodoxas do núcleo! Veja, é impressionante (mantissa, expoente, sinal):
Eu não entendo.
Eu me livro de sintaxe e pandeiro desnecessários, eu simplesmente inicializo as propriedades dos elementos em uma matriz de protótipos globais.
É usado apenas uma vez - quando os protótipos de elementos são reescritos no Kernel.
A reescrita é feita em um loop simples.
Como resultado, na fase de construção, o Kernel começa a conter protótipos de elementos selecionados pelo usuário.
Em seguida, começam novos ciclos sobre o Kernel. Neles, escrevo os valores definidos pelo usuário das propriedades dos elementos.
No final, você recebe um Kernel acabado, que contém as janelas do usuário acabado com todos os elementos.
O processo descrito acima, eu chamo o "processo de construção do núcleo".
Depois que o núcleo é construído, o "motor" começa a funcionar.
O motor é o código que controla a mecânica dos elementos.
O motor só é treinado para trabalhar com o Kernel. Seu motor são vários eventos (a maioria proveniente da OnChartEvent()).