오류, 버그, 질문 - 페이지 300

 
Yedelkin :
따라서 표시기의 짧은 이름 으로 작업해 보십시오. 필요한 경우 초기화 중에 매개변수 이름 및/또는 매개변수 값을 표시기에 삽입하십시오.

1. 요점은 그게 아니었다.

여기에서 특정 지표 세트가 취해진 반면 일부는 차트에 있고 일부는 그렇지 않을 수 있다고 가정해 보겠습니다.

이 경우 사용자는 이러한 칠면조에 대한 매개변수에서 자신의 매개변수를 지정할 수 있습니다. 어떤 매개변수와 어떤 칠면조가 사용되는지 결정하는 것이 목표입니다.

2. 복잡한 목표(복잡한 거래 시스템 구현).

사용자가 템플릿을 사용하여 지표 및 관련 디자인을 설정하는 여러 차트를 가져옵니다.

우리는 EA의 특정 차트에서 지표를 얻고 핸들(최소한)과 매개변수를 찾습니다.

그 후 고문에서 침착하게 표시기 핸들을 알고 일반 칠면조와 같이 작업합니다 (즉, 각 표시기의 버퍼 등을 참조 할 수 있음).


이 접근 방식을 사용하면 EA와 거래자가 동일한 지표 세트를 제어할 수 있으며(여기서 시각화가 매우 유용하기 때문에 매우 편리함) EA에 약간의 유연성을 제공합니다.

덜 중요한 것은 고문이 지표에 대한 추가 매개변수를 지정할 필요가 없다는 것입니다(상인이 설정할 수 있도록). 이 경우 거래자는 템플릿/여러 템플릿만 설정하고 저장하면 됩니다.

추신

포럼에서 비슷한 아이디어를 만났고 GLOBAL VARIABLES(매우 편리하고 효율적이지 않음)를 통해 문제를 해결하는 것이 좋습니다.

최소한 ChartIndicatorID (ChartIndicatorName과 동일한 매개변수 사용)와 같이 차트에서 칠면조 핸들을 가져올 수 있는 기능이 부족합니다.

또한 ChartIndicatorSetXXX 및 ChartIndicatorGetXXX도 표시되면...

 
Interesting :

1. 요점은 그게 아니었다.

여기에서 특정 지표 세트가 취해진 반면 일부는 차트에 있고 일부는 그렇지 않을 수 있다고 가정해 보겠습니다.

이 경우 사용자는 이러한 칠면조에 대한 매개변수에서 자신의 매개변수를 지정할 수 있습니다. 어떤 매개변수와 어떤 칠면조가 사용되는지 결정하는 것이 목표입니다.

2. 복잡한 목표(복잡한 거래 시스템 구현).

사용자가 템플릿을 사용하여 지표 및 관련 디자인을 설정하는 여러 차트를 가져옵니다.

우리는 EA의 특정 차트에서 지표를 얻고 핸들(최소한)과 매개변수를 찾습니다.

그 후 고문에서 침착하게 표시기 핸들을 알고 일반 칠면조와 같이 작업합니다 (즉, 각 표시기의 버퍼 등을 참조 할 수 있음).


이 접근 방식을 사용하면 EA와 거래자가 동일한 지표 세트를 제어할 수 있으며(여기서 시각화가 매우 유용하기 때문에 매우 편리함) EA에 약간의 유연성을 제공합니다.

덜 중요한 것은 고문이 지표에 대한 추가 매개변수를 지정할 필요가 없다는 것입니다(상인이 설정할 수 있도록). 이 경우 거래자는 템플릿/여러 템플릿만 설정하고 저장하면 됩니다.

추신

포럼에서 비슷한 아이디어를 만났고 GLOBAL VARIABLES (매우 편리하고 효율적이지 않음)를 통해 문제를 해결하는 것이 좋습니다.

최소한 ChartIndicatorID (ChartIndicatorName과 동일한 매개변수 사용)와 같이 차트에서 칠면조 핸들을 가져올 수 있는 기능이 부족합니다.

또한 ChartIndicatorSetXXX 및 ChartIndicatorGetXXX도 표시되면...

이 제안을 지지합니다!
 
Interesting :

최소한 ChartIndicatorID (ChartIndicatorName과 동일한 매개변수 사용)와 같이 차트에서 칠면조 핸들을 가져올 수 있는 기능이 부족합니다.

또한 ChartIndicatorSetXXX 및 ChartIndicatorGetXXX도 표시되면...

저에게도 이것은 사실입니다. 나는 지원한다.
 
Lizar :
저에게도 이것은 사실입니다. 나는 지원한다.
모두가 찬성하면 개시자가 ServiceDesk에 쓰도록 합니다.
 
-Alexey- :
모두가 찬성하면 개시자가 ServiceDesk에 쓰도록 합니다.

예, 거기에 작성하는 데 문제가 없습니다. 다만 특정 함정이 있습니다(주로 표시기 초기화 및 사용자가 차트에 던진 표시기로 "핸들"/식별자를 얻는 메커니즘과 관련됨).

먼저 이 문제를 전담하는 별도의 분기를 만들 수 있다고 생각합니다. ServiceDesk에 대한 토론과 결정의 결과입니다.

그래서 나는 그것을 일반 토론에 넣었습니다.

 
Interesting :
제 생각에는 칠면조 두 개로 나누는 것이 더 쉽습니다. 비록 사람마다 다르긴 하지만요.
할 수 있다. 그러나 계산이 매우 무거울 경우 수행할 작업은 다음과 같습니다. 컴퓨터 연기. 계산을 위해 동일한 작업을 2번 실행합니다. ((좋지 않음. 버퍼에 표시할 창을 표시하기 위해) 그러한 제안은 5-ke 또는 이와 유사한 것에 대한 제안이었습니다. 개발자가 하지 않은 것이 유감입니다. 이 트릭은 가능합니다
 
Trolls :
할 수 있다. 그러나 계산이 매우 무거울 경우 수행할 작업은 다음과 같습니다. 컴퓨터 연기. 계산을 위해 동일한 작업을 2번 실행합니다. ((좋지 않음. 버퍼에 표시할 창을 표시하기 위해) 그러한 제안은 5-ke 또는 이와 유사한 것에 대한 제안이었습니다. 개발자가 하지 않은 것이 유감입니다. 이 트릭은 가능합니다
아마도 칠면조의 논리는 개선되거나 특정 한계로 제한될 수 있습니다. 적어도 70%는 가능합니다.
 

테스터의 각 거래에 대한 잔액/자금 표시를 반환할 수 있습니까?

현재 버전은 Expert Advisor를 디버깅하고 작성하는 데 매우 불편합니다.

 
Jager :

테스터의 각 거래에 대한 잔액/자금 표시를 반환할 수 있습니까?

현재 버전은 Expert Advisor를 디버깅하고 작성하는 데 매우 불편합니다.

+1
 
mql5 :
게시해 주셔서 감사합니다. 수정했습니다.

새 빌드를 출시하기로 한 결정은 무엇을 기준으로 합니까?

개발을 방해하는 버그를 발견하고 이해하기 쉬운 형식으로 보고했으며 새 빌드를 릴리스하는 데 있어 귀하의 효율성을 진심으로 바랐습니다. 그러나 며칠이 지났지만 여전히 새 빌드가 없습니다.

이 접근 방식을 사용하면 버그를 보고 하고 플랫폼을 개선하고 싶은 마음이 사라집니다. 새 빌드를 기다리는 것보다 해결 방법을 찾는 것이 훨씬 쉽고 플랫폼의 버그는 그대로 유지됩니다.

소프트웨어 회사에서 일할 때 규칙이 있었습니다. 외부 개발자나 사용자가 버그를 발견하면 즉시 새 빌드를 조립하여 후자가 제품 품질을 개선하려는 욕구를 잃지 않도록 했습니다.

이 부분에 대해서는 회사의 방침을 생각하셔야 할 것 같습니다.