Perguntas de um "boneco" - página 12
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
POR FAVOR ACONSELHAR SOBRE O TERMINAL DO TELEMÓVEL.
QUANDO E QUANDO SERÁ QUALQUER APOIO PARA INDICADORES DE UTILIZADORES (NÃO NORMAL) OU CONSULTORES EM mql4 OU mql5 sejam REALIZADOS?????????????????????????????
EM QUE PLATAFORMAS (ANDRÓIDE, POR EXEMPLO) ISTO SERÁ IMPLEMENTADO????????????????? E QUANTO TEMPO?????????????
à espera da RESPOSTA, obrigado pela atenção
Interesting:
Bem, eu discordo dessa conclusão. OCO == "um cancela o outro". Bem, não existe tal coisa no MT5 onde uma encomenda cancela a outra. Há um ano que o lamento.Características como SL e TP fecham realmente uma posição aberta, mas a questão do "cancelamento"de ordens pendentes não tem nada a ver com isso.
Fazem-no, mas estas ordens são implementadas no servidor. E são os únicos realmente integrados no esquema OCO até agora (e não sonharíamos em implementar ordens "If Done" directamente no terminal e no servidor).
Ao abrir uma posição e definir TP e SL em MT5, usamos essencialmente a mesma forma (mas o resultado aqui é uma posição + 2 ordens de cancelamento).
Após a vossa mensagem, já comentei esta situação tomando em pormenor os SL e TP cancelados de forma intercambiável. No entanto, aqui gostaria de acrescentar o seguinte.
Se tivesse sido dito aos autores de ordens OCO que no século XXI a sua invenção será aplicada apenas aos níveis SL e TP, eles teriam ficado muito surpreendidos ao ver tanta limitação da área de aplicação do seu brainchild :) .De facto, tudo está de pernas para o ar: Todos os materiais que lêem referem-se à mesma coisa: as encomendas CCA são encomendas intercambiáveis cujos tipos são agora especificados na enumeração MQL5 ENUM_ORDER_TYPE. Nunca encontrei uma referência à ligação de ordens CCA e níveis SL-TP. Assim, o mecanismo de execução pode ser o mesmo mas é ENUM_ORDER_TYPE que o cliente executa mas não os níveis SL-TP (de acordo com MQ).
Assim, quando estou a escrever sobre ordens pendentes, refiro-me a ordens da lista ENUM_ORDER_TYPE e não a ordens "derivadas" baseadas em níveis SL-TP.
______________
* O "derivado" porque cada uma das ordens OCO pode ter diferentes níveis de SL-TP.
Senhores, a raiz da compreensão reside na simplicidade da plataforma. Simplicidade para 99% dos utilizadores e uma rejeição consciente de complicações que a restante percentagem de utilizadores pode compreender.
Coloque-se a questão "o que seria necessário para atrair X milhões de utilizadores para os mercados financeiros? Com experiência suficiente, a resposta estará perto de "fazer um sistema simples, removendo a complexidade e unindo os comerciantes num único ecossistema".
Em vez de empilharmos as definições de encomenda OCO (o painel não é realmente para a mente média), oferecemos um esquema de gestão de encomendas muito simples e directo com SL/TP integrado. A grande maioria das ordens OCO são apenas SL/TP para posições actuais. Ao colocarmos SL/TP dentro, minimizámos o número de encomendas adicionais e simplificámos grandemente a gestão de negócios.
ps: a emissão do sistema de encomendas está encerrada
ps: a emissão do sistema de encomendas está encerrada
ps: a emissão do sistema de encomendas está encerrada.
É uma pena que não seja possível fazer SLs/TPs normais (fiáveis) para negócios individuais (não posições totais).
Isto corta imediatamente a capacidade de (fiavelmente) negociar múltiplas estratégias no mesmo instrumento/conta.
Hali-vor não deve ser retomado, lembro-me da opinião dos criadores (um instrumento = uma posição = um SL e um TP)...
A que tipo (longo ou ulong) pertence realmente o ORDER_MAGIC?
ENUM_ORDER_PROPERTY_INTEGER
ORDEM_MAGIC
Identificador do Perito Conselheiro que fez a encomenda (destinado a cada perito a colocar o seu próprio número único)
longo
A que tipo (longo ou ulong) pertence realmente o ORDER_MAGIC?
ENUM_ORDER_PROPERTY_INTEGER
ORDEM_MAGIC
Identificador do Perito Conselheiro que fez a encomenda (destinado a cada perito a colocar o seu próprio número único)
longo
Penso que o resultado deve ser convertido para o tipo declarado no código (pode haver uma impressão errada na documentação).
Se estamos a falar de MqlTradeRequest, neste caso é muito provavelmente (ulong).
Na minha opinião, o resultado deve ser convertido para o tipo declarado no código (pode haver uma impressão errada na documentação).
Quanto à MqlTradeRequest, neste caso é muito provável (ulong), mas provavelmente muito tempo não terá problemas.
Em geral, a resposta não é sobre os méritos. A questão era muito clara: "a que tipo (longo ou ulong) pertence realmente aORDER_MAGIC"?
Vamos tentar ser substantivos:
1. ambos estes tipos podem ser declarados sem transformações.
2. Se utilizar apenas valores positivos de magik, é mais rentável especificar o seu valor como ulong (porque existe uma gama de valores possíveis de 0 a 18 446 744 073 709 551 615).
3. Por outro lado, a classe CExpert da Biblioteca Standard aplica valores longos na inicialização (o que lhe permite especificar valores negativos, mas desloca a gama de valores possíveis). Assim, ao inicializar esta classe, o valor do magik já pode ser de -9 223 372 036 854 775 808 a 9 223 372 036 854 775 808.
Esta declaração deve ser verificada.
4. Mas já na classe CTrade (da mesma biblioteca padrão) o mágico tem um valor ulong, pois deve basear-se na estrutura da consulta.
Vamos fazer algumas conclusões preliminares:
a) O trabalho com magik nas classes CExpert e CTrade não é consistente, uma vez que no primeiro caso é especificado há muito tempo, enquanto no outro ulong;
b) As classes em questão foram desenvolvidas por pessoas diferentes, ou o conjunto e estrutura de parâmetros para certas funções no CExpert foi escrito tendo em mente o CTrade (que pode ou não ter existido ainda).
c) O trabalho dos peritos associados ao desenvolvimento e documentação da biblioteca padrão não é totalmente coerente (embora, na sua maioria, se tenha visto um estudo bastante bom de questões-chave).
d) Se bem entendi, a interacção destas duas classes limita o valor do mágico a um intervalo de 0 a 9 223 372 036 854 775 808. Esta declaração deve ser verificada.
5. A estrutura MqlTradeRequest tem o tipo ulong para trabalhar com magik. Tudo é totalmente consistente com a classe CTrade, por isso é mais lógico especificar a gama de valores possíveis de mágico de 0 a 18 446 744 073 709 551 615 se utilizarmos apenas esta classe. Esta declaração deve serverificada.
PS
Penso que os criadores "fixaram" intencionalmente possíveis valores de um Mágico na gama de 0 a 9 223 372 036 854 775 808.
Os criadores parecem ter deliberadamente "amontoado" os valores possíveis de um magik numa gama de 0 a 9 223 372 036 854 775 808.
Na verdade, há até 8 bytes de informação dada à magia, que pode ser interpretada da forma que quiser. Pode ser datado, duplo, 4 curtos, 8 char, ou 64 bits bit a bit.
Com quatro, 4 bytes de magia eram suficientes para codificar qualquer coisa, mas agora temos 8. Tudo o que é preciso é a vontade.