FórumSeções

É possível implementar um padrão de um único botão na MQL4. - página 2

Novo comentário
Mas, por alguma razão, há muitos erros no momento da compilação. O que está errado?

De que paternas podemos falar se você não conhece o básico, você não poderia nem mesmo criar um campo de classe estático corretamente.

(há muitos artigos sobre singleton em hobber, para que serve, como fazer e o que está errado com ele).

Singleton ou uma classe estática?
Usando o padrão singleton
ALXIMIKS:

(há muitos artigos sobre o singleton no hubrabs e para que serve, e como, e o que há de errado com ele)

Classe monotonelada ou estática?
Usando o padrão Singleton.

Você acha que eu ainda não encontrei isto? Eu ainda não descobri como funciona. A questão é esta. Mas, ao que parece, não preciso de um único botão. Portanto, vou me contentar com os membros estáticos.

ALXIMIKS:

Como podemos falar de paternalidades se você não conhece o básico, você não poderia nem mesmo criar um campo de classe estático corretamente.

Se você souber como, poderá corrigi-lo. Ontem eu escrevi de acordo com a documentação. Mas também há muitos erros. Assim:

struct Symbol_Properties
{
   static datetime    gdt_Quote;           // Время поступления последней котировки
   static double      gda_Price [2];       // Текущие рыночные цены (0 - Bid, 1- Ask)
   static double      gd_Spread;           // Размер спреда в пунктах
   static double      gd_Swap;             // Своп
   static double      gd_Comission;        // Комиссия
   static double      gd_Pt;               // Величина одного пункта
   static int         gi_Digits;           // Количество знаков в цене после запятой
   static int         gi_StopLevel;        // Минимально-допустимый уровень стоп-лосса/тейк-профита в пунктах
   static int         gi_FreezLevel;       // Уровень заморозки ордеров в пунктах
};
int Symbol_Properties::gdt_Quote = 0;
int Symbol_Properties::gda_Price = 0;
int Symbol_Properties::gd_Spread = 0;
int Symbol_Properties::gd_Swap = 0;
int Symbol_Properties::gd_Comission = 0;
int Symbol_Properties::gd_Pt = 0;
int Symbol_Properties::gi_Digits = 0;
int Symbol_Properties::gi_StopLevel = 0;
int Symbol_Properties::gi_FreezLevel = 0;

O que vem a seguir?

static double       gd_Spread; 
int  Symbol_Properties::gd_Spread = 0;
não está triste com nada?
Естественно, создавать несколько объектов в разных классах данных структур крайне не рекомендуется.
Diga-me do que se trata. E traduza a citação acima mais claramente, infelizmente não entendo nada, obrigado.

Eu joguei o errado fora. De qualquer forma, a versão atual está correta aqui:

struct Symbol_Properties
{
   static datetime    gdt_Quote;           // Время поступления последней котировки
   static double      gda_Price [2];       // Текущие рыночные цены (0 - Bid, 1- Ask)
   static double      gd_Spread;           // Размер спреда в пунктах
   static double      gd_Swap;             // Своп
   static double      gd_Comission;        // Комиссия
   static double      gd_Pt;               // Величина одного пункта
   static int         gi_Digits;           // Количество знаков в цене после запятой
   static int         gi_StopLevel;        // Минимально-допустимый уровень стоп-лосса/тейк-профита в пунктах
   static int         gi_FreezLevel;       // Уровень заморозки ордеров в пунктах
};

datetime   Symbol_Properties::gdt_Quote = 0;
double     Symbol_Properties::gda_Price [2] = {0.0, 0.0};
double     Symbol_Properties::gd_Spread = 0;
double     Symbol_Properties::gd_Swap = 0;
double     Symbol_Properties::gd_Comission = 0;
double     Symbol_Properties::gd_Pt = 0;
int        Symbol_Properties::gi_Digits = 0;
int        Symbol_Properties::gi_StopLevel = 0;
int        Symbol_Properties::gi_FreezLevel = 0;

Entendo, agora eu me refiro a cada variável estática por um nome tão longo?

Symbol_Properties::gd_Spread = 0;

Ou é mais fácil implementá-la para que, após a descrição da estrutura de inicialização da variável, quando ela for inicializada, o membro estático correspondente seja atribuído a alguma variável do tipo:

double Spread = Symbol_Properties::gd_Spread = 0;

E depois, no código, referir-se às variáveis estáticas correspondentes por esta variável, certo?

hoz:

Certo, bem... O principal é queVadim sabe :)))))

Sim, esse é o tipo normal de diálogo:

P: Meus amigos me recomendaram alguns doces. Isto é exatamente o que eu preciso!

Eu: (Puzzled... O que isso tem a ver com os doces? Talvez B esteja indo à festa de aniversário de um amigo ou queira tratar as crianças, talvez a dele ou de outra pessoa? Talvez ele tenha entrado no negócio e agora esteja vendendo doces. Talvez tenha sido o último doce em Belarus e B é agora um monopolista. E se B falhou os doces? Muitos outros pensamentos passaram pela minha cabeça sobre o tema "por que rebuçados e o que fazer com eles". Mais uma vez, como antes com o B, minhas habilidades telepáticas me falharam. Nada me veio à mente).

Nem uma pista.

Só por precaução. É grosseiro postar diálogos sem o consentimento de todos os envolvidos na conversa. É de mau feitio.

1. Para que serve tudo isso?

2. Há duas maneiras de acessar os campos estáticos de uma classe (a estrutura é uma classe de acesso público por padrão e herança):

(a) Através do namespace da classe - por exemploSymbol_Properties::gd_Spread

(Spreadduplo= Symbol_Properties::gd_Spread) - o valorSpread torna-se igual agd_Spread da classeSymbol_Properties

(spread duplo= Symbol_Properties::gd_Spread =0) valor degd_Spread daclasse Symbol_Properties e o valor deSpread torna-se igual a 0

b) criar um objeto de classe (por exemplo,Symbol_Properties obj; ) e referir-se a ele como um campo usual da classe através deste objeto

(Duplo Spread = obj.gd_Spread)

( propagaçãodupla= obj.gd_Spread =0)

ALXIMIKS:

1. Para que serve tudo isso?

Conveniência... Afinal, se essas variáveis são utilizadas em uma única instância, por que eu deveria criar um objeto? Além disso, é muito mais conveniente ler o código ao se referir a uma variável, se NOME VARIÁVEL.VARIABIL.

ALXIMIKS:

2. Há duas maneiras de acessar campos estáticos de classe (estrutura é uma classe com acesso público por padrão e herança)

(a) através do espaço de nomes de classe - por exemploSymbol_Properties::gd_Spread

(Spreadduplo= Symbol_Properties::gd_Spread) - o valorSpread torna-se igual agd_Spread da classeSymbol_Properties

(spread duplo= Symbol_Properties::gd_Spread =0)- o valor despread degd_Spread da classeSymbol_Properties e o valor deSpread torna-se igual a 0

Exatamente! Foi por isso que o fiz dessa maneira. Inicializo imediatamente a variável que se refere à variável desta estrutura por zero e então ela é armazenada na memória permanentemente. O que é lógico, pois estas variáveis são necessárias em uma única instância. É por isso que não há motivo para criar objetos diferentes neste caso. Afinal de contas, é lógico... Você não concorda comigo?

ALXIMIKS:

b) Criar um objeto de classe (por exemploSymbol_Properties obj; ) e referir-se a ele como um campo de classe normal através deste objeto

Então as variáveis não serão estáticas, e não há garantia de que não manterão seus valores enquanto o programa for executado.
O que há de errado com STATIC VARIABLE, ou constantes, por exemplo?

O ESTADO VARIÁVEL não me agradou, porque eles são utilizados em classes diferentes. Por isso, eu os agrupei.

Constantes não são apreciadas porque as constantes não mudam seus valores, enquanto que estas variáveis devem ser capazes de mudar seus valores.

12345678910
Novo comentário