Minha abordagem. O núcleo é o motor. - página 172
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
Peter, parece que você está procurando algo para reclamar.
A resposta é não, a interlesência nunca funcionou com um elemento de texto e nunca funcionará. Mas se essa é a única questão, não é um problema fazer interlesão sobre as mesmas definições.
s.s. A propósito, isso também não vai funcionar para você:
Vasily, está longe de ser uma coisa trivial. Ao criar janelas complexas e tabelas grandes, o usuário ficará preso com nomes de elementos, que ele tem que prescrever manualmente, e ainda se lembrará ou pesquisará no formulário.
Para mim, esta linha
se transforma em um invólucro:
Eu não preciso prescrever ou lembrar o nome. Acho o item desejado na lista de inteligências.
Vasiliy, isto está longe de ser um assunto trivial. Ao criar janelas complexas e tabelas grandes, o usuário ficará preso com nomes de elementos que ele tem que escrever manualmente, e até mesmo lembrar ou procurar no formulário.
...
Repito, nunca é um problema fazer um interlacement para parâmetros de texto. Você quer que eu sugira tudo de uma só vez? Não existe tal coisa.
Repito que nunca é um problema fazer um interlacement para parâmetros textuais. Você quer que eu sugira tudo de uma só vez? Não existe tal coisa.
Sim, mas para fazê-lo em Sharp, você tem que imprimir um arquivo com definições, que você então transfere para o arquivo MQL sandbox e conecta ao programa. Seria especialmente bom fazer isso a cada mudança de conteúdo da GUI)).
Dmitry, existe um modelo arquitetônico chamado MVC. A abordagem que eu propus é exatamente sobre isso. Portanto, quando você critica, você está criticando MVC em primeiro lugar e soluções como Angular, ASP Net MVC, Ruby on Rails e outros produtos que não merecem sua atenção especializada, feitas através do "asno" em sua opinião. Portanto, acho que você deve entender por que não quero discutir com você e provar a validade da minha decisão - é simplesmente inútil.
Assim, MVC vem de todas as maneiras...
Além disso, é muito fácil justificar a inadequação deste modelo aqui, não apenas por raciocínio teórico, mas puramente prático, porque aqui é como uma máscara de gás em um passeio em um prado de flores.
Suponha que o usuário decida mudar o nome de um item, depois de chamá-lo em dezenas de lugares no programa. Ele tem que mudá-lo em todas as chamadas?
Em meu programa, não é necessário. Embrulhar um elemento só transmite de forma solta seu nome. Por exemplo, "Set lot" se transforma em"E_Trade_panel__Set_lot();" e se eu mudar o nome para "SET LOT", não preciso criar um novo invólucro.
E em sua solução, Vasiliy, eu preciso reescrever o nome em todas as chamadas.
Sim, mas para fazer isso você tem que imprimir um arquivo com definições em Sharp, que você então transfere para o arquivo MQL sandbox e conecta ao programa. Seria especialmente agradável fazê-lo a cada mudança de conteúdo da GUI)).
Peter, você simplesmente não está ciente de todas as tecnologias que o C# e o Visual Studio oferecem. Em particular, com a ajuda do T4 e das diretrizes de construção, este processo pode ser completamente automatizado, incluindo a transferência das definições geradas para a caixa de areia de arquivo.
Não, Pyotr, você não pode competir com C# e Visual Studio. São categorias de peso diferentes.
Peter, você simplesmente não está ciente de todas as tecnologias que o C# e o Visual Studio oferecem. Em particular, você pode automatizar completamente este processo com a ajuda do T4 e construir diretrizes, incluindo a transferência das definições geradas para a caixa de areia do arquivo.
Não, Pyotr, você não pode competir com C# e Visual Studio. São categorias de peso diferentes.
Por que eu não deveria competir com você? Se apenas porque as utilidades escritas em MQL nativo podem ser vendidas, e não importa o quanto você tente com C# você não vai me superar nesta vantagem).
Quanto à facilidade de escrever programas GUI complexos - eu já o testei e você ainda não o fez. Portanto, no momento é você quem está tentando vencer com C# e não vice-versa. :))
Quanto à facilidade de escrever programas GUI complexos - eu já o testei, e você ainda não o fez. Então, neste ponto, é você com C# que está tentando competir comigo, não vice-versa. :))
Piotr, o que você testou? Onde está sua liberação? Você tem tudo em papel até agora.
Bem, por que não posso competir? Eu já estou ganhando pelo menos porque as utilidades escritas no MQL nativo podem ser vendidas, e não importa o quanto você tente com C#, você não vai me superar nesta vantagem))).
Peter, você se revela um mercurial Q!
Peter, você simplesmente não está ciente de todas as tecnologias que o C# e o Visual Studio oferecem. Em particular, você pode automatizar completamente este processo com a ajuda do T4 e construir diretrizes, incluindo a transferência das definições geradas para a caixa de areia do arquivo.
Não, Pyotr, você não pode competir com C# e Visual Studio. São categorias de peso diferentes.
Bem, você está puxando o desenvolvimento em uma direção errada, Vasily.
Aqui você fez este adaptador de código aberto no GitHub. E você está falando de vastas possibilidades de C#, tais como a possibilidade de portar qualquer coisa para uma caixa de areia de arquivo. E você acha que ninguém vai acrescentar a este adaptador o que ele quer e não vai começar a distribuir a versão viral fechada? E não haverá nenhum "otário" que o aceite?