그것이 바로 내가 당신이 모든 것을 스스로 하기를 원하고 벽에 완두콩과 같은 기성품 솔루션을 제공하지 않기를 바랐던 이유입니다.
Peter, 함수 포인터와 같은 기능이 있다는 것을 상상할 수 있습니까? 덕분에 이러한 포인터 배열에서 이러한 포인터를 가져옴으로써 함수 호출 을 구성할 수 있습니다. 귀하의 작업에 매우 유용할 것이라고 생각합니다. 여기에서만 문제가 있습니다. 다시 클래스와 통신해야합니다.
당신은 흥미로운 이론을 가지고 있습니다. 비록 그것이 내 실험의 결과와 완전히 일치하지는 않지만, 이제 아래에서 설명할 것입니다.
테스트에서 알 수 있듯이 프로세서를 가장 많이 로드하는 것은 픽셀 배열의 초기화입니다.
아래에서 테스트 EA를 확인하세요.
문제 읽기:
바실리 소콜로프 :
Peter, 여기 과제가 있습니다. MT4에서 주문의 현재 시작을 표시하는 패널을 만듭니다. 시스템 패널의 전체 복사본을 만들 필요가 없습니다. 공개 주문의 기본 속성인 공개 가격 , 방향, 이익이 있는 가장 간단한 테이블을 표시합니다. 나머지는 당신에게 달려 있습니다. 중요한 것은 주문을 마감하면 테이블의 해당 표시도 사라진다는 것입니다. 그 반대의 경우도 마찬가지입니다. 새 주문을 열 때 이 테이블에 나타납니다.
여기에서 화면에서 테이블을 변경할 때 필요한 두 가지 다시 그리기 작업을 볼 수 있습니다. 1. 거래를 마감할 때와 2. 거래를 열 때. 나머지 시간에 픽셀을 다시 그리는 이유는 무엇입니까?
OrderOpenPrice 대신 OrderOpenTime()을 넣어야 하기 때문에
정확히. 혼란스러운. :)
나는 테스트 결과가 나를 조금 놀랐다는 것을 인정해야 한다.
그것이 바로 내가 당신이 모든 것을 스스로 하기를 원하고 벽에 완두콩과 같은 기성품 솔루션을 제공하지 않기를 바랐던 이유입니다.
함수 포인터에 대해 들었습니다. 그러나 나는 기능이 거의 없습니다. 이 때문에 공간이 없고 OOP를 사용할 필요가 없습니다.
나는 다른 개발 개념을 가지고 있습니다. 나는 전체적인 다기능 블록의 작업이 작은 기능의 큰 복합체보다 더 효과적이라고 믿습니다.
메커니즘 개발의 관점에서 더 유망합니다.
제 생각입니다...
나는 몇 개의 큰 블록을 가지고 있습니다. OOP를 적용하기 위해서는 그것들을 작은 함수로 나누고, 클래스로 조직화한 다음, 포인터와 다른 것들을 사용해야 합니다.
하지만 나는 그것을 할 수 없습니다. 생각이 다르기 때문입니다.
OOP의 개념은 내 생각의 특성과 일치하지 않으며 나는 그것에 대해 돌이킬 수 없습니다. 이게 이유야.
Nikolay, 소프트웨어 개발 문제에 대해서는 문제가 없습니다. 모든 것이 매우 빠르게 발전하고 있습니다.
동시에 메커니즘이 정상적으로 작동합니다.
이제 나는 공용체를 마스터했으며 자원에 문자열 쓰기라는 하나의 특정 작업에서 공용체를 사용하는 것을 보았습니다.
테스트 EA에서 프로세서의 속도와 부하를 확인하고 결과를 게시하려고 합니다.
좋다면 무브먼트와 어드바이저의 연결을 재구축하여 자원으로 만들겠습니다.
길이가 불확실한 문자열을 전송하는 데 리소스를 사용하려면 이러한 문자열을 char 배열에 작성해야 합니다.
하지만 그 크기는 공용체 내부에서만 선언되고 이후에는 변경되지 않는 것으로 보입니다.
ArrayResize를 통해 공용체에서 char 배열의 크기를 변경 하려고 시도했지만 효과가 없습니다.
char 배열의 크기를 미리 설정해야 할 것 같습니다. 그리고 최대이어야 합니다.
코드는 다음과 같습니다.
이제 공용체에 있는 char 배열의 크기를 미리 알고 있어야 한다는 것이 분명해졌습니다. ArrayResize (u.Char, StrSize )가 변경하지 않기 때문입니다.
따라서 배열의 크기를 최대 문자열의 길이와 동일하게 설정해야 합니다...
좋은 소식. 모든 것이 잘 작동합니다.
문자열은 리소스에 기록되고 다른 차트의 다른 EA에서 읽습니다.
프로세서에 부하가 없습니다. 로드는 라인을 인쇄하는 Alert 호출에 의해서만 주어집니다.
어드바이저 코드는 다음과 같습니다.
1. 문자열을 생성하고 리소스에 쓰는 Expert Advisor.
다른 차트의 리소스에서 한 줄을 읽는 Expert Advisor:
소통의 수단으로 활용하겠습니다. 유일한 단점은 유니온 에서 char 배열의 최대 크기 를 설정해야 한다는 것입니다. 반면에 문자열의 크기와 MT 개체의 수는 생각할 필요가 없습니다.
이 방법은 MT 개체를 통한 통신 방법보다 느리지만 매우 적합합니다.
당신은 흥미로운 이론을 가지고 있습니다. 비록 그것이 내 실험의 결과와 완전히 일치하지는 않지만, 이제 아래에서 설명할 것입니다.
테스트에서 알 수 있듯이 프로세서를 가장 많이 로드하는 것은 픽셀 배열의 초기화입니다.
아래에서 테스트 EA를 확인하세요.
문제 읽기:
바실리 소콜로프 :
Peter, 여기 과제가 있습니다. MT4에서 주문의 현재 시작을 표시하는 패널을 만듭니다. 시스템 패널의 전체 복사본을 만들 필요가 없습니다. 공개 주문의 기본 속성인 공개 가격 , 방향, 이익이 있는 가장 간단한 테이블을 표시합니다. 나머지는 당신에게 달려 있습니다. 중요한 것은 주문을 마감하면 테이블의 해당 표시도 사라진다는 것입니다. 그 반대의 경우도 마찬가지입니다. 새 주문을 열 때 이 테이블에 나타납니다.
여기에서 화면에서 테이블을 변경할 때 필요한 두 가지 다시 그리기 작업을 볼 수 있습니다. 1. 거래를 마감할 때와 2. 거래를 열 때. 나머지 시간에 픽셀을 다시 그리는 이유는 무엇입니까?
다른 문제를 해결하고 있습니까?
문제 읽기:
바실리 소콜로프 :
여기에서 화면에서 테이블을 변경할 때 필요한 두 가지 다시 그리기 작업을 볼 수 있습니다. 1. 거래를 마감할 때와 2. 거래를 열 때. 나머지 시간에 픽셀을 다시 그리는 이유는 무엇입니까?
다른 문제를 해결하고 있습니까?
그래서 그들은 당신이 말한대로 정확하게 다시 그려집니다.
그리고 프로세서의 로드는 애니메이션 중에 발생합니다.
여기에 픽셀 배열의 값이 지속적으로 재초기화됩니다. 16밀리초마다. 이것은 프로세서를 최대 40%까지 로드합니다.
나는 정확히 무엇이로드되는지 이해하려고 노력했습니다. 리소스를 저장하거나 읽을 생각입니다. 드로잉 루프에서 배열의 재초기화로 밝혀졌습니다.
또한 ObjectSetInteger(0,"MT object",OBJPROP_SELECTED,1); (16밀리초마다) 프로세서도 로드합니다. 약 10%.
이 호출을 사용하여 애니메이션 데이터가 있는 리소스를 읽어야 한다고 다른 EA에 알립니다.
전체적으로 애니메이션 중에 프로세서 부하의 + ~ 50%가 됩니다.