내 접근 방식. 코어 - 엔진. - 페이지 127

 
Vasiliy Sokolov :

Peter, 미안하지만 당신의 일은 받아들여지지 않습니다. 왜냐하면. 당신이 보낸 것은 드문 해킹입니다.

...

계산할 때까지. 귀하의 개선을 기대합니다. 그리고 당신이 그것을 알아낼 때까지 3D는 렌더링되지 않습니다!

왜 피터를 놀리는거야? 그는 프리랜서 예술가입니다. 당신이 원하는 것이 이루어집니다. 그리고 그것이 복잡하고 자신의 생각의 개념에 맞지 않는다면 그는 하기 싫고 하지도 않고 단순하고 하고 싶은 대로 되는 것으로 대체된다...

 
Artyom Trishkin :

왜 피터를 놀리는거야? 그는 프리랜서 예술가입니다. 당신이 원하는 것이 이루어집니다. 그리고 그것이 복잡하고 자신의 생각의 개념에 맞지 않는다면 그는 하기 싫고 하지도 않고 단순하고 하고 싶은 대로 되는 것으로 대체된다...

그러나 그(Peter)는 핵심 엔진에 대한 수요가 있고 주문을 받기를 원합니다. 기타 등등 여기에서 Vasily는 그에게 현실에 작은 감동을 주었습니다.

그리고 Peter, Alexander의 패널은 어떻습니까?

 
Artyom Trishkin :

왜 피터를 놀리는거야? 그는 프리랜서 예술가입니다. 당신이 원하는 것이 이루어집니다. 그리고 그것이 복잡하고 자신의 생각의 개념에 맞지 않는다면 그는 하기 싫고 하지도 않고 단순하고 하고 싶은 대로 되는 것으로 대체된다...

이런, 당신의 교활한 모습이 느껴집니다 :)

나는 그 남자가 일어나서 자신의 결정에 따라 누구나 자신의 프로그램에 대한 그래픽 인터페이스를 만들 수 있다고 말했기 때문에 침을 뱉었습니다. 그는 그것을 증명하기 위해 자원했고 자신이 사건에서 자신의 결정을 확인하겠다고 제안했습니다. 나는 확인했다 - 결과는 완전한 악몽이다. 따라서 그들이 말했듯이 그는 자신을 짐이라고 불렀습니다. 몸에 올라갑니다.)

 
상상의 문제를 해결하는 것과 타사 사용자의 특정 작업에는 큰 차이가 있습니다. 이 엔진은 두 번째 경우에만 사용된다고 명시되어 있습니다. 바로 이 두 번째 경우에 효과적이고 보편적인 솔루션을 제공하기 위해서는 솔루션이 기본 프로그래밍 패러다임을 기반으로 해야 합니다. 지금까지 Peter의 솔루션에서 이러한 패러다임의 올바른 구현을 보지 못했습니다. 반대로 특별히 공식화된 "단순한" 작업은 내부 문제의 전체 얽힘과 제안된 전체 솔루션의 완전한 어둠을 드러냈습니다.
 
Vasiliy Sokolov :
상상의 문제를 해결하는 것과 타사 사용자의 특정 작업에는 큰 차이가 있습니다. 이 엔진은 두 번째 경우에만 사용된다고 명시되어 있습니다. 바로 이 두 번째 경우에 효과적이고 보편적인 솔루션을 제공하기 위해서는 솔루션이 기본 프로그래밍 패러다임을 기반으로 해야 합니다. 지금까지 Peter의 솔루션에서 이러한 패러다임의 올바른 구현을 보지 못했습니다. 반대로 특별히 공식화된 "단순한" 작업은 내부 문제의 전체 얽힘과 제안된 전체 솔루션의 완전한 어둠을 드러냈습니다.

당신은 과장의 달인이십니다...

이러한 모든 "문제"는 한두 번 해결됩니다. 방금 기술을 만들었고 실제로 테스트할 사람이 없었습니다. 그리고 당신은 즉시 "칼집을 뺀 세이버"로 ...)

행 수를 제한하는 것을 제외하고는 이 모든 것이 넌센스입니다. 이것은 아직 해결되지 않았습니다.


주문이 열렸는지 닫혔는지 확인하는 방법을 잊어버려 주문이 닫히지 않았습니다. 그리고 당신은 "비극"을 퍼뜨립니다.))

 
Реter Konow :
주문이 열렸는지 닫혔는지 확인하는 방법을 잊어버려 주문이 닫히지 않았습니다. 그리고 당신은 "비극"을 퍼뜨립니다.))

PositionSelectByTicket

 
Konstantin Nikitin :

PositionSelectByTicket

감사해요.))

여기 한 남자가 고대 그리스 비극을 퍼뜨렸습니다 ...)) 그가 주장하는 모든 문제가 얼마나 간단하게 해결되었는지 이해하지 못하기 때문에 재미있습니다. 무제한 테이블 행을 제외한 모든 것.

 
Реter Konow :

당신은 과장의 달인이십니다...

...

젠장, 무슨 일이 벌어지고 있는지 정말 모르겠어? 아니면 이런 식으로 모퉁이를 자르려고 하는 거야?

어느 패널에서나 가장 기본적이고 어려운 순간은 일관된 상태를 표시하는 것입니다. 주문이 열려 있으면 표시되어야 하고 "거래" 탭에 없으면 패널에도 없어야 합니다. 이것은 기본적이며 개념적으로 "매우 간단합니다". 그러나 "매우 간단하게" 만들려면 상태 모델을 기반으로 하는 패널이 필요합니다. 당신은 그런 것이 없지만 사용자 객체에 채워진 문자열에 일관성이 없는 비뚤어진 데이터베이스가 있습니다.

그리고 이제 당신은 문제가 없다는 것을 우리에게 증명하려고 노력하고 있습니다. 테이블에 표시되지 않는 주문은 정상 입니다. 테이블에 주문이 있지만 실제로는 오랫동안 닫혀 있는 주문도 정상입니다. 그리고 일반적으로 모든 것이 매우 정상적이고 좋으며 위치 수만 20개로 제한됩니다.

 
Vasiliy Sokolov :

질문이 없도록 작업을 다시 명확히하겠습니다.

  1. 테이블은 동적이며 거래 탭과 동일한 주문을 보여줍니다. 탭에 주문이 없으면 테이블에도 없는 것입니다.
  2. 테이블에 표시된 주문의 수는 임의여야 합니다. 상한선은 없습니다.
  3. 표준 대화 상자를 통해 주문을 열면 테이블에 주문이 나타나야 합니다. 표준 수단으로 주문을 마감하면 테이블에서 주문이 사라집니다.
  4. 불일치 상태는 허용되지 않습니다 ! 테이블에 한 항목이 표시되고 거래 탭에 다른 항목이 표시되면 실수입니다.

지방이 실패할 때까지 . 귀하의 개선을 기대합니다. 그리고 당신이 그것을 알아낼 때까지 어떤 3D도 렌더링되지 않습니다!

  1. 이를 위해 사용자는 틱 또는 타이머에 대한 주문 순환을 작성하고 자신의 티켓을 배열에 작성된 티켓과 비교해야 합니다. 배열에 티켓이 없으면 주문이 방금 열렸고 E_Main_form_1__PnL( OrderTicket (), OrderProfit ());
  2. 이 질문은 기술적으로 매우 어렵습니다. 행 수는 미리 제한되어 있습니다. 그러나 20보다 훨씬 더 많을 수 있습니다. 200도 할 수 있습니다.
  3. 열 때와 마찬가지로 표준 창을 통해 주문을 닫는 것은 틱 또는 타이머 이벤트의 주문 주기에서 수정됩니다. 그리고 열린 주문의 티켓 배열에 티켓이 있고 그 주문이 더 이상 존재하지 않으면 전화해야합니다.
    E_Main_form_1_CLOSE_ROW___Orders_table(ticket);
    

4. 이 주기를 주문별로 올바르게 작성하면 테이블이 올바르게 작동합니다.

주문을 올바르게 처리하는 방법을 잊어버렸기 때문에 이 메커니즘을 올바르게 구현하지 못했습니다. 이로부터 테이블이 올바르게 작동하지 않습니다.

그러나 이것이 동적 테이블 자체가 작동하지 않는다는 것을 의미하지는 않습니다.

 
Реter Konow :

감사해요.))

여기 한 남자가 고대 그리스 비극을 퍼뜨렸습니다 ...)) 그가 주장하는 모든 문제가 얼마나 간단하게 해결되었는지 이해하지 못하기 때문에 재미있습니다. 무제한 테이블 행을 제외한 모든 것.

나는 당신, 당신의 코드, 당신이 하는 모든 일, 일종의 사람들에 대한 무시를 많이 느끼지만, 세부 사항에 관해서는 헛소리가 시작됩니다. 작지만 좋은 품질, 한 가지만 하십시오. 그래서 당신은 그들이 말하는 모든 것이 단순히 해결되고 기초적이라고 말합니다. 그러나 웬일인지 나는 그런 종류의 아무것도없는 결정을 내 렸습니다. 2주 만에 이 모든 간단한 트릭을 수행하지 못한 이유는 무엇입니까?

부정적인 분위기에 대해 죄송합니다. 당신은 나를 실망 시켰습니다. 나는 더 많이 그리고 더 잘 보기를 바랐다. 데모를 수정하십시오. 응용 프로그램에 따라 질적으로 잘 만드십시오. "예, 기본입니다. 여기서 수정해야 합니다." 즉시 테스트할 수 있는 솔루션을 제안하십시오.