빠른 솔루션이 필요한 경우 CArrayInt에서 모든 티켓을 수집한 다음 새 틱이 도착하면 미결 주문 티켓을 CArrayInt와 비교합니다. Search() 메서드가 있습니다. 티켓이 없으면 비교를 중지합니다. 열린 주문 티켓이 있는 CArrayInt, CArrayInt를 재설정하고 CArrayInt의 모든 티켓을 다시 작성하고 전역적으로 설명된 플래그 MyOnTradeTransaction을 설정합니다. - 주문 목록이 변경되었다는 표시 - 코드는 매우 간결합니다.
그리고 영장 상실보다 더 많은 것을 잡아야 할 때 .. 탬버린과의 춤이 시작됩니다 ...
OrdersTotal()을 확인하면 보류 중인 주문의 활성화가 표시되지 않습니다. 예를 들어 - 주문 수 는 변경되지 않고 티켓도... 그리고 주문/포지션 수정 사실을 파악해야 할 때...
그러나 모든 것이 이미 발명되고 완료되었으며 씹는 것으로 무료로 액세스 할 수 있도록 배치되었습니다 ...
내가 부정하고 있는 이점은 무엇입니까? 나에게는 단 하나의 부정적인 것이 있습니다. 어떤 것이 어떻게 작동하는지 이해하고 싶고, 내 마음이 아니라 그것을 이해할 수만 있다면 나는 그것을 사용하는 것이 불편하고 나에게 편하지 않은 모든 것을 거부합니다. 나는 이미 당신이 내가 평생 읽을 수 있는 것보다 더 많은 편지를 쓴다고 말했습니다. 나한테 총구 굴리지마...
플러스 - 이벤트는 손실될 수 없습니다. OnTrade() 및 OnTradeTransaction()과 다릅니다. 그러나 당신은 그런 이벤트가 손실될 수 있다고 믿지 않습니다... 그래서 제가 말하는 것입니다 - 토론은 의미가 없습니다.
아니요, 구현되지 않았습니다. 이제 이것이 중요한 것이 아닙니다. 이것은 거의 마지막 단계에 있습니다. 동일한 유형의 모든 작업을 한 번에 수행하고 다른 시간 간격으로 나누지 않는 것이 더 쉽습니다. 나를 위한.
좋아, 기다릴게
그러나 그것은 다른 방향으로 밝혀졌습니다. 이미이 문제가 발생했습니다. 즉시 프로그램 구조에 저장하는 기능을 넣지 않고 파일에 저장을 쓰기 시작했습니다. 모든 것이 매우 번거로운 것으로 판명되었습니다. 그리고 대부분의 코드를 처음부터 다시 작성 - IMHO, 파일에 저장해야 하는 경우 최소한 "스텁"을 사용하여 즉시 구현해야 합니다. 그렇지 않으면 각 클래스에 저장하고 싶은 모든 것을 수집합니다. - 매우 힘든 작업, 실제로 전체 소스 코드를 분석해야 합니다.
그러나 그것은 다른 방향으로 밝혀졌습니다. 이미이 문제가 발생했습니다. 즉시 프로그램 구조에 저장하는 기능을 넣지 않고 파일에 저장을 쓰기 시작했습니다. 모든 것이 매우 번거로운 것으로 판명되었습니다. 그리고 대부분의 코드를 처음부터 다시 작성 - IMHO, 파일에 저장해야 하는 경우 최소한 "스텁"을 사용하여 즉시 구현해야 합니다. 그렇지 않으면 각 클래스에 저장하고 싶은 모든 것을 수집합니다. - 매우 힘든 작업, 실제로 전체 소스 코드를 분석해야 합니다.
저장/로드 방법은 처음에 선언됩니다. 또한 표준 라이브러리 의 기본 CObject 개체에서 . 그러나 각 라이브러리 개체에서 파일에 저장하는 구현을 즉시 작성하십시오. 이것은 하나, 음, 두 개의 개체(따라서 기사)를 여전히 어떻게든 설명할 수 있습니다. 그러나 각 기사에 저장/로드 방법에 대한 설명을 작성하는 것은 기사에서 기사로 거의 동일한 "동작"을 읽는 것이 다소 지루할 것입니다. 그런 양의 기사를 읽는 것은 당신도 마찬가지라고 생각합니다). 따라서 이 작업은 끝을 향해 두세 개의 기사로 설명되어야 합니다. 한 번에 한 번에 순식간에 지나가고 독자에게 큰 부담을 주지는 않습니다.
기사에 아무 것도 설명되어 있지 않으면 다른 문제입니다. 물론 즉시 필요합니다. 그것은 모두 프레젠테이션과 목표의 세부 사항에 달려 있습니다. 목표가 코드 기반이라면 모든 것을 한 번에, 목표가 교육 기사라면 점차적으로 - 때가 되면. 두 번째 옵션이 있습니다.
온트레이드 이벤트가 다시 언급되었습니다. 연결이 복원된 후에도 단말기가 여전히 거래 환경을 동기화하기 때문에 연결이 끊긴 경우 등의 경우 OnTradeTransaction 을 보장하는 데 문제가 없습니다. OnTrade는 부차적이므로 신뢰할 수 있습니다. 개발자 자신이 잼을 허용하지 않았지만 예약이 제거되었으므로 모든 것이 정상입니다.
그러나 각 기사에 저장/로드 방법에 대한 설명을 작성하는 것은 기사에서 기사로 거의 동일한 "동작"을 읽는 것이 다소 지루할 것입니다. 그런 양의 기사를 읽는 것은 당신도 마찬가지라고 생각합니다). 따라서 이 작업은 끝을 향해 두세 개의 기사로 설명되어야 합니다. 한 번에 한 번에 급습하고 독자에게 큰 부담을 주지는 않습니다.
읽어야 할 글의 양이 엄청 많다는 말은 아니지만 소스코드의 양이 엄청나서 도움을 받지 않고는 사용법을 알 수 없다라고 썼습니다 / 자주하는 질문
빠른 솔루션이 필요한 경우 CArrayInt에서 모든 티켓을 수집한 다음 새 틱이 도착하면 미결 주문 티켓을 CArrayInt와 비교합니다. Search() 메서드가 있습니다. 티켓이 없으면 비교를 중지합니다. 열린 주문 티켓이 있는 CArrayInt, CArrayInt를 재설정하고 CArrayInt의 모든 티켓을 다시 작성하고 전역적으로 설명된 플래그 MyOnTradeTransaction을 설정합니다. - 주문 목록이 변경되었다는 표시 - 코드는 매우 간결합니다.
그리고 영장 상실보다 더 많은 것을 잡아야 할 때 .. 탬버린과의 춤이 시작됩니다 ...
OrdersTotal()을 확인하면 보류 중인 주문의 활성화가 표시되지 않습니다. 예를 들어 - 주문 수 는 변경되지 않고 티켓도... 그리고 주문/포지션 수정 사실을 파악해야 할 때...
그러나 모든 것이 이미 발명되고 완료되었으며 씹는 것으로 무료로 액세스 할 수 있도록 배치되었습니다 ...
내가 부정하고 있는 이점은 무엇입니까? 나에게는 단 하나의 부정적인 것이 있습니다. 어떤 것이 어떻게 작동하는지 이해하고 싶고, 내 마음이 아니라 그것을 이해할 수만 있다면 나는 그것을 사용하는 것이 불편하고 나에게 편하지 않은 모든 것을 거부합니다. 나는 이미 당신이 내가 평생 읽을 수 있는 것보다 더 많은 편지를 쓴다고 말했습니다. 나한테 총구 굴리지마...
플러스 - 이벤트는 손실될 수 없습니다. OnTrade() 및 OnTradeTransaction()과 다릅니다. 그러나 당신은 그런 이벤트가 손실될 수 있다고 믿지 않습니다... 그래서 제가 말하는 것입니다 - 토론은 의미가 없습니다.
그리고 영장 상실보다 더 많은 것을 잡아야 할 때 .. 탬버린과의 춤이 시작됩니다 ...
OrdersTotal()을 확인하면 보류 중인 주문의 활성화가 표시되지 않습니다. 예를 들어 - 주문 수 는 변경되지 않고 티켓도... 그리고 주문/포지션의 수정을 포착해야 할 때...
그러나 모든 것이 이미 발명되고 완료되었으며 씹는 것으로 무료로 액세스 할 수 있도록 배치되었습니다 ...
나는 OrdersTotal을 분석하는 것을 제안하지 않습니다, 그것은 신뢰할 수 없습니다
이러한 방식으로 주문 수정을 추적할 수 없으면 CArray 또는 CObj를 기반으로 클래스를 작성해야 합니다.
기본적인 작업이 아닌 빠른 솔루션을 제공했습니다.)
플러스 - 이벤트는 손실될 수 없습니다.
나는 OrdersTotal을 분석하는 것을 제안하지 않습니다, 그것은 신뢰할 수 없습니다
이러한 방식으로 주문 수정을 추적할 수 없으면 CArray 또는 CObj를 기반으로 클래스를 작성해야 합니다.
기본적인 작업이 아닌 빠른 솔루션을 제공했습니다.)
아마도 PC에서 리셋버튼을 누르면 .... 글을 오래 안써봐서 터미널 재기동시 클래스 상태를 파일로 저장하는 방법을 여쭤봤던 기억이 납니다. - 이미 구현되어 있습니까?그리고 손실의 신뢰성을 위해 발코니에서 컴퓨터를 던질 수도 있습니다. :) 그리고 아이스 링크가 아래에서 기다리게하십시오. 그런 다음 위에 콘크리트를 부을 수 있습니다 :))
아니요, 구현되지 않았습니다. 이제 이것이 중요한 것이 아닙니다. 이것은 거의 마지막 단계에 있습니다. 동일한 유형의 모든 작업을 한 번에 수행하고 다른 시간 간격으로 나누지 않는 것이 더 쉽습니다. 나를 위한.
아니요, 구현되지 않았습니다. 이제 이것이 중요한 것이 아닙니다. 이것은 거의 마지막 단계에 있습니다. 동일한 유형의 모든 작업을 한 번에 수행하고 다른 시간 간격으로 나누지 않는 것이 더 쉽습니다. 나를 위한.
좋아, 기다릴게
그러나 그것은 다른 방향으로 밝혀졌습니다. 이미이 문제가 발생했습니다. 즉시 프로그램 구조에 저장하는 기능을 넣지 않고 파일에 저장을 쓰기 시작했습니다. 모든 것이 매우 번거로운 것으로 판명되었습니다. 그리고 대부분의 코드를 처음부터 다시 작성 - IMHO, 파일에 저장해야 하는 경우 최소한 "스텁"을 사용하여 즉시 구현해야 합니다. 그렇지 않으면 각 클래스에 저장하고 싶은 모든 것을 수집합니다. - 매우 힘든 작업, 실제로 전체 소스 코드를 분석해야 합니다.
(거래 내역 폴링 없이) 재현 가능한 몇 가지 예를 제공해 주시면 감사하겠습니다.
나는 당신의 유익한 행동에 보답하고 싶습니다. 불행히도 나는 매우 크고 복잡한 코드에서 짧은 작업 코드를 고르는 데 어려움을 겪고 있습니다. 또한 매우 구체적입니다(예: 한 번에 하나의 포즈만 엽니다).
그래서 Slava의 경우 컴파일된 예제 대신 코드 스켈레톤을 배치해야 했습니다.
그러나 나는 무언가를 시도 할 것입니다. 그렇지 않으면 내 양심이 나를 괴롭힐 것입니다. 그러나 빨리는 아닙니다.
추신: 제 말은 코드 작성 생산성이 매우 낮습니다. 저는 인내만 가지고 있습니다. 그리고 동시에 실제 계정 에서 가능한 한 빨리 고문을 시작하는 데 과부하가 걸립니다. 나는 당신의 생산성이 부럽습니다.
좋아, 기다릴게
그러나 그것은 다른 방향으로 밝혀졌습니다. 이미이 문제가 발생했습니다. 즉시 프로그램 구조에 저장하는 기능을 넣지 않고 파일에 저장을 쓰기 시작했습니다. 모든 것이 매우 번거로운 것으로 판명되었습니다. 그리고 대부분의 코드를 처음부터 다시 작성 - IMHO, 파일에 저장해야 하는 경우 최소한 "스텁"을 사용하여 즉시 구현해야 합니다. 그렇지 않으면 각 클래스에 저장하고 싶은 모든 것을 수집합니다. - 매우 힘든 작업, 실제로 전체 소스 코드를 분석해야 합니다.
저장/로드 방법은 처음에 선언됩니다. 또한 표준 라이브러리 의 기본 CObject 개체에서 . 그러나 각 라이브러리 개체에서 파일에 저장하는 구현을 즉시 작성하십시오. 이것은 하나, 음, 두 개의 개체(따라서 기사)를 여전히 어떻게든 설명할 수 있습니다. 그러나 각 기사에 저장/로드 방법에 대한 설명을 작성하는 것은 기사에서 기사로 거의 동일한 "동작"을 읽는 것이 다소 지루할 것입니다. 그런 양의 기사를 읽는 것은 당신도 마찬가지라고 생각합니다). 따라서 이 작업은 끝을 향해 두세 개의 기사로 설명되어야 합니다. 한 번에 한 번에 순식간에 지나가고 독자에게 큰 부담을 주지는 않습니다.
기사에 아무 것도 설명되어 있지 않으면 다른 문제입니다. 물론 즉시 필요합니다. 그것은 모두 프레젠테이션과 목표의 세부 사항에 달려 있습니다. 목표가 코드 기반이라면 모든 것을 한 번에, 목표가 교육 기사라면 점차적으로 - 때가 되면. 두 번째 옵션이 있습니다.
온트레이드 이벤트가 다시 언급되었습니다. 연결이 복원된 후에도 단말기가 여전히 거래 환경을 동기화하기 때문에 연결이 끊긴 경우 등의 경우 OnTradeTransaction 을 보장하는 데 문제가 없습니다. OnTrade는 부차적이므로 신뢰할 수 있습니다. 개발자 자신이 잼을 허용하지 않았지만 예약이 제거되었으므로 모든 것이 정상입니다.
그러나 각 기사에 저장/로드 방법에 대한 설명을 작성하는 것은 기사에서 기사로 거의 동일한 "동작"을 읽는 것이 다소 지루할 것입니다. 그런 양의 기사를 읽는 것은 당신도 마찬가지라고 생각합니다). 따라서 이 작업은 끝을 향해 두세 개의 기사로 설명되어야 합니다. 한 번에 한 번에 급습하고 독자에게 큰 부담을 주지는 않습니다.
읽어야 할 글의 양이 엄청 많다는 말은 아니지만 소스코드의 양이 엄청나서 도움을 받지 않고는 사용법을 알 수 없다라고 썼습니다 / 자주하는 질문
이렇게 많은 양의 데이터를 저장하는 구현을 기다릴 것입니다. 어떻게 보일지 흥미롭습니다.
이렇게 많은 양의 데이터를 저장하는 구현을 기다릴 것입니다. 어떻게 보일지 흥미롭습니다.
좋아요