Como verificar se um pedido é selecionado - página 4
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
Na verdade, tem havido muita demagogia.
Tudo o que precisamos saber se um pedido é selecionado ou não.
Expliquei isso no início do tópico, não está claro?
Temos alguma função que potencialmente trata de ordens, ou seja, seleciona-as e as analisa. Ele pode ser chamado a partir de diferentes fragmentos de código, incluindo aqueles que já têm uma ordem selecionada para trabalhar. Se esta função separada não salvar a ordem já selecionada e restaurar sua seleção, isto levará a erros na lógica EA, pois quando voltarmos desta função, a ordem selecionada antes de ser chamada estará errada. Portanto, para evitar estes erros, precisamos lembrar a ordem atualmente selecionada do local de sua chamada em cada função auxiliar que trata de ordens por si só e retornar sua seleção quando ela for feita. Como realizar esta tarefa facilmente e sem gerar erros - esta é a questão do tema atual
// Isso implica que uma ordem é selecionada através do OrderSelect (ou há um erro).
Por que um erro? Se a ordem não for escolhida, esta ação simplesmente não é necessária, mas parece ser impossível descobrir antecipadamente se a ordem é escolhida ou não sem truques especiais
// Então por que deve ser selecionado novamente?
É por isso que após retornar desta função para a parte de chamada do código, a ordem selecionada nesta parte do código antes da chamada da função permanece selecionada - para que as operações que são realizadas com a ordem atualmente selecionada não conduzam a erros
Não, ele está realmente no tanque.
Eu expliquei tudo no início do fio, é assim tão pouco claro?
Temos alguma função que potencialmente funciona com os pedidos, ou seja, seleciona-os e analisa-os. Ele pode ser chamado a partir de diferentes fragmentos de código, incluindo aqueles que já têm uma ordem selecionada para trabalhar. Se esta função separada não salvar a ordem já selecionada e restaurar sua seleção, isto levará a erros na lógica EA, pois quando voltarmos desta função, a ordem selecionada antes de ser chamada estará errada. Portanto, para evitar estes erros, precisamos lembrar a ordem atualmente selecionada do local de sua chamada em cada função auxiliar que trata de ordens por si só e retornar sua seleção quando ela for feita. Como realizar esta tarefa facilmente e sem gerar erros é a questão deste mesmo tópico
1. Para passar para a função o número da ordem selecionada antes de ser chamada.
2. Quando a função terminar, selecione novamente a mesma ordem.
Como eu sei o que você quer obter? Você terá que ser mais específico :(
1. Enviar o número da ordem selecionada antes da chamada da função.
2. Quando a função terminar, re-selecione a mesma ordem.
Como eu sei o que você quer obter? Você deve ser mais claro :(
Sim, eu entendo, porém, gostaria de escrever funções informativas, tais como lucro total ou ordens abertas, que podem ser chamadas sem pensar que mudarão algo na lógica de execução do programa. Isto faz sentido, eu acho.
Nem sempre é trivial passar a ordem selecionada na função de chamada, imagine que o aninhamento de chamadas >1, deveríamos passar um bilhete para cada função para que alguma função de informação menor pudesse usá-la?
Seria mais lógico dar uma embalagem para OrderSelect e OrderTicket, que armazenaria e obteria informações sobre a ordem atualmente selecionada de uma variável separada, mas aqui acabamos com a duplicação de informações (o terminal já sabe se a ordem é escolhida, mas não podemos passar essas informações sem um erro potencial). Assim, ou obtemos duplicação de informações ou complicação excessiva de funções (também passamos a ordem selecionada do topo para cada parâmetro), ou a geração forçada de erros de execução do programa.
Sim, eu entendo isso, mas gostaria de escrever funções informativas, tais como lucro total ou número de ordens abertas, que podem ser chamadas sem pensar que elas mudarão a lógica de execução do programa. Isto faz sentido, eu acho.
Faz sentido, mas neste caso devemos pelo menos dividir as funções em "brancas" e "pretas". O número de ordem selecionado no primeiro é salvo, e quando é violado no segundo, é restaurado.
Parece ser tão simples quanto isso.
Sim, eu entendo isso, mas gostaria de escrever funções informativas, tais como lucro total ou número de ordens abertas, que podem ser chamadas sem pensar que elas mudarão a lógica de execução do programa. Isto é bastante lógico, eu acho.
Nem sempre é trivial passar uma ordem selecionada em uma função de chamada, imagine que o agrupamento de chamadas é >1, não deveria ser passado um bilhete para cada função para que alguma função de informação menor pudesse usá-lo?
Veja a biblioteca de funções da Kim e você verá que cada função está enumerando, selecionando e verificando o ingresso, e depois o que você precisa saber. Sua "lógica" não permite que você aprenda as regras básicas de programação.
Você tem um ancião em um campo, e um tio em Kiev.
Veja a biblioteca de funções da Kim e veja que cada função faz a enumeração, seleção e verificação do bilhete e, em seguida, o que precisa ser aprendido. Sua "lógica" não lhe permite aprender as regras alfabéticas de programação.
Um pouco mais velho em um jardim e um tiozinho em Kiev.
Boris, não é necessário. Estou falando dos ABCs.