마지막으로! 이것은 잘못된 진술입니다. 레이블은 캔버스보다 빠를 수 없습니다. 레이블이 거의 없는 경우 기껏해야 실행 속도 측면에서 캔버스의 속도와 같을 수 있습니다. 더 많이 - 더 많이 캔버스를 잃습니다.
차트 자체는 프로그래머가 액세스할 수 없는 내부 캔버스이기도 합니다. 그리고 특성을 가진 개체를 만들 때 다음 ChartRedraw()가 발생할 때 이 개체를 그리도록 차트를 설정하기만 하면 됩니다(캔버스에 그리는 것처럼). 원본 소스 읽기
문제의 사실은 여러 줄을 업데이트해야 하는 경우 문자 그대로 여러 레이블의 텍스트를 변경하는 것을 의미합니다. 그리고 캔버스( OBJ_BITMAP_LABEL )가 속도면에서 이길 것이라고 말할 필요가 없습니다. 결국, 화면의 많은 픽셀에 텍스트를 표시하는 경우 변경 후 ResourceCreate를 사용 하여 차트 내부의 적은 수의 픽셀을 변경하지 않고 모두 전송해야 합니다( OBJ_LABEL 은 차트 개체 이기 때문에). 그리고 그와 마찬가지로 OBJ_BITMAP_LABEL에 대해 말하는 ChartRedraw()를 호출해야 합니다. 그 후 OBJ_BITMAP_LABEL이 항상 속도면에서 이긴다고 할까요?... 사실, 어떤 경우에 누가 더 빠른지, 이것은 실험적으로 설정해야 합니다(일반적인 이해를 위해). 제가 뭔가를 섞은 건지, 아니면 제가 직접 쓴 건지.. 글쎄요, 왜 화를 내시는 건가요?!...
문제의 사실은 여러 줄을 업데이트해야 하는 경우 문자 그대로 여러 레이블의 텍스트를 변경하는 것을 의미합니다. 그리고 캔버스( OBJ_BITMAP_LABEL )가 속도면에서 이길 것이라고 말할 필요가 없습니다. 결국 화면의 많은 픽셀에 텍스트를 표시하는 경우 차트 내부의 적은 수의 픽셀을 변경하지 않고 ResourceCreate를 사용하여 모두 전송해야 합니다( OBJ_LABEL 은 차트 개체 이기 때문에). 그 후 OBJ_BITMAP_LABEL이 항상 속도면에서 이긴다고 할까요?... 따라서 어떤 경우에 누가 더 빠른지 실험적으로 설정해야 합니다. 내 생각에 동의하는 것 같은데?... 글쎄, 왜 화를 냈어?!...
당신은 항상 추측하고 있습니다. 누군가의 불만 사항을 포함합니다. 아니요, 당신은 근본적으로 틀렸고 단순히 주제에 있지 않습니다. 당신은 스스로 우화를 생각해 내고 누구의 말을 듣지 않고 완고하게 믿으려고합니다.
2021.03.09 20:40:47.616 코어 1 사용 가능한 메모리가 충분하지 않음, 2211Mb 사용됨, 2416Mb 사용 가능, 사용 가능한 최대 블록은 60Mb
내가 이해하는 한 64MB로는 충분하지 않습니다.
이것은 디스크 공간 부족이 아니라 메모리 문제입니다. 하지만 11Gb를 가지고 있기 때문에 RAM이 부족한 것 같지는 않습니다...
에이전트 탭에서 하나를 제외한 모든 코어를 비활성화하십시오. 그리고 점차적으로 켜십시오.
하지만 캔버스보다 더 빠른 방법을 찾고 있었습니다. 라벨 외에는 다른 것을 찾지 못한 것으로 나타났습니다.
마지막으로!
이것은 잘못된 진술입니다. 레이블은 캔버스보다 빠를 수 없습니다. 레이블이 거의 없는 경우 기껏해야 실행 속도 측면에서 캔버스의 속도와 같을 수 있습니다. 더 많이 - 더 많이 캔버스를 잃습니다.
차트 자체는 프로그래머가 액세스할 수 없는 내부 캔버스이기도 합니다. 그리고 특성을 가진 개체를 만들 때 다음 ChartRedraw()가 발생할 때 이 개체를 그리도록 차트를 설정하기만 하면 됩니다(캔버스에 그리는 것처럼).
원본 소스 읽기
이것은 디스크 공간 부족이 아니라 메모리 문제입니다. 하지만 11Gb를 가지고 있기 때문에 RAM이 부족한 것 같지는 않습니다...
에이전트 탭에서 하나를 제외한 모든 코어를 비활성화하십시오. 그리고 점차적으로 켜십시오.
장애인, 도움이 되지 않음
2021.03.10 10:32:48.769 코어 1 64MB를 사용할 수 없음
마지막으로!
이것은 잘못된 진술입니다. 레이블은 캔버스보다 빠를 수 없습니다. 레이블이 거의 없는 경우 기껏해야 실행 속도 측면에서 캔버스의 속도와 같을 수 있습니다. 더 많이 - 더 많이 캔버스를 잃습니다.
차트 자체는 프로그래머가 액세스할 수 없는 내부 캔버스이기도 합니다. 그리고 특성을 가진 개체를 만들 때 다음 ChartRedraw()가 발생할 때 이 개체를 그리도록 차트를 설정하기만 하면 됩니다(캔버스에 그리는 것처럼).
원본 소스 읽기
문제의 사실은 여러 줄을 업데이트해야 하는 경우 문자 그대로 여러 레이블의 텍스트를 변경하는 것을 의미합니다. 그리고 캔버스( OBJ_BITMAP_LABEL )가 속도면에서 이길 것이라고 말할 필요가 없습니다. 결국, 화면의 많은 픽셀에 텍스트를 표시하는 경우 변경 후 ResourceCreate를 사용 하여 차트 내부의 적은 수의 픽셀을 변경하지 않고 모두 전송해야 합니다( OBJ_LABEL 은 차트 개체 이기 때문에). 그리고 그와 마찬가지로 OBJ_BITMAP_LABEL 에 대해 말하는 ChartRedraw()를 호출해야 합니다. 그 후 OBJ_BITMAP_LABEL이 항상 속도면에서 이긴다고 할까요?... 사실, 어떤 경우에 누가 더 빠른지, 이것은 실험적으로 설정해야 합니다(일반적인 이해를 위해). 제가 뭔가를 섞은 건지, 아니면 제가 직접 쓴 건지.. 글쎄요, 왜 화를 내시는 건가요?!...
장애인, 도움이 되지 않음
2021.03.10 10:32:48.769 코어 1 64MB를 사용할 수 없음
테스트 중인 Expert Advisor에 문제가 있는 것일까요?... 테스터가 다른 Expert Advisor와 정상적으로 작동합니까?
문제의 사실은 여러 줄을 업데이트해야 하는 경우 문자 그대로 여러 레이블의 텍스트를 변경하는 것을 의미합니다. 그리고 캔버스( OBJ_BITMAP_LABEL )가 속도면에서 이길 것이라고 말할 필요가 없습니다. 결국 화면의 많은 픽셀에 텍스트를 표시하는 경우 차트 내부의 적은 수의 픽셀을 변경하지 않고 ResourceCreate를 사용하여 모두 전송해야 합니다( OBJ_LABEL 은 차트 개체 이기 때문에). 그 후 OBJ_BITMAP_LABEL이 항상 속도면에서 이긴다고 할까요?... 따라서 어떤 경우에 누가 더 빠른지 실험적으로 설정해야 합니다. 내 생각에 동의하는 것 같은데?... 글쎄, 왜 화를 냈어?!...
당신은 항상 추측하고 있습니다. 누군가의 불만 사항을 포함합니다. 아니요, 당신은 근본적으로 틀렸고 단순히 주제에 있지 않습니다. 당신은 스스로 우화를 생각해 내고 누구의 말을 듣지 않고 완고하게 믿으려고합니다.
게시물을 수정했습니다. 내가 생각한 것 또는 내가 이해하지 못한 것을 쓸 수 있습니다 ...
KB에서 흥미로운 것을 공유하세요.
하나의 흥미로운 소스가 곧 준비될 것입니다.