Erros, bugs, perguntas - página 362

[Mykola Demko]

Lizar:
A necessidade de tal funcionalidade aumentará à medida que o número de tipos de objectos aumentar. E tornar-se-á necessário quando se criam objectos onde não se pode determinar o número de pontos de ancoragem pelo seu tipo. Por exemplo, pode ser uma polilinha de algum tipo. Mas por agora não é muito crítico, mas pode ser executado como um desejo no balcão de serviço.

Por agora, é mais realista (se houver tal necessidade) criar um interruptor de função que dará o número de pontos de ancoragem por tipo de objecto.

Basta fazer esta tabela (Referência MQL5 / Constantes padrão, enumerações e estruturas / Constantes de objectos / Tipos de objectos) em switch. O parâmetro de entrada da função será ObjectGetInteger(chart_id,name,OBJPROP_TYPE).

Não há perigos ocultos uma vez que todos os tipos estão rigidamente ligados a pontos de ancoragem. Mas se os objectos com número variável de pontos aparecerem, então haverá uma necessidade extrema para tal funcionalidade.

[---]

Urain:

Agora, a forma mais realista (se necessário) é criar uma função de comutação que dará o número de pontos de ancoragem com base no tipo de objecto.

Pedi um imóvel no ObjectGet há muito tempo atrás.

parece-me que isto tem a ver com a própria lógica nas entranhas do MT5.

Provavelmente apenas passa por todos os pontos e verifica-os para VAZIO. E se um ponto tem um dígito normal, ele constrói-se.

Assim, não há relação directa entre o tipo de objecto e o número de pontos de ancoragem.

É por isso que notou correctamente que tem de ser o próprio a fazer a troca.

[Konstantin Gruzdev]

Urain:

Agora, a forma mais realista (se necessário) é criar uma função de comutação que dará o número de pontos de ancoragem com base no tipo de objecto.

Basta fazer esta tabela (Referência MQL5 / Constantes padrão, enumerações e estruturas / Constantes de objectos / Tipos de objectos) em switch. O parâmetro de entrada da função será ObjectGetInteger(chart_id,name,OBJPROP_TYPE).

Não há perigos ocultos uma vez que todos os tipos estão rigidamente ligados a pontos de ancoragem. Mas se obtivermos novos objectos com um número variável de pontos, vamos precisar realmente desta funcionalidade.

sergeev:

Pedi um imóvel no ObjectGet há muito tempo atrás.

Se houver um objecto com um número variável de pontos, então tal funcionalidade será extremamente necessária.

Provavelmente apenas passa por todos os pontos e verifica-os para VAZIO. E se um ponto tem um dígito normal, ele constrói-se.

Assim, não há relação directa entre o tipo de objecto e o número de pontos de ancoragem.

Se houver um número variável de pontos, então haverá uma necessidade extrema para tal funcionalidade.

Sim, como escrevi acima, tenho isto implementado através de um interruptor. Funciona sem qualquer problema. Mas a ideia vai mais longe, eu quero mais comodidade e universalidade.

A propósito, penso que seria bom deixar os utilizadores criarem os seus próprios objectos. Por exemplo, pelo menos permitir a fusão de objectos padrão em grupos com uma "marca" comum. Para que fosse possível referir-se a um grupo de objectos como um só. Depois haveria alguns objectos complicados como polilinhas, anéis, toros... e assim por diante. E mesmo objectos de algum painel de controlo poderiam ser fundidos. E a Ctrl-B não produziria uma folha de objectos, mas sim nomes de grupos de objectos, ou algo semelhante. Além disso, o problema de obter 100000 eventos a partir de objectos modificados no manipulador OnChartEven() seria resolvido, porque estes 100000 objectos poderiam ser fundidos num grupo e receber apenas um evento CHARTEVENT_OBJECT_CHANGE. No fim de contas, seria uma beleza. Claro que se pode implementar tudo isto parcialmente através de aulas, mas não tudo.

[Vladimir Gomonov]

Lizar:

........ E a Ctrl-B não daria uma folha de objectos, mas sim nomes de grupos de objectos, ou algo do género...........

....... uma vez que estes 100000 objectos poderiam ser combinados num grupo e receber apenas um evento CHARTEVENT_OBJECT_OBJECT_CHANGE. Tudo em resumo, uma bela.......

Sonha, não tenhas esperanças.

:)

[Serge]

Estou a escrever um indicador para exibir castiçais para vários instrumentos ao mesmo tempo. Depois de o iniciar e antes de aparecerem as novas barras, tudo é apresentado correctamente:

Mas após o aparecimento de novos bares, ocorre um turno:

E ChartRedraw não ajuda. Embora, se eu carregar no botão certo, tudo está no seu devido lugar. Pode dizer-me como evitar o turno?

[Mykola Demko]

Opreço é o dobro ; normalizado automaticamente na MqlTradeRequest? (o que é improvável) e se não, porque é que ainda não há normalização na biblioteca padrão? (Levantei esta questão há 9 meses atrás).

Saí da situação simplesmente fazendo edições na biblioteca padrão, mas sabe-se que não é o caso (é demolido quando se actualiza).

bool CTrade::PositionOpen(const string symbol,ENUM_ORDER_TYPE order_type,double volume,
                          double price,double sl,double tp,const string comment)
{
...
m_request.price       =price; // ??????????
...
}

Se eu estiver errado, então indique em quê?

[Renat Fatkhullin]

Não fazemos a normalização automaticamente, uma vez que não nos é permitido alterar o preço do comerciante de modo a não sermos acusados de arbitrariedade.

O preço tem de ser normalizado por si próprio se estiver a utilizar o preço calculado. Quando uma encomenda é colocada com preços líquidos inalterados Bid/Ask, a normalização não é necessária.

[Mykola Demko]

Renat:

Não fazemos a normalização automaticamente, uma vez que não nos é permitido alterar o preço do comerciante de modo a não sermos acusados de arbitrariedade.

O preço tem de ser normalizado por si próprio se estiver a utilizar o preço calculado. Quando uma encomenda é colocada com preços líquidos inalterados Bid/Ask, a normalização não é necessária.

Obrigado, descobri o que eu queria. Tive de normalizar até mesmo o lance/roca em 4.

[Renat Fatkhullin]

Urain:
Obrigado, descobri o que queria. Até mesmo o lance/objecto teve de ser normalizado em 4.

Na verdade, no MT4 não é necessário normalizar o Bid and Ask. São sempre normalizadas por defeito.

Se tem um exemplo em mãos, por favor mostre-me.

[Mykola Demko]

Renat:

Na verdade, no MT4 não é necessário normalizar o Bid and Ask. São sempre normalizadas por defeito.

Se tiver um exemplo à mão, por favor mostre-mo.

Não tenho um exemplo à mão, foi há muito tempo atrás (talvez as construções actuais estejam bem), uma vez que houve tantos problemas que recebi pedidos no MT4 mesmo solicitando Bid and Ask, depois da normalização tudo correu bem, por isso havia uma regra para normalizar qualquer pedido. E sabe, o hábito é uma segunda natureza.