Como verificar se um pedido é selecionado - página 19
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
Em princípio, sim, mas o "ponteiro" terá que ter seu próprio ponteiro. pense na minha sugestão com a função, parece-me uma solução universal. é claro que há uma questão sobre a velocidade de tal código, mas parece ser a terceira questão.
Obrigado, estou sempre feliz em ter uma conversa construtiva.
Portanto, se a função A no programa seleciona alguma ordem no laço e depois chama a função auxiliar B da biblioteca, mesmo que B selecione outra ordem no processo, a seleção da ordem na função A não deve ser afetada pelo retorno.
Obrigado, sempre feliz em ter uma conversa construtiva.
De nada, mas não tire conclusões precipitadas.
Se você armazena o valor da função em uma variável, sim. Caso contrário, a função é global e pode mudar na primeira chamada.
Estou um pouco confuso. Eu quis dizer a seguinte situação: chamamos de função biblioteca B() da função A() no módulo do programa principal, que, por exemplo, simplesmente seleciona a primeira ordem na lista (assumindo que há uma ordem a priori):
nulo B(){
OrderSelect(0,SELECT_BY_POS);
}
Quando o controle retornar da biblioteca para o módulo principal após esta função ter sido chamada, se chamarmos OrderTicket() ou qualquer outra função nela que espera que a ordem seja pré-selecionada, obteremos exatamente o mesmo erro 4105. Mas se antes da chamada da função B no módulo principal alguma outra ordem já tiver sido selecionada, ela permanecerá selecionada independentemente do novo Select na biblioteca, porque a ordem atualmente selecionada, como eu a entendo, é única apenas dentro do módulo.
Mas se chamarmos a mesma função B da função A do módulo principal, então a ordem selecionada na função A antes da chamada para B mudará para ordem 0 (ou seja, a ordem atualmente selecionada após retornar da função B será ordem 0, não importa qual era a ordem atualmente selecionada antes da chamada para B).
Portanto, se chamarmos uma função que utilize OrderSelect por si só, devemos nos certificar de que, ao retornarmos desta função, a ordem que escolhemos antes de chamarmos esta função, para que possamos usá-la mais tarde. Se você não tiver certeza disso, isso pode levar a erros lógicos difíceis de encontrar em seu código.
Especificamente, o "ponteiro" - o estado da seleção da ordem atual - é global dentro do módulo, ou seja, este ponteiro é o mesmo para a biblioteca e diferente para o módulo do programa. Isto significa que se a função A no programa seleciona alguma ordem no laço e então chama a função auxiliar B da biblioteca, então mesmo que durante sua operação B selecione outra ordem, a seleção da ordem na função A não deve ser alterada no retorno. Mas se ambas as funções estão dentro de um módulo, então ao retornar da função B, precisamos lembrar e restaurar a seleção da ordem atual antes e depois de B ser chamada na própria função A ou na função B quando ela começar e terminar seu trabalho, para que a lógica do trabalho da função A não seja violada naquele ponto.
Seu ponto é claro...
E vejo uma analogia com as construções populares do Expert Advisor quando os números dos bilhetes são armazenados em variáveis e usados mais tarde (nos próximos tiquetaques, como se um byyticket fosse aberto, etc.)...
Se você quiser obter um bilhete do último pedido aberto, basta usar as propriedades deste pedido, OrderSelect() e tudo ficará bem.Isso significa que a qualquer momento, o Expert Advisor tem que "entender" em que estado está a estratégia comercial e agir de acordo com este estado, não importa o que aconteça com a eletricidade e outros Expert Advisors em funcionamento no terminal.
Quando o controle retornar da biblioteca para o módulo principal após esta função ter sido chamada, se chamarmos a função OrderTicket() ou qualquer outra função nela que foi projetada para a ordem a ser pré-selecionada, teremos exatamente o mesmo erro 4105. Mas se antes de chamar a função B no módulo principal alguma outra ordem já tiver sido selecionada, ela permanecerá selecionada independentemente do novo Select na biblioteca, porque a ordem atualmente selecionada, como eu a entendo, é única apenas dentro do módulo.
está provado que funciona desta maneira, ou você acha que funciona desta maneira?
Para mim não há separação em módulos e bibliotecas... uma vez compilado o código funciona como uma construção única...
onde OrderSelect() for chamado o mesmo OrderTicket() da última ordem selecionada será devolvido...
Acho que deveria funcionar assim...
está provado que funciona dessa maneira, ou você acha que funciona?
Para mim não há divisão em módulos e bibliotecas... após a compilação, o código funciona como uma construção única...
Onde quer que a OrderSelect() seja chamada a mesma OrderTicket() da última ordem selecionada será devolvida...
Acho que deveria funcionar assim...
Foi verificado que a ordem selecionada na biblioteca não é a ordem selecionada quando ela é devolvida no módulo principal. Portanto, a ordem que é logicamente selecionada deve ser a última ordem selecionada no módulo principal, embora eu ainda não a tenha verificado.
Resolvi este problema por mim mesmo criando invólucros para funções de biblioteca no arquivo mqh da biblioteca, semelhante ao seguinte:
bool GetOrder(int a=0){
return(OrderSelect(_GetOrder(a),SELECT_BY_TICKET));
}
A propósito, você também não pode passar parâmetros padrão para funções de biblioteca.
Aqui _GetOrder(int a) é a própria função da biblioteca que encontra e devolve algum pedido. A função é chamada a partir da biblioteca com um parâmetro explícito "a", na função de embalagem é 0 por padrão, mais o ticket retornado na embalagem é selecionado novamente no módulo principal do programa, porque sua seleção na função da biblioteca não chegará ao "destinatário".
Também acho que, não importa de onde esta função seja chamada, ela dará um conjunto de parâmetros selecionados para uma determinada ordem e o programa não os alterará até a próxima chamada para esta função, não importa de onde essa chamada venha.
Por que outra razão você envolveria esta função em uma função adicional, completamente desnecessária?
PYSYS. Conselhos - crie uma variável inteira estática, passe o valor do pedido após a abertura, ela não mudará, até que você queira, e executará com precisão o que você planejou.
Verificou se a ordem selecionada na biblioteca não é a ordem selecionada ao retornar ao módulo principal. Portanto, logicamente, a ordem selecionada no retorno deve ser a última ordem selecionada no módulo principal, embora eu ainda não tenha verificado isto.
Esta afirmação precisa ser esclarecida: A afirmação é verdadeira se estamos falando de um módulo (biblioteca) que é compilado APENAS (*.mg4-libraries from the libraries folder). Para os módulos que fazem parte do arquivo principal compilado (*.mgh-library), esta afirmação NÃO é verdadeira!
MQH não é um módulo separado, mas um inserto no módulo principal, localizado em um arquivo diferente. Portanto, é claro que estamos falando de uma biblioteca .ex4 separada