[ARQUIVO]Qualquer pergunta de novato, para não desorganizar o fórum. Profissionais, não passem por ela. Não posso ir a lugar nenhum sem você - 5. - página 371

Novo comentário
 
Fox_RM:

Não há praticamente nenhuma diferença, apenas um processo ligeiramente diferente de obter os pontos de controle A e B. Já tentei com arrays.

Então, entre A e B, eu também teria que passar pelas barras. Não vejo outra maneira, é por isso que estou perguntando.

Talvez alguém possa me dar uma dica. Talvez haja algo errado com a lógica da escrita de códigos?


1. evitar quebras de linha e organizar o código em uma escada.

2. Em vez de repetidas declarações condicionais curtas e repetidas, use construir se(...) ... senão...

3. Tire a chamada da função de formação do objeto gráfico do laço interno (freio principal).

 
Chiripaha:

este aqui:



... ou melhor ainda, um destes:

if (AOBuffer3[i]<=0){
   ExtMapBuffer1[i] =  nSum; Vol_Arr[i] =  Volume[i]*Point*coaf;
}
else{
   ExtMapBuffer1[i] = -nSum; Vol_Arr[i] = -Volume[i]*Point*coaf;
}
 
tara:

... ou melhor ainda, um desses:

Sim, eu concordo.

Recolho todas as minhas sugestões no comentário "antigo" (se alguma coisa). - Pode não ser muito "certo", mas não será disperso.

Acho que o problema é o acúmulo de textos - Refletido no comentário principal (não sei como ligar-se a ele - desculpe).

 
tara:

3. Tirar a função de formação do objeto gráfico do laço interno (freio principal).

Agora, eu também me pergunto - Como você faz isso? (implementar)

Hm.... Exatamente! - É empilhável. E os valores intermediários não são importantes.

      if (shift_up > shift_dn)
       {
        for (int dn_br = shift_dn; dn_br <= shift_up; dn_br++)            //-------------- Перебор значений внутри основного цикла
          {
           Vol_AO_up += Volume[dn_br]; 
          }   
         ObjectDelete ("Awesome_super_volumes"+up_koaf);        // Заодно и удалить старый текст, чтобы не копился
         SetText("Awesome_super_volumes"+up_koaf, DoubleToStr(Vol_AO_up,0), AO_time_dn, AO_dn, Blue);
       }

Então não haverá um monte deles...

 

Eu tenho esta chamada em minha função init:

GetMarketInfo();

Esta função aqui:

//+-------------------------------------------------------------------------------------+
//| Сбор рыночных данных                                                                |
//+-------------------------------------------------------------------------------------+
void GetMarketInfo()
{
   gd_spread = MarketInfo(Symbol(),MODE_SPREAD) * Point;
   gd_stopLevel = MarketInfo(Symbol(),MODE_STOPLEVEL)  * Point;
   gd_tickSize = MarketInfo(Symbol(),MODE_TICKSIZE);
}

Variáveis gd_spread, gd_stopLevel, gd_tickSize que declarei globalmente até agora. Agora decidi escrever algumas bibliotecas que utilizam estas variáveis. Acontece que eu movi estas variáveis para o arquivo de cabeçalho. Então, para evitar erros na compilação da biblioteca, eu deveria transferir a funçãoGetMarketInfo() para a biblioteca também, certo?

 
hoz:

Eu tenho esta chamada em minha função init:

Esta função aqui:

Variáveis gd_spread, gd_stopLevel, gd_tickSize que declarei globalmente até agora. Agora decidi escrever algumas bibliotecas que utilizam estas variáveis. Acontece que eu movi estas variáveis para o arquivo de cabeçalho. Então, para evitar erros na compilação da biblioteca, eu deveria transferir a funçãoGetMarketInfo() para a biblioteca também, certo?

Definitivamente não chamar esta função no init - spread and stoplevel pode variar no tempo
 
artmedia70:
Certamente não no init - a propagação e o nivelamento podem mudar com o tempo


Acho que o inite deve ser descartado, para evitar problemas no comércio real. Se a conexão for cortada por DC, e então aparecer, a reinicialização não acontecerá e isso causará erros e problemas no comércio real, certo?

Bem, o que devemos fazer então? Chamar constantemente alguma função em cada função que retornará essas variáveis de mercado?

 
hoz:


Acho que o init deve ser abandonado, para que não haja mau funcionamento no comércio real. Afinal, se a conexão for cortada pelo CD, e depois aparecer, a reinicialização não acontecerá, e já leva a erros e falhas quando se trabalha de verdade, certo?

Bem, o que fazer então? Chamar constantemente alguma função em cada função, que irá retornar essas variáveis de mercado?

Este tipo de informação deve ser dividido em variável e imutável.

Os dados imutáveis podem ser escritos em qualquer lugar, porque mesmo que haja uma quebra de conexão, os dados continuarão a ser relevantes. - Melhor, é claro, não no início, para não sobrecarregar a coruja desnecessariamente.

Mas as variáveis podem ser através de chamada de função (se a biblioteca for usada) ou apenas atualizá-las no início da função de início.

 

Isso também é verdade. O cérebro está sempre pensando na produtividade, em um momento em que a mente não sabe bem como fazê-lo da melhor maneira. Eu tenho um temperamento... um gêmeo :(

Certo, você tem que separar um do outro imediatamente.

Mas, mais uma vez. Se variáveis do ambiente de mercadogd_stopLevel,gd_tickSize são usadas em diferentes funções (funções de modificação, envio de pedidos, etc.), então não é muito razoável chamar funções que recebem valores especificados constantemente na função de biblioteca. Existe alguma maneira de unificar isto? Afinal, ao contrário do spread, o tamanho do stop loss e do tick será sempre o mesmo.

 
hoz:

Isso também é verdade. O cérebro está sempre pensando na produtividade, em um momento em que a mente não sabe bem como fazê-lo da melhor maneira. Eu tenho um temperamento... um gêmeo :(

Certo, você tem que separar um do outro imediatamente.

Mas, mais uma vez. Se variáveis do ambiente de mercadogd_stopLevel,gd_tickSize são usadas em diferentes funções (funções de modificação, envio de pedidos, etc.), então não é muito razoável chamar funções que recebem valores especificados constantemente na função de biblioteca. Existe alguma maneira de unificar isto? Afinal, ao contrário do spread, o tamanho do stop loss e do tick será sempre o mesmo.

A Artem já disse que o rochedo também pode flutuar - não é um valor constante! - E o tamanho do tick é, sim, uma constante.

Para unificar - novamente, dividi-lo em 2 funções - MarketInfoConst e MarketInfoImage (variável). Coloque um em Inite, o outro no início do(s) Start(s). E será possível combiná-lo em uma biblioteca.

A questão da produtividade (otimização de coruja) é diferente. Pessoalmente não enfiei todas estas funções na coruja. Eu apenas tomo os parâmetros conforme a necessidade. Sim, eu tenho que escrever mais código, mas a coruja lida com menos coisas "supérfluas" de biblioteca, porque nem tudo do MarketInfo pode vir a ser necessário na coruja.
1...364365366367368369370371372373374375376377378...432
Novo comentário