Encontrei um problema de sobrecarga da pilha de chamadas (por isso, penso eu).
Depois de chamar um método de um dos objectos , ver exemplo abaixo. O código é simplificado, apenas a sua essência. A classe CClass1 é uma classe base e a list1 tem diferentes objectos que são descendentes desta classe e as suas funções init são implementadas de forma diferente. Assim, numa classe em que a função init vai buscar tal lista (para simplificar, inicializa uma interface aninhada, um painel no painel) após retornar do init na linha
há um erro
2010.12.02 00:21:00 test1 (EURUSD,H1) Acesso ao ponteiro inválido em 'Container.mqh' (74,10)
Isto é, o ponteiro t está morto.
Quando se depura, não existe tal erro, após o ponteiro de chamada do método estar "vivo", são criadas interfaces aninhadas e o Expert Advisor continua a trabalhar.
Esta é a única forma de contornar o erro:
#O ponteiro do tamanho da pilha de propriedades não conseguiu nada.
É difícil dizer alguma coisa ao certo. É necessário o código fonte.
Voltei das férias, comecei a construir terminais, actualizei para 360 e um indicador deixou de funcionar...
Li as alterações: 6. MQL5: Processamento fixo do evento de clique sobre um gráfico.
Agora quando clica num objecto gráfico são gerados dois eventos ao mesmo tempo: CHARTEVENT_OBJECT_CLICK + CHARTEVENT_CLICK, enquanto antes só havia um CHARTEVENT_OBJECT_CLICK, o que permite simular um duplo clique
Voltou das férias, iniciou os terminais, actualizou para 360 build e um indicador deixou de funcionar...
leitura em mudanças: 6. MQL5: Processamento fixo do evento de clique sobre um gráfico.
Agora quando clica num objecto gráfico são gerados dois eventos ao mesmo tempo: CHARTEVENT_OBJECT_CLICK + CHARTEVENT_CLICK, enquanto antes só havia um CHARTEVENT_OBJECT_CLICK, o que permite simular um duplo clique
E, claro, é necessário colocar os Inits na ordem correcta no caso de aulas herdadas
Em geral, gostaria que escrevessem um artigo sobre o tratamento de erros em projectos complexos, Imprimir e devolver, pois aqui não é a solução.
Ou seja, criar um pré-construtor que complete o processo de construção, e que por sua vez exiba uma bandeira de inicialização.
Em geral, é uma boa solução, mas existem alguns inconvenientes. Temos de sondar cada função com bandeira de inicialização, e com um grande número de funções de classe, não é conveniente.
E se tivermos de mudar alguma coisa, todas as funções teriam de ser reescritas.
SZ Eu editei o código, corrigi a gralha.
class test
{
private:
bool inited;
intvalue;
public:
test(void){inited=false;};
bool Set(int passed){value=passed;return(true);};
bool Init(int passed)
{
if(Set(passed))inited=true;
return(inited);
};
int Get()
{
if(!inited)
{
Print("Объект неинициализирован");
return(-1);
}
return(value);
};
};
//+------------------------------------------------------------------+//| |//+------------------------------------------------------------------+void OnStart()
{
test var;
var.Init(1);
Print(var.Get());
test var2;
Print(var2.Get());
}
Isto é, criar um pré-construtor que completaria o processo de construção, e que por sua vez, colocaria uma bandeira de inicialização.
Em geral, é fixe, mas há alguns inconvenientes. Teremos de consultar cada função para a bandeira de inicialização, e com um grande número de funções de classe, isto não é conveniente.
O código foi actualizado pela primeira vez da mesma forma que pela segunda vez.
SZ Eu editei o código, fixei a supervisão.
bem, se houvesse um construtor, isso não significaria que a inicialização fosse bem sucedida. em qualquer caso, é necessário verificar o facto da inicialização
claro que se pode verificar uma vez:
void OnStart()
{
test var;
if( ! var.Init(1)){
// здесь какято обрабткаreturn;
};
Print(var.Get());
test var2;
Print(var2.Get());
}
Mas se utilizar o seu próprio código, pode fazer dele uma regra para verificar o facto da inicialização no momento da chamada, e se for utilizado por outros, não pode escrever em instruções: "deve utilizar apenas esta construção, caso contrário não posso garantir as consequências". Não, tem de verificar a inicialização nos métodos de classe de qualquer forma.
A actualização do terminal instalado em pasta diferente foi bem sucedida, os símbolos estão na lista (mas não havia gráficos abertos antes da actualização)...
Por favor, digam-me se isto é um insecto ou não permitido.
Receberá um erro
O mais provável é que o ArrayInitialize() se destine a preencher apenas matrizes de um certo tipo, numérico para ser exacto (muito provavelmente int ou duplo).
Porque a matriz tem tipo ENUM_ORDER_TYPE de chamada de ArrayInitialize irá causar um erro, dizendo que este método de chamada não é permitido.
Na minha opinião, há duas opções neste caso:
1. mudar o tipo de matriz ENUM_ORDER_TYPE para int, tendo-o ao mesmo tempo em conta no código (pelo menos os tipos de ordem podem ser facilmente representados como int);
2. Implementar de forma independente a "inicialização" da matriz.
Encontrei um problema de sobrecarga da pilha de chamadas (por isso, penso eu).
Depois de chamar um método de um dos objectos , ver exemplo abaixo. O código é simplificado, apenas a sua essência. A classe CClass1 é uma classe base e a list1 tem diferentes objectos que são descendentes desta classe e as suas funções init são implementadas de forma diferente. Assim, numa classe em que a função init vai buscar tal lista (para simplificar, inicializa uma interface aninhada, um painel no painel) após retornar do init na linha
há um erro
2010.12.02 00:21:00 test1 (EURUSD,H1) Acesso ao ponteiro inválido em 'Container.mqh' (74,10)
Isto é, o ponteiro t está morto.
Quando se depura, não existe tal erro, após o ponteiro de chamada do método estar "vivo", são criadas interfaces aninhadas e o Expert Advisor continua a trabalhar.
Esta é a única forma de contornar o erro:
#O ponteiro do tamanho da pilha de propriedades não conseguiu nada.É difícil dizer alguma coisa ao certo. É necessário o código fonte.
Tente escrever um pedido para o Servicedesk.
Voltei das férias, comecei a construir terminais, actualizei para 360 e um indicador deixou de funcionar...
Li as alterações: 6. MQL5: Processamento fixo do evento de clique sobre um gráfico.
Agora quando clica num objecto gráfico são gerados dois eventos ao mesmo tempo: CHARTEVENT_OBJECT_CLICK + CHARTEVENT_CLICK, enquanto antes só havia um CHARTEVENT_OBJECT_CLICK, o que permite simular um duplo clique
Será sempre assim ou será um insecto?
Voltou das férias, iniciou os terminais, actualizou para 360 build e um indicador deixou de funcionar...
leitura em mudanças: 6. MQL5: Processamento fixo do evento de clique sobre um gráfico.
Agora quando clica num objecto gráfico são gerados dois eventos ao mesmo tempo: CHARTEVENT_OBJECT_CLICK + CHARTEVENT_CLICK, enquanto antes só havia um CHARTEVENT_OBJECT_CLICK, o que permite simular um duplo clique
Será sempre assim ou será um insecto?
Mais uma vez bati na parede da impossibilidade,
Preciso de passar um parâmetro ao construtor, para que a classe seja inicializada com certos parâmetros,
como contornar este problema? O que é que recomendam?
Mais uma vez, bati na parede da impossibilidade,
Preciso de passar um parâmetro ao construtor para que a classe seja inicializada com certos parâmetros,
Como contornar este problema?
к
bem, não vejo outra saída
e, claro, tem de colocar os Inits na ordem correcta no caso de aulas herdadas
Gostaria que escrevessem um artigo sobre o tratamento de erros em projectos complexos,Imprimir e devolver, pois aqui não é a solução.
Bem, não vejo qualquer outra saída.
E, claro, é necessário colocar os Inits na ordem correcta no caso de aulas herdadas
Em geral, gostaria que escrevessem um artigo sobre o tratamento de erros em projectos complexos, Imprimir e devolver, pois aqui não é a solução.
Ou seja, criar um pré-construtor que complete o processo de construção, e que por sua vez exiba uma bandeira de inicialização.
Em geral, é uma boa solução, mas existem alguns inconvenientes. Temos de sondar cada função com bandeira de inicialização, e com um grande número de funções de classe, não é conveniente.
E se tivermos de mudar alguma coisa, todas as funções teriam de ser reescritas.
SZ Eu editei o código, corrigi a gralha.
Isto é, criar um pré-construtor que completaria o processo de construção, e que por sua vez, colocaria uma bandeira de inicialização.
Em geral, é fixe, mas há alguns inconvenientes. Teremos de consultar cada função para a bandeira de inicialização, e com um grande número de funções de classe, isto não é conveniente.
O código foi actualizado pela primeira vez da mesma forma que pela segunda vez.
SZ Eu editei o código, fixei a supervisão.
bem, se houvesse um construtor, isso não significaria que a inicialização fosse bem sucedida. em qualquer caso, é necessário verificar o facto da inicialização
claro que se pode verificar uma vez:
Mas se utilizar o seu próprio código, pode fazer dele uma regra para verificar o facto da inicialização no momento da chamada, e se for utilizado por outros, não pode escrever em instruções: "deve utilizar apenas esta construção, caso contrário não posso garantir as consequências". Não, tem de verificar a inicialização nos métodos de classe de qualquer forma.
Aos promotores.
Imediatamente após o reinício da nova construção
PS
A actualização do terminal instalado em pasta diferente foi bem sucedida, os símbolos estão na lista (mas não havia gráficos abertos antes da actualização)...
Diz-me se se trata de um insecto ou se não é permitido.
Dá um erro
Por favor, digam-me se isto é um insecto ou não permitido.
Receberá um erro
O mais provável é que o ArrayInitialize() se destine a preencher apenas matrizes de um certo tipo, numérico para ser exacto (muito provavelmente int ou duplo).
Porque a matriz tem tipo ENUM_ORDER_TYPE de chamada de ArrayInitialize irá causar um erro, dizendo que este método de chamada não é permitido.
Na minha opinião, há duas opções neste caso:
1. mudar o tipo de matriz ENUM_ORDER_TYPE para int, tendo-o ao mesmo tempo em conta no código (pelo menos os tipos de ordem podem ser facilmente representados como int);
2. Implementar de forma independente a "inicialização" da matriz.