OrderSend() perguntas - página 6
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
Estou a bater o meu cérebro... a paragem não se estabelece... e muitos erros. isto é o que resta da experiência, e não vai funcionar mais
Se o fizer, não há erros, mas o stop-loss ainda não está definido
Aparentemente, não expliquei o problema anterior de forma muito clara. Deixe-me tentar novamente.
Durante o último ano, a descrição da lista de valores de enumeraçãoENUM_ORDER_TYPE_FILLING foi alterada pelo menos três vezes. A descrição anterior era a seguinte
ENUM_ORDER_TYPE_FILLING
Identificador
Descrição
ORDER_FILLING_FOK
Uma transacção só pode ser executada no volume especificado e a um preço igual ou melhor do que o especificado na encomenda. Se não houver oferta suficiente no mercado neste momento para o símbolo da encomenda, então a encomenda não será preenchida. Este tipo de preenchimento é utilizado no modo de execução SYMBOL_TRADE_EXECUTION_INSTANT ouSYMBOL_TRADE_EXECUTION_REQUEST.
ORDER_FILLING_IOC
Um acordo para executar uma transacção no volume máximo disponível no mercado dentro do volume especificado na ordem e a um preço igual ou melhor do que o especificado na ordem. Neste caso, não serão feitas encomendas adicionais para o volume em falta. Este tipo de preenchimento só pode estar disponível nos modos de execução SYMBOL_TRADE_EXECUTION_MARKET eSYMBOL_TRADE_EXECUTION_EXCHANGE dependendo das definições no servidor de negociação.
ORDER_FILLING_RETURN
Acordo para tornar uma transacção no volume máximo disponível no mercado dentro do volume especificado na ordem e a um preço igual ou melhor do que o especificado na ordem. Neste caso, será feita uma encomenda adicional para o volume em falta ao preço especificado nesta encomenda. Este tipo de enchimento é utilizado apenas para encomendas pendentes (TRADE_ACTION_PENDING).
Como podemos facilmente ver, existe uma correspondência um-para-um entre ORDER_FILLING_RETURN e ordens pendentes, nomeadamente ORDER_FILLING_RETURN só poderia ser aplicado a encomendas pendentes e o campo type_filling de todas as encomendas pendentes só poderia ser preenchido com o valor de ORDER_FILLING_RETURN.
Para ordens de mercado(action===TRADE_ACTION_DEAL) o campo type_filling deveria ter sido preenchido em função dos modos de execução definidos no lado do servidor.
Assim, tínhamos um certo paradigma: se houvesse uma ordem pendente,ORDER_FILLING_RETURN; se houvesse uma ordem de mercado, ORDER_FILLING_FOK ou ORDER_FILLING_IOC (dependendo do modo).
Agora tudo está um pouco virado do avesso, nomeadamente:
ENUM_ORDER_TYPE_FILLING
Identificador
Descrição
ORDER_FILLING_FOK
Esta política de preenchimento de encomendas significa que a encomenda só pode ser preenchida até ao volume especificado. Se não houver volume suficiente do instrumento financeiro no mercado neste momento, a ordem não será executada. O volume necessário pode ser compilado a partir de várias ofertas actualmente disponíveis no mercado.
ORDER_FILLING_IOC
Indica acordo para executar uma transacção até ao volume máximo disponível no mercado dentro do volume especificado na ordem. Se a execução completa não for possível, a encomenda será preenchida até ao volume disponível, e o volume não preenchido será cancelado.
ORDER_FILLING_RETURN
Este modo só é utilizado para encomendas de ORDER_TYPE_BUY_LIMIT e ORDER_TYPE_SELLL_LIMIT. Em caso de execução parcial, a ordem limite com o volume restante não é eliminada, mas permanece em vigor.
Para ORDER_TYPE_BUY_BUY_STOP_LIMIT e ORDER_TYPE_SELLL_STOP_LIMIT ordena a ordem correspondente ORDER_TYPE_BUY_LIMIT/ORDER_TYPE_SELLL_LIMIT com o tipo de execução ORDER_FILLING_RETURN será criada aquando da activação.
A restrição de utilizar ORDER_FILLING_FOK e ORDER_FILLING_IOC apenas com ordens do mercado desapareceu. Também não há restrições à utilização de ORDER_FILLING_FOK e ORDER_FILLING_IOC com ordens de mercado, dependendo do modo de execução definido no servidor. Existe uma restrição ao uso de ORDER_FILLING_RETURN apenas com ordens de limite e stop_limit .
Então a minha pergunta é: É aceitável usar ORDER_FILLING_FOK e ORDER_FILLING_IOC para todas as ordens (tanto de mercado como pendentes), incluindo ordens de limite e stop_limit? Alguém descobriu as mudanças?
Sim, é um pouco obscuro nesta questão.
Se houver correspondência completa entre ENUM_SYMBOL_TRADE_EXECUTION e ENUM_ORDER_TYPE_FILLING , então a segunda é obviamente desnecessária.
Assim, não há moralidade, e muito provavelmente são permitidos valores diferentes deENUM_ORDER_TYPE_FILLINGpara um e o mesmoENUM_SYMBOL_TRADE_EXECUTION . MQ descreveria aqui um quadro de possibilidades, mas muito provavelmente estes dados dependem das configurações do servidor de negociação.
E daí a segunda moral, o que afinal é necessário:
é necessária uma função que devolva uma lista de opções válidas (ENUM_ORDER_TYPE_FILLING), para o tipo de encomenda solicitada (imediata ou pendente).
Não há muitas opções, por isso pode entrar no int através do "|".
Se eu estiver errado, dê-me um feiticeiro mágico, onde procurar esta pergunta.
Para resolver esta questão, fui à biblioteca padrão (por uma questão de hábito, se não é claro como os outros o fazem).
A função de herança conveniente foi aí dada, enquanto na classe SetTypeFilling() da CTrade não é utilizada, o campo type_filling é inicializado por defeito zero que corresponde a ORDER_FILLING_FOK de acordo com a enumeração.
É tudo, acabou-se o trabalho. E eu pensei que por este campo não estar presente na interface, significa que o enchimento é automatizado na classe.
SZY em geral, à espera de uma resposta, como resolvê-lo :)Até agora, vejo uma solução: bater no servidor até obter a resposta que deseja.
Uma boa noite de diversão, fez-me rir até ao estômago.
Os chineses invadiram o servidor principal do Pentágono.
Todos os chineses tentaram uma vez digitar a senha.
Todas as outras pessoas escreveram "Mao Tse Tung".
Em 5*10^7 tentativas, o servidor diz que a senha é "Mao Tse Tung".
Por agora, vejo uma saída: bater no servidor até obter a resposta certa.
saída estúpida.
Deve falar primeiro com o seu CD. Descubra que tipos de execução suportam e que tipos de lista de metaquotas correspondem aos seus tipos de execução.
porque só porque as metaquotas surgiram - 3 tipos de preenchimento e 3 tipos de tempo - não significa que elas sejam um reflexo da realidade quando se trata de preencher encomendas num corretor real.
saída estúpida.
Deve falar primeiro com o seu CD. descubra que tipos de execução suportam e que tipos de lista de metaquotas correspondem aos seus tipos de execução.
porque só porque as metaquotas surgiram - 3 tipos de preenchimento e 3 tipos de vezes - não significa que sejam um reflexo da realidade quando se trata de preencher encomendas num corretor real.
É isso que estou a dizer, tudo depende das configurações do servidor,
Mas bater em todas as empresas de corretagem é também um problema,
por exemplo, numa empresa de corretagem pode obter uma encomenda para uma corretagem real,
mas contornar tudo e escrever os aneis de troca no seu código é exagero.
Se sentir que já se registou connosco, pode começar do zero com um verdadeiro corretor ou pode abri-los do zero,
PS concorda que o código normal é escrito de uma forma unificada, para qualquer negociação, são possíveis excepções, mas em primeiro lugar confirmam as regras, e em segundo lugar, se houver excepções, tem de escrever as excepções.
Aqui, tal tautologia acaba por se revelar.
Este é o meu ponto de vista, tudo depende das configurações do servidor,
Mas seria problemático bater em cada empresa de corretagem,
Se não souber a diferença entre os dois, pode pensar que a ordem será copiada para a ordem correcta,
mas contornar tudo e escrever os aneis de troca no seu código é exagero.
PS deve concordar que o código normal é escrito de uma forma unificada, para qualquer tipo de negociação,
PS concorda que o código normal é escrito de uma forma unificada para cada negociação, as excepções são possíveis, mas primeiro as excepções apenas confirmam as regras e segundo se houver excepções, terá de escrever as excepções. Aqui, tal tautologia acaba por se revelar.
eis o que se passa.
as metaquotas são confundidas com os tipos e tempos de execução. são não normalizadas no sentido em que na realidade as ordens IOC e FOK se referem a tempos de execução.
O tipo de execução da ordem costumava ser adequadamente nomeado AON. mas foi depois removido.
Veja a especificação FIX que a CAF utiliza e executa as encomendas
Marquei tipos que levaram meta-cotas para si próprios. Mas como podem ver, todos eles estão num grupo da etiqueta TimeInForce <59>.
E agora por favor digam-me como o corretor que coloca ofertas no mercado irá processar a colocação tipo IOC e tempo GTD na ordem MT. Porque este é um campo, não dois diferentes.
Por conseguinte, cada corretor pensará por si próprio o que fazer com o enchimento e que tipo de utilização e como retirar a encomenda.
A única graça de poupança é a diferença entre o mercado e a ordem pendente, ou seja, alguns tipos de execução de ordens são utilizados apenas para ordens pendentes e outros para ordens de mercado. Em geral, devemos olhar para este ponto e discuti-lo.
O nome All-Or-Nothing está na etiqueta completamente diferente ExecInst <18>, que não é passada na ordem MT de forma alguma. É implicitamente assumido (provavelmente) para o tipo FOK
...
Alex assume este tópico, por favor. Infelizmente, sou um flutuador nestas questões.
Faça sugestões para o SD, fale com eles.
Temos de colocar o tema em alguma ordem.
O que temos agora não é de modo algum utilizável para programação profissional.
Alex, assuma este tópico, por favor. Infelizmente, estou a nadar nestas matérias.
Fazer sugestões para o sd, falar com eles.
Precisamos de pôr o tema em ordem.
Não tenho a certeza se o que temos agora é adequado para programação profissional.
Ha. Ou eu sou estúpido ou os meus esquis não estão a correr.
Vê você mesmo que todos os meses as metaquotas fazem uma ligação a uma nova bolsa ou mercado.
Do qual concluo que, neste estado de coisas, os seus programadores atracam MT e FIX sem problemas (ou com alguma tensão com limitação de um deles).
Assim, podem combinar os tipos de tempo FOK e GTC, o que significa que é pouco provável que mudem alguma coisa num futuro previsível, uma vez que o trabalho está em curso.
Ao mesmo tempo (compreendo) que para a ponte de troca da MT só podem definir dois tipos - AON ou Parcial. E inventado em MT Return - provavelmente vai para Partial.
Em geral, as questões de interacção entre o corretor FIX e o servidor de MT situam-se no plano dos programas de perícia e compreensão no corretor, que fazem pontes da MT para os seus fornecedores. E não creio que as metaquotas mudem alguma coisa, porque têm uma longa e activa promoção da plataforma para os mercados, e portanto a estrutura interna do servidor de MT é bastante consistente com as realidades.