여기에서 인쇄가 표시되지 않는다는 것을 직접 읽었습니다 .. 이것은 매우 나쁩니다 .. 일반적으로 회색 선에서 충분히 오랜 시간 동안 최적화 진행에 녹색 점이 없으면 이것이 의미하는 바는 무엇입니까? 단순히 긍정적 인 결과가 없다는 것입니까? 그렇다면 Tim은 더 많은 인쇄물과 시각화가 필요합니다! 근데 왜 안 가? 탱크는 움직이고 함선은 전쟁 중이며 4GB의 작동 메모리가 있고 비디오 카드는 최고입니다. 1375MHz가 뭔가 있지만 완전히 테스트할 수는 없습니다!! 최소한 천천히... 컴퓨터는 즉시 넉다운에 들어가 빈 화면을 켭니다.
글꼴을 정확히 포함하지는 않지만 캔버스에 그리기 위해 표준 Windows 글꼴을 사용할 수 있는 기회를 제공할 수 있습니다.
캔버스에 대한 현재 아이디어는 좋습니다. 나는 당신이 그것을 위해 약간의 GDI를 열 것이라는 것을 이해합니다. 그것은 경이 롭다.
그런데 여기에 문제가 있는데, 차트를 그리는 원리에 이념적 차원에서 내재되어 있는 것 같다.
두 가지 예를 들어 설명하겠습니다.
캔버스를 보다 적극적으로 사용하기 위해서는 인원 변경이 필요합니다. 그리고 우리 터미널에서는 모든 시간 프레임( OBJ_NO_PERIODS )에서 숨겨질 때까지 어떤 개체도 그려지지 않습니다. 이것은 객체의 위치 를 준비할 수 없으며 아직 그려지지 않은 경우 치수 를 찾을 수 없다는 사실로 이어집니다.
출력 정적 텍스트 의 크기 와 출력 bmp 크기 모두에 대해 이 주제를 제기했습니다. 답은 다음과 같습니다. 너비 값 = -1로 그린 다음 개체 자체의 크기를 물어보면 확실히 알고 있습니다. 그리고 여기에 최소한의 일시 중지 와 ChartRedraw 를 호출해야 할 필요성을 추가합니다. 이것이 해킹이라는 데 동의합니다.
그러나 우리는 그러한 정적 또는 bmp가 아니라 수십 개를 차트에 두드려야 합니다. 그리고 많은 활동이 있는 경우 렌더링에서 일시 중지를 관찰해야 합니다.
그런데 여기에 문제가 있는데, 차트를 그리는 원리에 이념적 차원에서 내재되어 있는 것 같다.
캔버스를 보다 적극적으로 사용하기 위해서는 인원 변경이 필요합니다. 그리고 우리 터미널에서는 모든 시간 프레임( OBJ_NO_PERIODS )에서 숨겨질 때까지 어떤 개체도 그려지지 않습니다. 이것은 객체의 위치 를 준비할 수 없으며 아직 그려지지 않은 경우 치수 를 찾을 수 없다는 사실로 이어집니다.
캔버스의 완벽한 백버퍼링 힌트와 화면의 개체에 대한 스냅에 대해 알고 있습니까?
우리는 아티팩트 없이 완벽하고 신속하게 프레임을 그릴 수 있습니다. OpenCL 테스트 에서 프레임 시퀀스 생성을 기반으로 한 비디오 예제를 보십시오.
마법이 일어나는 곳입니다. 그래픽 개체는 그래픽 리소스에 대한 직접 바인딩을 가져옵니다. 또한 이 바인딩은 빠른 페이징 및 백 버퍼 작업을 위해 특별히 만들어졌기 때문에 캐싱과 관련하여 지능적입니다.
이제 화면의 개체와 관련이 있는지 걱정할 필요 없이 버퍼에 쉽게 그릴 수 있습니다.
//--- рисуем что хотим в buf
....
이제 이 업데이트된 비트맵을 화면에 표시할 시간입니다.
//--- saving the frame in memory and drawing it
ResourceCreate(resname,buf,SIZE_X,SIZE_Y, 0 , 0 ,SIZE_X,COLOR_FORMAT_XRGB_NOALPHA);
ChartRedraw ();
이를 위해 리소스를 다시 "다시 빌드"하고(사실 모든 크기가 동일하기 때문에 다시 빌드가 발생하지 않음) 새 비트맵을 여기에 복사하고 이 리소스의 변경 카운터가 증가합니다.
여기에서 objname 그래픽 개체 자체는 이미 리소스와 연결되어 있기 때문에 어떤 식으로든 건드리지 않습니다.
다음으로 ChartRedraw를 통해 화면 다시 그리기를 호출하므로 그래픽 개체를 그려야 합니다. 그리고 그 하나는 비트맵 변경 카운터로 제어하는 리소스에 대한 바인딩이 있습니다. 그래픽 개체에 대해 저장된 변경 카운터가 리소스 카운터와 일치하지 않으면 비트맵이 그래픽 개체에 자동으로 안전하게 복사되어 렌더링됩니다. 카운터가 일치하면 그림이 변경되지 않고 표시됩니다.
다음은 안전한(MQL5 및 터미널 렌더링 시스템 자체의 동시 액세스로부터) 프레임 표시와 함께 빠른 작업의 간단한 방법입니다.
원격 에이전트에 대한 시각화는 절대적으로 불가능합니까? 아니면 가능합니까?
nafik이 필요하지 않고 원격 에이전트가 프로세스 모드로 작동하고 창이 없기 때문에 불가능합니다(설정 창 제외).
작업 관리자를 통해서만 볼 수 있습니다(하지만 프로세스만 볼 수 있고 수행하는 작업은 아님).
nafik이 필요없어서 불가능하고 원격에이전트가 프로세스모드로 작동하고 창이 없습니다(설정창 제외) 감사합니다! 이해했다! 정말로!
시계의 경우 예를 들어 리소스에 직접 저장할 수 있다면 비표준 글꼴을 사용하고 싶습니다.
텍스트는 별도의 ttf 파일을 가지고 다니지 않고 리소스로 ex5에 즉시 포함한다는 의미입니다.
즉, 그래픽 비트맵/캔버스에서 그리기 전용입니까?
글꼴을 정확히 포함하지는 않지만 캔버스에 그리기 위해 표준 Windows 글꼴을 사용할 수 있는 기회를 제공할 수 있습니다.
즉, 그래픽 비트맵/캔버스에서 그리기 전용입니까?
아니요, 효율적인 레이블 그리기를 위해. 문제는 터미널이 리소스에서 글꼴을 가져와서 자체적으로 설치할 수 있다는 것입니다.
즉, 그래픽 비트맵/캔버스에서 그리기 전용입니까?
글꼴을 정확히 포함하지는 않지만 캔버스에 그리기 위해 표준 Windows 글꼴을 사용할 수 있는 기회를 제공할 수 있습니다.
캔버스에 대한 현재 아이디어는 좋습니다. 나는 당신이 그것을 위해 약간의 GDI를 열 것이라는 것을 이해합니다. 그것은 경이 롭다.
그런데 여기에 문제가 있는데, 차트를 그리는 원리에 이념적 차원에서 내재되어 있는 것 같다.
두 가지 예를 들어 설명하겠습니다.
캔버스를 보다 적극적으로 사용하기 위해서는 인원 변경이 필요합니다. 그리고 우리 터미널에서는 모든 시간 프레임( OBJ_NO_PERIODS )에서 숨겨질 때까지 어떤 개체도 그려지지 않습니다. 이것은 객체의 위치 를 준비할 수 없으며 아직 그려지지 않은 경우 치수 를 찾을 수 없다는 사실로 이어집니다.
출력 정적 텍스트 의 크기 와 출력 bmp 크기 모두에 대해 이 주제를 제기했습니다. 답은 다음과 같습니다. 너비 값 = -1로 그린 다음 개체 자체의 크기를 물어보면 확실히 알고 있습니다. 그리고 여기에 최소한의 일시 중지 와 ChartRedraw 를 호출해야 할 필요성을 추가합니다. 이것이 해킹이라는 데 동의합니다.
그러나 우리는 그러한 정적 또는 bmp가 아니라 수십 개를 차트에 두드려야 합니다. 그리고 많은 활동이 있는 경우 렌더링에서 일시 중지를 관찰해야 합니다.
--------------------
기존 오브제에 대한 대안으로 유비쿼터스 캔버스는 유토피아 // 이상적으로는 유쾌하지만
정상적인 접근 방식을 사용하는 사람은 전체 차트 2096 x 1080 픽셀을 가로지르는 대각선을 위해 10MB 비트맵을 그리고 브레이크를 사용하여 차트에 넣지 않을 것입니다.
나는 캔버스의 개발을 전적으로 지원합니다 // 그리고 일반적으로 모든 개발을 지원합니다
그러나 사용 가능한 개체는 인터페이스의 모든 비즈니스 요구 사항의 95%를 커버합니다. 캔버스는 복잡한 비즈니스 구조에 대한 첨부 파일입니다 // Kart Kohonen의 예에서 매우 잘 입증되었습니다. 그러나 그들은 물건을 완전히 대체하고 싶어하지 않습니다.
(-5%는 좌표선 도입을 막기 위한 개발자들의 노력입니다. :) // 하지만 이미 대화는 시작되었으니 합의가 이루어지길 바랍니다)
2012.10.20 14:21:46 테스터 전문가 파일 C:\Users\Micah\AppData\Roaming\MetaQuotes\Terminal\FF783873B20D7FA177754FFAFFD85AFB6\MQL5\Experts\final.ex5 할당 오류
2012.10.20 14:21:31 Core 2 인증(에이전트 빌드 695)
2012.10.20 14:21:16 127.0.0.1:3001에 연결하는 코어 2
2012.10.20 14:11:10 Core 1 OpenCL 장치: GPU NVIDIA Corporation GeForce 9600 GSO 1GB(OpenCL 1.0 포함)(12개 장치, 1375MHz, 2048MB, 버전 301.42)
죄송합니다 여기 뭐라고 써져있나요??? 나는 그 오류가 실수라는 것을 이해합니다. 그에게 부족한 것은 무엇입니까? ??
일반적으로 테스트하는 동안 거의 완전히 멈춥니다!! 그것은 종종 스스로를 잘라냅니다 .. 그러나 같은 저녁에 결국 게임은 매우 활기차고 아름답습니다 - 월드 탱크, 스토커 등. !
그런데 여기에 문제가 있는데, 차트를 그리는 원리에 이념적 차원에서 내재되어 있는 것 같다.
캔버스를 보다 적극적으로 사용하기 위해서는 인원 변경이 필요합니다. 그리고 우리 터미널에서는 모든 시간 프레임( OBJ_NO_PERIODS )에서 숨겨질 때까지 어떤 개체도 그려지지 않습니다. 이것은 객체의 위치 를 준비할 수 없으며 아직 그려지지 않은 경우 치수 를 찾을 수 없다는 사실로 이어집니다.
캔버스의 완벽한 백버퍼링 힌트와 화면의 개체에 대한 스냅에 대해 알고 있습니까?
우리는 아티팩트 없이 완벽하고 신속하게 프레임을 그릴 수 있습니다. OpenCL 테스트 에서 프레임 시퀀스 생성을 기반으로 한 비디오 예제를 보십시오.
아름다운 전술 사용:
마법이 일어나는 곳입니다. 그래픽 개체는 그래픽 리소스에 대한 직접 바인딩을 가져옵니다. 또한 이 바인딩은 빠른 페이징 및 백 버퍼 작업을 위해 특별히 만들어졌기 때문에 캐싱과 관련하여 지능적입니다.
//--- рисуем что хотим в buf ....이를 위해 리소스를 다시 "다시 빌드"하고(사실 모든 크기가 동일하기 때문에 다시 빌드가 발생하지 않음) 새 비트맵을 여기에 복사하고 이 리소스의 변경 카운터가 증가합니다.
여기에서 objname 그래픽 개체 자체는 이미 리소스와 연결되어 있기 때문에 어떤 식으로든 건드리지 않습니다.
다음으로 ChartRedraw를 통해 화면 다시 그리기를 호출하므로 그래픽 개체를 그려야 합니다. 그리고 그 하나는 비트맵 변경 카운터로 제어하는 리소스에 대한 바인딩이 있습니다. 그래픽 개체에 대해 저장된 변경 카운터가 리소스 카운터와 일치하지 않으면 비트맵이 그래픽 개체에 자동으로 안전하게 복사되어 렌더링됩니다. 카운터가 일치하면 그림이 변경되지 않고 표시됩니다.
다음은 안전한(MQL5 및 터미널 렌더링 시스템 자체의 동시 액세스로부터) 프레임 표시와 함께 빠른 작업의 간단한 방법입니다.