예를 포함하여 모든 것이 오랜 시간 동안 수행되었고 MFC의 아날로그 형태로 표준 라이브러리 에 있는 경우 주제의 인터페이스에 대해 말하는 것은 무엇입니까?
깔끔하고 전문적인 패널을 만들기 위한 라이브러리가 있는지도 모르고 엉뚱한 토론을 하고 있습니다. 그것들은 살아 있고, 끌고, 최소화하고, 이벤트에 반응하는 등입니다.
깔때기가 첫 번째 단계에서 전환을 잃을 때 다른 그래픽 구조는 "아무도 솔루션의 존재를 의심하지 않습니다." 모든 솔루션. 그들은 읽지 않고, 알지도 못하고 알고 싶지도 않습니다. 그리고 표준 라이브러리에는 13MB의 MQL5 소스가 있습니다. 제정신이라면 누가 거기에 가겠는가?
토론하고 조언하고 문제를 이해했다고 생각하는 것이 더 즐겁습니다 ...
Renat, 저는 이 도서관에서 일한 지 2년이 되었습니다. 주요 단점은 컨트롤과 해당 구성 요소의 불연속성입니다. 트레일로 드래그할 때 양식 요소가 양식 뒤를 따라갈 때 효과를 보지 못했을 것입니다. 스펙타클은 다채롭지만 생산적이지는 않습니다. 이벤트 처리에서 MFC 접근 방식을 사용하는 것이 좋습니다. 이미 이전 포스트에서 라이브러리 자체의 골격이 좋다고 썼지만 결국에는 개별 프리미티브에서 벗어나 하나의 캔버스에 최종 결과(컨트롤이 있는 양식)를 그리고 그래프 위로 하나의 개체를 드래그해야 합니다(또는 다른 캔버스), 루프에서 위치를 변경하여 원시 객체의 무리가 아닙니다.
물론, 당신은 말할 수 있습니다 : 도서관이 있습니다. 도대체 왜 아직도 그것을 필요로합니까? 그리고 이것을 진정시키기 위해 원칙적으로 모든 것을 치료하십시오. 그것은 당신의 권리입니다.
그러나 여기에서 시각화와 GUI에 대해 이야기하는 것은 원칙적으로 아무도 당신에게 아무것도 요구하지 않으며 단지 이해 당사자 간의 토론일 뿐입니다.
나는 상인들 사이에서 그러한 필요성을 눈치 채지 못했습니다. 수익성에 대해 이야기하는 것이 아니라 고문의 모든 종류의 장신구에 대해 이야기합니다.
그리고 고문의 가장 중요한 장신구는 잠재적인 수익성입니다!
그리고 고문의 가장 중요한 장신구는 잠재적인 수익성입니다!
무슨 이야기를 하든 ... 그냥 이야기 하는 것이 분명 합니다.
무슨 이야기를 하든 ... 그냥 이야기 하는 것이 분명 합니다.
그리고 충분한 어둠이 있다면 말하고 행동하라
네, 그렇습니다. Classic Expert Advisor - 매수/매도 신호를 생성하기 위한 세 가지 지표와 정지에 대한 몇 가지 공식. 슬프다.
더 나은 - "일반적인" ZigZag 및 일부 기능을 기반으로 하는 자체 Expert Advisor
더 나은 - "일반적인" ZigZag 및 일부 기능을 기반으로 하는 자체 Expert Advisor
각자에게.
특히 독일어...
예를 포함하여 모든 것이 오랜 시간 동안 수행되었고 MFC의 아날로그 형태로 표준 라이브러리 에 있는 경우 주제의 인터페이스에 대해 말하는 것은 무엇입니까?
깔끔하고 전문적인 패널을 만들기 위한 라이브러리가 있는지도 모르고 엉뚱한 토론을 하고 있습니다. 그것들은 살아 있고, 끌고, 최소화하고, 이벤트에 반응하는 등입니다.
깔때기가 첫 번째 단계에서 전환을 잃을 때 다른 그래픽 구조는 "아무도 솔루션의 존재를 의심하지 않습니다." 모든 솔루션. 그들은 읽지 않고, 알지도 못하고 알고 싶지도 않습니다. 그리고 표준 라이브러리에는 13MB의 MQL5 소스가 있습니다. 제정신이라면 누가 거기에 가겠는가?
토론하고 조언하고 문제를 이해했다고 생각하는 것이 더 즐겁습니다 ...
Renat, 저는 이 도서관에서 일한 지 2년이 되었습니다. 주요 단점은 컨트롤과 해당 구성 요소의 불연속성입니다. 트레일로 드래그할 때 양식 요소가 양식 뒤를 따라갈 때 효과를 보지 못했을 것입니다. 스펙타클은 다채롭지만 생산적이지는 않습니다. 이벤트 처리에서 MFC 접근 방식을 사용하는 것이 좋습니다. 이미 이전 포스트에서 라이브러리 자체의 골격이 좋다고 썼지만 결국에는 개별 프리미티브에서 벗어나 하나의 캔버스에 최종 결과(컨트롤이 있는 양식)를 그리고 그래프 위로 하나의 개체를 드래그해야 합니다(또는 다른 캔버스), 루프에서 위치를 변경하여 원시 객체의 무리가 아닙니다.
물론, 당신은 말할 수 있습니다 : 도서관이 있습니다. 도대체 왜 아직도 그것을 필요로합니까? 그리고 이것을 진정시키기 위해 원칙적으로 모든 것을 치료하십시오. 그것은 당신의 권리입니다.
그러나 여기에서 시각화와 GUI에 대해 이야기하는 것은 원칙적으로 아무도 당신에게 아무것도 요구하지 않으며 단지 이해 당사자 간의 토론일 뿐입니다.
모든 것이 오랫동안 수행되었고 예제를 포함하여 MFC의 아날로그 형태로 표준 라이브러리 에 있는 경우 주제의 인터페이스에 대해 모두 무엇입니까?
깔끔하고 전문적인 패널을 만들기 위한 라이브러리가 있는지도 모르고 엉뚱한 토론을 하고 있습니다. 그것들은 살아 있고, 끌고, 최소화하고, 이벤트에 반응하는 등입니다.
그들은 그래픽이 버그가 있고 미완성이며 몇 년 동안 수정되지 않았다는 것을 잊었습니다.
표준 그래픽 라이브러리에는 버그에 대한 동일한 주제가 충분히 있지만 관심이 없습니다.
다른 한편으로는 시작이 되었고, 유사물이 작성되었으며, 모든 사람이 파일로 자신이 가진 것을 실제로 끝낼 수 있습니다(일부 장소에서 매우 논쟁의 여지가 있는 13MB의 소스를 연구하려는 경우).
그러나 피드백은 종종 실제로 충분하지 않습니다. 버그 보고서에 따르면 항상 답변이 있는 것은 아닙니다...
그들은 그래픽이 버그가 있고 미완성이며 몇 년 동안 수정되지 않았다는 것을 잊었습니다.
그래픽에 대한 나의 특별한 성능에 따르면 작업에 필요하지 않습니다. 일반적으로 SB의 그래픽 위시리스트를 이틀 만에 대부분 만드는 것이 현실적입니다.
그러나 테스터에서 그래픽 동작이 다르다는 사실이 진짜 문제입니다! - 댓글도 달고 싶지 않습니다.
그래픽에 대한 나의 특별한 성능에 따르면 작업에 필요하지 않습니다. 일반적으로 SB의 그래픽 위시리스트를 이틀 만에 대부분 만드는 것이 현실적입니다.
그러나 테스터에서 그래픽 동작이 다르다는 사실이 진짜 문제입니다! - 댓글도 달고 싶지 않습니다.
성능에 관한 것이 아니라 작업의 버그에 관한 것입니다.