간단한 산술로 계산하면 10~17개의 창 영역의 합이 전체 화면보다 훨씬 큽니다. 동의합니다. 그림자, 아이콘, 프레임을 만드는 데 필요한 보조 추가 도면....
그리고 TextOut에 대해 확인하고 작성하겠습니다. 흥미로운 아이디어입니다.
나는 당신의 간단한 산술을 이해하지 못합니다 :). 내 산술에서는 사용자에게 보이지 않는 픽셀을 그릴 필요가 없으며 그리기위한 캔버스의 최대 크기는 픽셀 단위의 디스플레이 크기에 의해 제한됩니다.
저는 하나의 비트맵에 창 수에 상관없이 레이어로 그립니다. 창이 100개까지 있을 수 있습니다. 간단한 기본 요소는 아주 짧은 시간 안에 그려집니다. 위에서 쓴 것처럼 가장 긴 것은 텍스트입니다. 그러나 처음 사용할 때 TextOut의 도움으로, 그리고 이미 준비된 배열에서 더 많이 사용합니다.
나는 당신의 간단한 산술을 이해하지 못합니다 :). 내 산술에서는 사용자에게 보이지 않는 픽셀을 렌더링 할 필요가 없으며 렌더링을위한 캔버스의 최대 크기는 픽셀 단위의 디스플레이 크기에 의해 제한됩니다.
저는 창 수에 상관없이 하나의 비트맵에 레이어로 그립니다. 창이 100개까지 있을 수 있습니다. 간단한 기본 요소는 아주 짧은 시간 안에 그려집니다. 위에서 쓴 것처럼 가장 긴 것은 텍스트입니다. 그러나 처음 사용할 때 TextOut의 도움으로, 그리고 이미 준비된 배열에서 더 많이 사용할 수 있습니다.
하나의 큰 캔버스로 작업하는 데는 많은 한계가 있습니다. 나는 이미이 옵션에 대해 생각했고 심지어 Nikolay와 논의했습니다.
설명해 드리겠습니다. 표준 C캔버스 클래스를 사용하기 때문에 그렇게합니다. 작업하는 프레임 워크 내에 기성품 솔루션이 있습니다. 하지만 저는 C캔버스 클래스를 사용하지 않습니다. 모든 렌더링 코드는 개인적으로 개발합니다. 그렇기 때문에 모든 것을 위한 하나의 캔버스라는 개념을 고수하지 않습니다. 제 생각에는 그래픽 환경에서는 기술적으로 불편하고 비효율적인 솔루션이라고 생각합니다. 하나의 비트맵을 가지고 그 위에 이미지의 상호 작용을 프로그래밍 방식으로 구축하는 것보다 비트맵 개체 세트를 사용하고 기성 리소스를 첨부하는 것이 더 쉽습니다. 상상하기조차 어렵습니다. 그러나 이것이 중요한 것은 아닙니다.
캔버스가 하나만 있다면 다중 창 GUI의 개념을 실현하는 것이 얼마나 더 어려운지 상상해 보세요. 나는 그런 작업을 수행하지 않을 것입니다.
그러나 이것조차도 결정적인 것은 아닙니다. 모든 이미지에 대해 하나의 캔버스라는 아이디어를 거부하는 주된 이유 : 캔버스가 하나만있을 때 인터페이스 창을 이동하려면 MQL 환경 내에서 다시 그려야합니다. 반대로 각 창이 자체 비트 맵 개체를 차지하고 ObjectSetInteger () 함수에 의해 이동되는 경우 - 이동 된 개체의 다시 그리기는 MQL 환경 외부에서 작동하는 표준 함수에 해당합니다. 따라서 훨씬 빠릅니다.
하나의 큰 캔버스로 작업하는 데는 많은 한계가 있습니다. 저는 이미 그러한 옵션에 대해 생각해 보았고 Nikolay와도 논의했습니다.
설명해 드리겠습니다. 표준 C캔버스 클래스를 사용하기 때문에 그렇게합니다. 작업하는 프레임 워크 내에 기성품 솔루션이 있습니다. 하지만 저는 C캔버스 클래스를 사용하지 않습니다. 모든 렌더링 코드는 개인 개발로 작성합니다. 그래서 저는 모든 것을 위한 하나의 캔버스라는 개념을 고수하지 않습니다. 제 생각에는 그래픽 환경에서는 기술적으로 불편하고 비효율적인 솔루션입니다. 하나의 비트맵을 가지고 그 위에 이미지의 상호 작용을 프로그래밍 방식으로 구축하는 것보다 비트맵 개체 세트를 사용하고 기성 리소스를 첨부하는 것이 더 쉽습니다. 상상하기조차 어렵습니다. 그러나 이것이 중요한 것은 아닙니다.
캔버스가 하나만 있다면 다중 창 GUI의 개념을 실현하는 것이 얼마나 더 어려운지 상상해보십시오. 나는 그런 일을하지 않을 것입니다.
그러나 이것조차도 결정적인 것은 아닙니다. 모든 이미지에 대해 하나의 캔버스라는 아이디어를 거부하는 주된 이유는 캔버스가 하나만있을 때 인터페이스 창을 이동하려면 MQL 환경 내에서 다시 그려야합니다. 반대로 각 창이 자체 비트 맵 개체를 차지하고 ObjectSetInteger ()로 이동하는 경우 - 이동할 때 다시 그리는 것은 MQL 환경 외부에서 작동하는 표준 함수에 해당합니다. 따라서 훨씬 빠릅니다.
다른 솔루션이 더 효율적으로 작동하는 개발 방향이 약간 다를 뿐입니다.
TextOut에 대한 팁을 주셔서 대단히 감사합니다. 이 점을 조사해 보겠습니다.
저는 표준 캔버스를 사용하고 있지 않습니다 :).
그리고 하나의 비트맵에 다중 창 인터페이스를 구현하는 것이 더 쉽다는 것을 알았습니다. 그러나 각자에게!
그리고 실제로는 ObjectSetInteger 등을 사용하는 것보다 전체 캔버스를 다시 그리는 것이 더 빠른 것 같습니다....
또한 변경할 때마다 전체 화면 캔버스가 완전히 다시 그려지지만 50ms 이상 걸리지 않습니다...
가장 비싼 것은 텍스트를 그리는 것입니다. 따라서 매번 TextOut을 사용하지 않기 위해 배열에 저장합니다. 훨씬 더 빠릅니다.
예, TextOut이 사용됩니다. 나는 그것으로 무엇을 할 수 있는지 생각할 것입니다.
간단한 산술로 계산하면 10~17개의 창 영역의 합이 전체 화면보다 훨씬 큽니다. 동의합니다. 그림자, 아이콘, 프레임을 만드는 데 필요한 보조 추가 도면....
그리고 TextOut에 대해 확인하고 작성하겠습니다. 흥미로운 아이디어입니다.
나는 당신의 간단한 산술을 이해하지 못합니다 :). 내 산술에서는 사용자에게 보이지 않는 픽셀을 그릴 필요가 없으며 그리기위한 캔버스의 최대 크기는 픽셀 단위의 디스플레이 크기에 의해 제한됩니다.
저는 하나의 비트맵에 창 수에 상관없이 레이어로 그립니다. 창이 100개까지 있을 수 있습니다. 간단한 기본 요소는 아주 짧은 시간 안에 그려집니다. 위에서 쓴 것처럼 가장 긴 것은 텍스트입니다. 그러나 처음 사용할 때 TextOut의 도움으로, 그리고 이미 준비된 배열에서 더 많이 사용합니다.
향후 작업 계획에 대한 승인을 받아야 합니다.
매주 업데이트를 발행하겠습니다. 토요일 또는 일요일.
1. 다음 릴리스에서는 엔진의 정식 버전을 출시하겠습니다. 버그를 수정하고 렌더링 속도를 높이겠습니다.
2. 두 번째 릴리스는 테이블 전용입니다. 기본 기능을 복원하겠습니다.
3. 세 번째 릴리스 - 동적 테이블을 만들겠습니다. 일주일 안에 구현하고 싶습니다. 노력하겠습니다.
4. 네 번째 릴리스-동적 창. 완성 된 버전을 게시하려고 노력할 것입니다.
이 단계에서는 빌더, 엔진 및 마크 업 언어의 기본 버전이 완료된 것으로 간주 할 수 있습니다.
완성 된 창과 요소 그룹을 게시 할 KIB 코드로 작성된 템플릿 분기를 확실히 열 것입니다. 인터페이스를 구축하려는 사람들이 더 쉽게 만들 수 있도록 삽화와 함께.
그리고 사람들이 모든 가능성을 사용할 수 있도록 튜토리얼 기사를 작성하려고 노력할 것입니다.
이 스레드에서는 가능한 한 코드, 사진 및 설명 자료를 계속 게시할 것입니다. 위에서 언급한 작업을 하느라 매우 바쁠 것 같습니다.
나는 당신의 간단한 산술을 이해하지 못합니다 :). 내 산술에서는 사용자에게 보이지 않는 픽셀을 렌더링 할 필요가 없으며 렌더링을위한 캔버스의 최대 크기는 픽셀 단위의 디스플레이 크기에 의해 제한됩니다.
저는 창 수에 상관없이 하나의 비트맵에 레이어로 그립니다. 창이 100개까지 있을 수 있습니다. 간단한 기본 요소는 아주 짧은 시간 안에 그려집니다. 위에서 쓴 것처럼 가장 긴 것은 텍스트입니다. 그러나 처음 사용할 때 TextOut의 도움으로, 그리고 이미 준비된 배열에서 더 많이 사용할 수 있습니다.
하나의 큰 캔버스로 작업하는 데는 많은 한계가 있습니다. 나는 이미이 옵션에 대해 생각했고 심지어 Nikolay와 논의했습니다.
설명해 드리겠습니다. 표준 C캔버스 클래스를 사용하기 때문에 그렇게합니다. 작업하는 프레임 워크 내에 기성품 솔루션이 있습니다. 하지만 저는 C캔버스 클래스를 사용하지 않습니다. 모든 렌더링 코드는 개인적으로 개발합니다. 그렇기 때문에 모든 것을 위한 하나의 캔버스라는 개념을 고수하지 않습니다. 제 생각에는 그래픽 환경에서는 기술적으로 불편하고 비효율적인 솔루션이라고 생각합니다. 하나의 비트맵을 가지고 그 위에 이미지의 상호 작용을 프로그래밍 방식으로 구축하는 것보다 비트맵 개체 세트를 사용하고 기성 리소스를 첨부하는 것이 더 쉽습니다. 상상하기조차 어렵습니다. 그러나 이것이 중요한 것은 아닙니다.
캔버스가 하나만 있다면 다중 창 GUI의 개념을 실현하는 것이 얼마나 더 어려운지 상상해 보세요. 나는 그런 작업을 수행하지 않을 것입니다.
그러나 이것조차도 결정적인 것은 아닙니다. 모든 이미지에 대해 하나의 캔버스라는 아이디어를 거부하는 주된 이유 : 캔버스가 하나만있을 때 인터페이스 창을 이동하려면 MQL 환경 내에서 다시 그려야합니다. 반대로 각 창이 자체 비트 맵 개체를 차지하고 ObjectSetInteger () 함수에 의해 이동되는 경우 - 이동 된 개체의 다시 그리기는 MQL 환경 외부에서 작동하는 표준 함수에 해당합니다. 따라서 훨씬 빠릅니다.
다른 솔루션이 더 효과적으로 작동하는 개발 방향이 다를 뿐입니다.
TextOut에 대한 팁을 주셔서 대단히 감사합니다. 이 점을 조사해 보겠습니다.
템플릿 브랜치는 다음과 같은KIB 코드로 작성됩니다.
예, 디버깅을 위해 엔진에서 사용자 프로그램 연결을 끊는 것을 구현할 것입니다. 오해가 있었나 봅니다.
하나의 큰 캔버스로 작업하는 데는 많은 한계가 있습니다. 저는 이미 그러한 옵션에 대해 생각해 보았고 Nikolay와도 논의했습니다.
설명해 드리겠습니다. 표준 C캔버스 클래스를 사용하기 때문에 그렇게합니다. 작업하는 프레임 워크 내에 기성품 솔루션이 있습니다. 하지만 저는 C캔버스 클래스를 사용하지 않습니다. 모든 렌더링 코드는 개인 개발로 작성합니다. 그래서 저는 모든 것을 위한 하나의 캔버스라는 개념을 고수하지 않습니다. 제 생각에는 그래픽 환경에서는 기술적으로 불편하고 비효율적인 솔루션입니다. 하나의 비트맵을 가지고 그 위에 이미지의 상호 작용을 프로그래밍 방식으로 구축하는 것보다 비트맵 개체 세트를 사용하고 기성 리소스를 첨부하는 것이 더 쉽습니다. 상상하기조차 어렵습니다. 그러나 이것이 중요한 것은 아닙니다.
캔버스가 하나만 있다면 다중 창 GUI의 개념을 실현하는 것이 얼마나 더 어려운지 상상해보십시오. 나는 그런 일을하지 않을 것입니다.
그러나 이것조차도 결정적인 것은 아닙니다. 모든 이미지에 대해 하나의 캔버스라는 아이디어를 거부하는 주된 이유는 캔버스가 하나만있을 때 인터페이스 창을 이동하려면 MQL 환경 내에서 다시 그려야합니다. 반대로 각 창이 자체 비트 맵 개체를 차지하고 ObjectSetInteger ()로 이동하는 경우 - 이동할 때 다시 그리는 것은 MQL 환경 외부에서 작동하는 표준 함수에 해당합니다. 따라서 훨씬 빠릅니다.
다른 솔루션이 더 효율적으로 작동하는 개발 방향이 약간 다를 뿐입니다.
TextOut에 대한 팁을 주셔서 대단히 감사합니다. 이 점을 조사해 보겠습니다.
저는 표준 캔버스를 사용하고 있지 않습니다 :).
그리고 하나의 비트맵에 다중 창 인터페이스를 구현하는 것이 더 쉽다는 것을 알았습니다. 그러나 각자에게!
그리고 실제로는 ObjectSetInteger 등을 사용하는 것보다 전체 캔버스를 다시 그리는 것이 더 빠른 것 같습니다....