Fazendo um projeto de crowdsourced em Tela - página 39

 
Алексей Барбашин:

...

Peter, você fez um ótimo trabalho ao criar uma biblioteca GUI em seu estilo. Mas se você planeja publicá-lo, ainda vale a pena redesenhá-lo para uma tecnologia diferente. Estou pronto para ajudá-lo nisto e passo a passo transferir todo o poder de sua biblioteca de uma nova maneira.

Alexei, digamos que eu estaria disposto a tentar. Como você sugere fazer isso? O trabalho é incrível.
 
Реter Konow:
Alexey, digamos que eu gostaria de tentar. Como você se propõe a fazer isso? É um trabalho impossível.

Peter, provavelmente não consigo imaginar nem mesmo uma pequena fração da quantidade de trabalho que você fez, e estou mais do que certo de que simplesmente subestimo a escala completa dos objetos criados. MAS!

Como sempre, há um MAS!

Qualquer projeto, nem mesmo necessariamente na programação.

Para começar, nós nos abstraímos dos objetos que foram criados. Ou seja, não os representaremos como uma matriz, estruturas ou classes. Aceitaremos simplesmente a noção de OBJETO (elemento de controle, forma, interface como um todo, e assim por diante). Você tenta estabelecer a interação dos objetos de forma estrutural. Quando descobrirmos juntos o que é construído, tentaremos revelar as regularidades com base nisso. Em princípio, você não terá que identificá-los porque os identificou há muito tempo e fez um tratamento unificado para eles, você simplesmente explicará o princípio de operação e propósito. Então, simplesmente substituiremos um objeto por outro em seu projeto. Naturalmente, será muito mais difícil do que escrever a partir do zero. Mas temos um objetivo ligeiramente diferente em nosso caso, portanto, de modo geral, não há pressa. Mas publicações sobre a tradução do algoritmo da matriz para o algoritmo do objeto provavelmente seriam interessantes não apenas para iniciantes. Estou convencido de que no processo deste trabalho, outros participantes se juntarão a nós e compartilharão suas idéias ou estimularão uma implementação mais conveniente deste ou daquele algoritmo.

De uma forma ou de outra, a idéia em si deve ser primeiramente representada por um fluxograma do algoritmo.

Eu fiz minha sugestão. Mas você pode fazer o contrário, tudo depende de seu desejo e visão da questão (trabalho conjunto).

 
Алексей Барбашин:

Peter, provavelmente não consigo imaginar nem mesmo uma pequena fração da quantidade de trabalho que você fez, e estou mais do que certo de que simplesmente subestimo a escala completa dos objetos criados. MAS!

Como sempre, há um MAS!

Qualquer projeto, nem mesmo necessariamente na programação.

Para começar, nós nos abstraímos dos objetos que foram criados. Ou seja, não os representaremos como uma matriz, estruturas ou classes. Aceitaremos simplesmente a noção de OBJETO (elemento de controle, forma, interface como um todo, e assim por diante). Você tenta estabelecer a interação dos objetos de forma estrutural. Quando descobrirmos juntos o que é construído, tentaremos revelar as regularidades com base nisso. Em princípio, você não terá que identificá-los porque os identificou há muito tempo e fez um tratamento unificado para eles, você simplesmente explicará o princípio de operação e propósito. Então, simplesmente substituiremos um objeto por outro em seu projeto. Naturalmente, será muito mais difícil do que escrever a partir do zero. Mas temos um objetivo ligeiramente diferente em nosso caso, portanto, de modo geral, não há pressa. Mas publicações sobre a tradução do algoritmo da matriz para o algoritmo do objeto provavelmente seriam interessantes não apenas para iniciantes. Estou convencido de que no processo deste trabalho, outros participantes se juntarão a nós e compartilharão suas idéias ou estimularão uma implementação mais conveniente deste ou daquele algoritmo.

De uma forma ou de outra, a idéia em si deve ser primeiramente representada por um fluxograma do algoritmo.

Eu fiz minha sugestão. Mas você pode fazer o contrário, tudo depende de seu desejo e visão da questão (trabalhar em conjunto).

Muito bem. Farei o que puder. Vou explicar as soluções e a arquitetura. Mas eu não sei se terei sucesso no final.

Agora os objetos estão dispostos no núcleo. Eles precisam ser retirados do núcleo e colocados em classes.

1. Eu provavelmente criaria três classes básicas: "Rectangle_label", que acomodaria todas as propriedades básicas das etiquetas retangulares, "Icon" e "Texto". Esses objetos fazem parte de quase todos os controles.

2. Em seguida, criar um grupo de classes descendentes. Eles seriam divididos pelos seguintes critérios: a) elementos que controlam um parâmetro. b) elementos que são controlados pelo parâmetro.

3. As classes descreveriam as propriedades específicas de cada elemento.

Estas são apenas as primeiras idéias. Eles podem estar errados.

Com este esquema, a herança se torna imediatamente múltipla - classes de elementos (herdeiros) devem incluir propriedades de três classes base ao mesmo tempo.

 
Реter Konow:

Muito bem. Farei o meu melhor. Vou explicar as soluções e a arquitetura. Mas eu não sei se terei sucesso no final.

Neste momento, os objetos estão organizados no núcleo. Eles precisam ser retirados do núcleo e colocados em classes.

1. Eu provavelmente criaria três classes básicas: "Rectangle_label", que acomodaria todas as propriedades básicas das etiquetas retangulares, "Icon" e "Texto". Esses objetos fazem parte de quase todos os controles.

2. Em seguida, criar um grupo de classes descendentes. Eles seriam divididos pelos seguintes critérios: a) elementos que controlam um parâmetro. b) elementos que são controlados pelo parâmetro.

3. As classes descreveriam as propriedades específicas de cada elemento.

Estas são apenas as primeiras idéias. Eles podem estar errados.

Com este esquema, a herança acaba sendo plural ao mesmo tempo - as classes de elementos (descendentes) devem incluir propriedades de três classes básicas ao mesmo tempo.

Então, aqui vai um raciocínio.

"Eu criaria três classes base: "Rectangle_label", que conteria todas as propriedades básicas das etiquetas retangulares, "Ícone" e "Texto". - Classicamente, o primeiro objeto simplesmente chama Rectângulo ou Rect, a segunda imagem generalizada, bem, o terceiro pode ser descrito por propriedades separadas ou também fazer um objeto separado. Para indicar que o tipo de dado criado é uma classe em c++ e em mql é usual indicar C antes do nome do tipo, ou seja, CRectangle, CImage, CText. Mas tipos simples que apenas contêm dados heterogêneos são mais convenientes de criar como estruturas.

A primeira coisa a considerar são todas as propriedades básicas dos controles LARGOS. Mais tarde você pode adicionar qualquer propriedade, não será um problema.

"a) elementos que controlam um parâmetro. b) elementos que são controlados por um parâmetro". - decifrar é necessário aqui. Eu não entendo o que estas descrições significam.

"haverá sucesso no final" - é ainda melhor ter certeza de que haverá sucesso. Caso contrário, é melhor não começar.
 
Алексей Барбашин:

Bem, aqui vai um raciocínio.

1. "Eu criaria três classes básicas: "Rectangle_label", que conteria todas as propriedades básicas das etiquetas retangulares, "Ícone" e "Texto". - Classicamente, o primeiro objeto simplesmente chama Rectângulo ou Rect, a segunda imagem generalizada, bem, o terceiro pode ser descrito por propriedades separadas lobo também fazem um objeto branco. Para indicar um tipo de dado criado como uma classe em c++ e em mql, é costume indicar C antes do nome do tipo, ou seja, CRectangle, CImage, CText

2. "a) elementos que controlam o parâmetro. b) elementos que são controlados pelo parâmetro". - decifrar é necessário aqui. Eu não entendo o que estas descrições significam.

"Haverá sucesso no final" - é ainda melhor ter certeza de que haverá sucesso. Caso contrário, é melhor não começar.

1. A classe mais básica é GHObjest (objeto gráfico básico). Deve haver propriedades x,y, x_tamanho, y_sixe e diferentes tipos de ligação de coordenadas. Estas são propriedades comuns de TODOS os objetos.

2. seus descendentes são CRec, CImage, CText. Eles têm apenas propriedades específicas e inerentes.

3. Depois, há as classes de plataformas de janelas. Há vários deles: Janela de menu, Janela de opções, Janela de diálogo, Janela dinâmica. Há ali um conjunto de propriedades específicas.

3. Depois, há as classes de elementos. Pode haver até 50 deles. Eles são divididos em categorias: 1) por método de processamento de parâmetros, 2) por método ornamental.

Este é um bom ponto de partida. Precisamos fazer uma linguagem de marcação, não uma biblioteca. Qual é o sentido do contrário?


ZS A maioria dos controles funciona com o parâmetro que lhes é dado. A essência de seu propósito é controlar algum parâmetro do usuário. Mas, cada controle o faz de uma maneira diferente.

ZSY. Esqueci de acrescentar - você precisa de uma classe base de parâmetros com suas propriedades. CParam, por exemplo.

 
Реter Konow:

1. A classe mais básica é a GOBijest (objeto gráfico básico). Deve haver propriedades x,y, x_tamanho, y_sixe e diferentes tipos de ligação de coordenadas. Estas são propriedades comuns de TODOS os objetos.

2. seus descendentes são CRec, CImage, CText. Eles têm apenas propriedades específicas e inerentes.

3. Depois, há as classes de plataformas de janelas. Há vários deles: Janela de menu, Janela de opções, Janela de diálogo, Janela dinâmica. Há ali um conjunto de propriedades específicas.

3. Depois, há as classes de elementos. Pode haver até 50 deles. Eles são divididos em categorias: 1) por método de processamento de parâmetros, 2) por método ornamental.

Este é um bom ponto de partida. Precisamos fazer uma linguagem de marcação, não uma biblioteca. Qual é o sentido do contrário?


ZS A maioria dos controles funciona com o parâmetro que lhes é dado. A essência de seu propósito é controlar algum parâmetro do usuário. Mas, cada elemento o faz de maneira diferente.

Estou tendo um pouco de explosão cerebral... )) Tudo precisa ser desenhado, caso contrário não se pode digeri-lo. )

 
Алексей Барбашин:

Estou tendo uma pequena explosão cerebral... )) Tudo precisa ser desenhado, caso contrário não se pode digeri-lo. )

)) Nada...

A classe base de parâmetros CParam tem vários descendentes. A questão é que existem propriedades gerais de parâmetros de itens controlados, e existem propriedades específicas. Por exemplo: um botão tem um bool do tipo parâmetro controlado, enquanto uma lista suspensa tem um tipo "menu". Ou seja, um botão alterna 1/0, enquanto uma lista oferece uma seleção limitada. O controle deslizante, por exemplo, tem um tipo de parâmetro "alcance" - ou seja, alcance. Existem vários outros tipos e todos têm propriedades únicas.

Portanto, as classes que são descendentes da classe do parâmetro base também devem ser. Algo como "CBool", "CRange", "CMenu".

 
Реter Konow:

)) Nada...

A classe base de parâmetros CParam tem vários descendentes. A questão é que existem propriedades comuns para parâmetros de itens controlados, e existem propriedades específicas. Por exemplo: um botão tem um tipo de parâmetro controlado de bool, enquanto uma lista suspensa tem um tipo "menu". Ou seja, um botão alterna 1/0, enquanto uma lista oferece uma seleção limitada. O controle deslizante, por exemplo, tem um tipo de parâmetro "alcance" - ou seja, alcance. Existem vários outros tipos e todos têm propriedades únicas.

Portanto, as classes que são descendentes da classe do parâmetro base também devem ser. Algo como "CBool", "CRange", "CMenu".

Espere. Tentemos ver isso de forma um pouco abstrata agora.

Peter, do seu ponto de vista, o que controles como Botão, Etiqueta de texto, Caixa de entrada, Caixa de imagem têm em comum?

Документация по MQL5: Константы, перечисления и структуры / Константы объектов / Типы объектов
Документация по MQL5: Константы, перечисления и структуры / Константы объектов / Типы объектов
  • www.mql5.com
При создании графического объекта функцией ObjectCreate() необходимо указать тип создаваемого объекта, который может принимать одно из значений перечисления ENUM_OBJECT. Дальнейшие уточнения свойств созданного объекта возможно с помощью функций по работе с графическими объектами.
 
Алексей Барбашин:

Espere. Tentemos ver isso de forma um pouco abstrata agora.

Peter, do seu ponto de vista, o que controles como Botão, Etiqueta de texto, Caixa de entrada, Caixa de imagem têm em comum?

1. Coordenadas, dimensões.

2. Coordenar as dependências, dimensionar as dependências.

3. um monte mais de coisas dependendo do número total de propriedades na funcionalidade de controle. Eu tenho 270 propriedades em meu núcleo. A maioria delas é comum. Mas, eu tenho uma funcionalidade desenvolvida que suporta muitas características. Portanto, tal número de propriedades. Temos que começar com as propriedades mais simples.

 
Реter Konow:

1. Coordenadas.

2. Coordenar as dependências.

3. um monte de outras coisas, dependendo do número total de propriedades na função de controle. Eu tenho 270 propriedades em meu núcleo. A maioria deles é comum. Mas, eu tenho uma funcionalidade avançada que suporta muitas características. Portanto, tal número de propriedades. Temos que começar com as propriedades mais simples.

Sim, é claro, com as propriedades mais simples. Em que objetos primitivos poderia consistir o mesmo rótulo de texto? Ou em que objetos primitivos poderia consistir um simples Botão?