Galeria de UIs escritas em MQL - página 24

 
hini #:
Como você pode se livrar de mais de cinco mil avisos gerados na compilação, muitos deles em arquivos de linguagem de marcação?
Não é possível. Isso é tecnicamente inevitável porque escrevemos código de marcação na matriz de strings. Esse tipo de dados é convencionalmente adequado para escrever quaisquer valores e palavras.

No final, isso não importa, porque o construtor é perfeitamente capaz de distinguir entre palavras-chave, nomes e valores numéricos.

Não há perda de dados devido a essa abordagem.
 
Teoricamente, você poderia escrever (int) ou (double) antes de cada valor numérico, mas deixo isso a critério do usuário.
 
Temos que "pisar na garganta" do compilador, mas no final ganhamos). Não é um grande problema.


Para que fique registrado. Eu respeito as regras de programação e os avisos do compilador, mas, nesse caso, não encontrei uma solução melhor. Sei que algumas pessoas podem não gostar dessa abordagem, mas ela acabou sendo a melhor. E inofensiva.
 
Espero realmente que amanhã eu possa postar uma atualização e que aqueles que quiserem possam finalmente começar a criar sua própria interface. Farei o possível para isso.
 
Реter Konow os avisos do compilador, mas, nesse caso, não consegui encontrar uma solução melhor. Sei que algumas pessoas podem não gostar dessa abordagem, mas ela acabou sendo a melhor. E inofensiva.
Uma pequena história:

Quando surgiu a questão de onde escrever o código de marcação, tive duas opções principais: em uma matriz de strings ou em um arquivo. Depois de ponderar os prós e os contras que me vieram à mente, decidi que uma matriz é muito melhor por vários motivos. Primeiro, a inicialização instantânea e o processamento do conteúdo da matriz pelo código do construtor. Em segundo lugar, o acesso extremamente rápido a atributos e propriedades individuais de controles do construtor/motor para leitura/sobregravação, se necessário (com um arquivo, isso seria um grande problema). E, em terceiro lugar, é muito mais fácil enviar uma matriz para um recurso por meio de um evento OnChartEvent() personalizado. É por isso que escolhemos uma matriz. E os avisos... bem, o que você pode fazer. Sempre é preciso sacrificar algo para atingir o objetivo.

 
Correção do texto acima: encaminhamento não por recurso, mas por fatias de strings compostas.
 
Bem, e a razão total que colocará o último prego na "tampa do caixão" da ideia de que a marcação poderia ser escrita em um arquivo de texto:

Um arquivo .txt não pode ser compilado para garantir que não haja erros grosseiros de digitação. Isso significa que, se o usuário errar alguma coisa com vírgulas, aspas, espaços, etc., ele NÃO SABERÁ DO COMPILADOR.

Somente depois de não conseguir criar a interface, ele terá que perceber que digitou mal o código e entrar no sistema para procurar e encontrar todos os erros de digitação. Se ele errar um erro sequer, o procedimento terá de ser feito novamente.

Esse é um preço absurdamente caro pela ausência de avisos do compilador.

É por isso que, na MQL, a variante com matriz de strings para código de marcação não tem alternativas e não pode ser usada. E os avisos do compil ador devem ser considerados como um dado adquirido.
 
P.S. O compilador avisa mesmo quando uma palavra-chave é digitada incorretamente. Às vezes, o intellisense ajuda. Em um arquivo .txt, se as palavras-chave forem escritas incorretamente, você não saberá. Portanto, não há nenhuma vantagem prática de um arquivo em relação a uma matriz.

Espero ter explicado em detalhes por que você não deve se livrar dos avisos do compilador nesse caso específico.

Bom dia a todos.

 
Реter Konow os avisos do compilador não devem ser removidos nesse caso específico.

Olá a todos.

Ok, entendi.
 
Essa parte do código está no centro do construtor?
Arquivos anexados: