차트의 개체 배치를 더 이상 "수직으로" 제어할 수 없습니다. - 페이지 2

 
stringo >> :

1. 물론 문서화되지 않은 기능에 대해 논의할 수 있습니다. 그리고 이것은 반복적으로 수행되었습니다. 그러나 해결책을 찾기 위해. 문서화되지 않은 행동을 변경하지 않습니다.

2. 우리는 개체의 그리기 순서를 변경하기 위해 더 많은 요청(이 토론의 참가자보다 더 많이)을 받았습니다. 예, 상위 5개 항목에서 객체가 생성될 때까지 간단하고 자연스러운 순서를 만들었습니다(그러나 이것도 문서화되지 않음). 이제 우리는 무엇을 합니까?

3. 아무것도 하지 마세요! 현재 정렬을 사용하면 이름으로 정렬할 때는 불가능했던 개체 그룹을 간단하게 다시 만들 수 있기 때문입니다.

제 생각에는 실수를 하는 것이 두려운 것 같았습니다. 다른 물건의 존재에 대해 걱정하지 마세요."

deinit() - 객체 삭제를 수행할 때 황금률이 있습니다.

때때로 그들은 너무 많이 "코딩"하여 절대적으로 모든 것을 삭제합니다 ...

;)

 
stringo писал(а) >>

2. 우리는 개체의 그리기 순서를 변경하기 위해 더 많은 요청(이 토론의 참가자보다 더 많이)을 받았습니다. 예, 상위 5개 항목에서 객체가 생성될 때까지 간단하고 자연스러운 순서를 만들었습니다(그러나 이것도 문서화되지 않음). 이제 우리는 무엇을 합니까?

실례합니다. 그러나 이러한 요청이 누구에게서 온 것인지 고려되었습니까?

포럼을 보면 Expert Advisors의 지표가 계산되기를 원하는 사람들이 많이 있습니다. 이것이 해서는 안 된다는 것을 이해하는 사람들보다 훨씬 더 많은 사람들이 있습니다. 이와 같은 것을 더 많이 찾을 수 있습니다.

 
stringo писал(а) >>

3. 아무것도 하지 마세요! 현재 정렬을 사용하면 이름으로 정렬할 때는 불가능했던 개체 그룹을 간단하게 다시 만들 수 있기 때문에.


아주 심각한 것을 놓친 것 같습니다...

 
죄송합니다. 다시 한 번 말씀드리지만, 그런 제안은 온전한 사람만이 할 수 있습니다... 그리고 왜 내가 이 순서로 코드 라인을 작성했는지 ...하지만 그들은 전혀 잘못된 순서로 그려집니다 ....
 

"시간순"으로 정렬하는 논리가 무엇인지 궁금합니다. 계산이 이루어졌습니다. 나는 시간을 거슬러 올라가 미래를 보는 눈으로 과거의 물건을 만든다. 나는 물건의 생성 시간이 필요하지 않다. 물체의 이름과 좌표는 나에게 중요합니다. 또한 시간이 아닌 이름으로 개체를 검색합니다.

 

좋든 싫든 시스템의 그래픽 부분은 매우 중요합니다. 이것은 제품 홍보의 중요한 측면이자 경쟁력입니다. 내 악의에도 불구하고, 나는 MT의 그래픽 부분이 여전히 작동하고 나쁘지 않다는 것을 인정해야 합니다. 그리고 MT의 성공의 큰 부분은 그녀의 장점이라고 생각합니다.

내가 왜 Z-order와 Alpha(투명성)를 지지하는 걸까?

이것들은 기본 요소입니다. 감히 상기시켜 드립니다.

:)

 


stringo писал(а) >>

미안, 나도 중요한 걸 놓친 것 같은데? 나는 당신의 요점이 내 제안에 대한 답변인지 잘 이해하지 못했습니다. 아닌 것 같다...

나는 그것들을 당신의 독립적 인 포인트로 대답하려고 노력할 것입니다.

1. 물론 문서화되지 않은 기능에 대해 논의할 수 있습니다. 그리고 이것은 반복적으로 수행되었습니다. 그러나 해결책을 찾기 위해. 문서화되지 않은 행동을 변경하지 않습니다.

방금 토론을 위해 세 가지 다른 옵션을 제안했습니다. 각 옵션은 현재 솔루션보다 더 나은 IMHO(순수)입니다. 문서화되지 않은 것에 관해서는 이것은 당신의 정원에있는 돌입니다. 차트에 개체를 만들면 순서에 따라 수행합니다. 이 순서를 문서화하십시오. ;)


2. 우리는 개체의 그리기 순서를 변경하기 위해 더 많은 요청(이 토론의 참가자보다 더 많이)을 받았습니다.

불행히도, 우리는 그러한 요청이 있었다는 사실, 그 숫자, 얼마나 많은 참가자가 제안했는지 알지 못합니다(100명의 요청이 100개라는 점에 동의해야 합니다. 이것은 한 사람이 요청하는 것과 전혀 동일하지 않습니다. 백 번 연속). 가능하다면 어떤 제안이었는지, 그리고 왜 그들의 주장을 수용했는지 말씀해 주십시오.


예, 상위 5개 항목에서 객체가 생성될 때까지 간단하고 자연스러운 순서를 만들었습니다(그러나 이것도 문서화되지 않음). 이제 우리는 무엇을 합니까?

글쎄, 적어도 문서화하십시오. 이것이 GUI의 주요 기능 중 하나이기 때문입니다.

이것이 "단순한" 방법이라는 사실에 대한 주장은 이해할 수 있지만 그것이 자연스럽다는 것은 너무 의심스럽습니다. 개발자가 "100개의 개체가 있습니다. 개체를 배치하는 방법 이 필요합니다."라는 문제를 해결하면 자연스러운 현상입니다. 그러나 그가 다른 사용자/상인에 대해 생각해야 하는 다른 개발자에 대해 생각한다면 그는 텍스트의 기질을 "타이어"로 바꾸는 터미널의 동작에 대해 적어도 의아해할 것입니다.

3. 아무것도 하지 마세요! 현재 정렬을 사용하면 이름으로 정렬할 때는 불가능했던 개체 그룹을 간단하게 다시 만들 수 있기 때문입니다.

쉽게 재현할 수 있습니다. 그리고 차트의 상황에 동적으로 조정되는 인터페이스를 개발한다면? 글쎄, 예를 들어, 열린 위치가 있는 경우 - 적어도 그것에 대한 정보를 표시해야 합니다 - 이에 대한 개체가 있어야 합니다! 하지만 EA는 포지션을 닫았고 더 이상 필요하지 않습니다. 그리고 잠시 후 구매 신호가 있습니다 ....

인터페이스의 정교함이 부족한 다른 영역의 예: 개체의 투명도를 설정할 수 있는 기능이 없기 때문에 Y = 32000 좌표로 이동해야 합니다.)


그리고 지금, 사건에 대해: 우리는 무엇에 대해 논쟁하고 있습니까? 나와 많은 포럼 사용자는 현재 문서화되지 않은 개체 배치 방법이 불편하고 왜 그것이 불편하다고 생각합니다. 귀하의 "자연스러운" 위치를 최소한 몇 가지 유사한 논거로 설명하고 그것이 우리보다 더 정확한 이유, 모든 개체를 표시할 때 동일한 개체 이름으로 정렬하기 전에 모든 개체를 다시 만드는 것의 이점은 무엇인지 설명하십시오. 설득하면 말할 것도 없고, 그렇지 않으면 수직 배치를 관리 가능하게 만들기 위한 질문/요청이 계속 유효합니다.

이 모든 것이 편협한 프로그래머라는 불편한 시각을 갖게 하기 위한 것이 아님을 이해하십시오. 당신은 내가 개인적으로 아직 아무것도 보지 못한 것과 동등한 훌륭한 플랫폼을 만들었습니다. 아직 손에 넣지 않은 실수가 있다는 것뿐입니다. 한 번에 모든 것을 할 수는 없습니다. 그러나 나는 5가 4보다 낫기를 정말로 원하므로 적어도 거기에 있던 좋거나 친숙한 것을 깨뜨리지 마십시오(이름순으로 정렬) ;)

 

첨가물

3. А ничего не делать! Так как при нынешней сортировке можно просто пересоздать группу объектов, что было невозможно при сортировке по именам .

etozh 4에서 왜 불가능합니까? 매우 쉽게 수행되고 특징적인 것 - 개체의 이름이 변경되지 않은 경우 결과는 제거 전과 정확히 동일합니다.

하지만 현 상황에서는 구성의 아이덴티티를 보장할 수 없습니다;) 결국 훌륭한 OnChartEvent 기능을 만드셨습니다. Init에서 개체를 처음 생성하는 동안 순서는 항상 명확합니다. 그러나 객체 삭제를 시작하면 CHARTEVENT_OBJECT_DELETE 및 CHARTEVENT_OBJECT_CREATE 를 실행할 수 있으며 이는 매번 새로운 방식으로 객체 체인을 쉽게 구축할 수 있습니다. 실제로 초기화할 때 OnChartEvent 핸들러는 아직 작동하지 않지만 다시 생성할 때 삭제 또는 생성 각각에 대해 "재채기"하고 최종적으로 수집되는 순서는 MathRand만 알고 있습니다. :)

 

ForexTools , 당신은 새로운 터미널에 대해 정말 끔찍한 말을 하고 있습니다...

여기서 나가서 눈사태 행성에서 sklis 훈련을 시작하고 싶습니다...

아마 그렇게 될 수 없습니다.

 
Oper >> :

ForexTools , 당신은 새로운 터미널에 대해 정말 끔찍한 말을 하고 있습니다...

아마 그렇게 될 수 없습니다.

괜찮습니다. 베타 버전의 일반적인 개선 사항입니다. 개발자는 모든 것을 예측할 수 없습니다. 그들 자신이나 우리 중 하나가 터미널 동작의 부적절함을 발견하고 뭔가 잘못되었다고 추측할 때까지. 나를 놀라게 한 유일한 것은 그들이 우리가 원하는 방식이 아닌 것을 보여주려는 (최대) 모든 시도에 대한 고통스러운 반응입니다. :)