오류, 버그, 질문 - 페이지 989

 

아니요, 모든 자동차는 개인용입니다. Piggy에서 WS에 이르기까지 축에도 라이센스가 부여됩니다. 나는 죄책감이 든다 ... 우리는 스스로를 변명해야한다 ... 스스로를 정당화해야한다 ... 로그, 이것, 저것 ...

그리고 프로세서의 코어보다 더 많은 잠금 에이전트를 두는 것은 입법 수준에서 금지되어야 하고, 그게 다야!

 
muallch :

...

그리고 프로세서의 코어보다 더 많은 잠금 에이전트를 두는 것은 입법 수준에서 금지되어야 하고, 그게 다야!

일반적으로 논리적입니다.
 

안녕하세요. 개발자들에게 질문이 있습니다. 이상적인 거래 형성 주기는 다음 단계로 구성됩니다.

1. OrderSend()를 통해 요청을 보낸 다음 메서드가 true와 유효한 retcode를 반환했는지 확인합니다.

2. 다음으로 OnTradeTransaction()을 통해 서버에서 요청의 진행 상황을 추적해야 합니다. 이 핸들러는 매우 편리하며 프로세스를 완전히 제어할 수 있습니다.

그러나 우리는 현실 세계에 살고 있으며, 예를 들어 연결 실패로 인해 또는 단순히 트랜잭션이 "배송 중 손실"로 인해 TRADE_TRANSACTION_REQUEST 유형의 트랜잭션을 기다리지 않을 수 있습니다. 따라서 대기 루프가 무한해지고 요청에 따라 트랜잭션이 완료되었는지 여부를 판별할 수 없게 됩니다.

불가항력의 경우 논리적으로 올바른 프로세스 종료를 명확하게 수신하여 이러한 비상 사태를 처리하기 위한 법적 절차가 있습니까? 예를 들어 TRADE_TRANSACTION_REQUEST를 20초(또는 30초 또는 40초) 이내에 기다리지 않았다면 느리지만 정확한 알고리즘으로 전환합니다. 히스토리에 있는 주문 과 그 상태를 계산하여 신호를 열거나 건너뛰도록 또 다른 요청을 할 것인지 결정합니다. OrderSendAsync() 메서드의 경우 작업이 훨씬 더 복잡합니다. 특정 주문이 작동하지 않았다는 정확한 기준이 있어야 하고 이 기준을 적용하기 시작할 시기를 알아야 합니다. 제가 잘못 이해한 부분이 있다면 정정 부탁드립니다.

 
M24 :

OrderSendAsync() 메서드의 경우 작업이 훨씬 더 복잡합니다. 특정 주문이 작동하지 않았다는 정확한 기준이 있어야 하고 이 기준을 적용하기 시작할 시기를 알아야 합니다. 제가 잘못 이해한 부분이 있다면 정정 부탁드립니다.

HistorySelectByPosition - 이론적으로 도움이 될 것입니다. 주문이 전송 될 때 id가 발행됩니다.

 
표시기의 세로 축이 표시기의 표시와 함께 사라질 수 있는 이유는 무엇입니까? 이것은 기본 지표에서는 발생하지 않지만 생성 된 지표에는 그러한 문제가 있습니다. 말그대로 약간의 가로 스크롤 값과 돋보기의 값을 늘리면 사진이 사라집니다.//서비스 데스크에서 복제하겠습니다.
 

VanHelsing :

32x 시스템에서도 Win7은 이미 실수 연산에 문제가 있으며 XP에서는 "wininet.dll" 라이브러리에 값을 전달할 때 전혀 작동하지 않습니다.

그리고 wininet에서 실수를 어디에서 전송합니까?
 
papaklass :

1. 현재 틱에 거래 주문을 보내고 다음 틱에 실행을 확인하는 것을 규칙으로 합니다. 그러면 무한 루프가 발생하지 않습니다.

2. 이전 틱에서 주어진 주문의 실행을 확인할 때 모든 종류의 OnTrade()/ OnTradeTransaction()을 귀찮게하지 마십시오. 계정 상태를 확인하십시오. 원본으로 작업합니다. 결국 모든 거래 주문은 거래 계정의 상태를 변경하기 위한 것입니다. 따라서 이 상태의 변화를 확인하십시오.

3. 검사 결과에 따라 로봇의 추가 논리를 수행합니다.

OnTrade()/OnTradeTransaction() 과 같은 기능을 사용하기 전에 무엇이 더 중요한지 결정하십시오:

ㅏ). 주어진 시장 상황에서 포지션을 개시/마감/수정합니다.

비). 거래 주문이 실행되지 않는 이유를 찾는 데 시간을 할애하고 책임이 있는 사람을 찾으십시오.

그래도 약간의 오해가 있습니다. 다음 틱에 대한 확인 결과 위치 변경 을 받지 못한 경우 이 경우 어떻게 해야 합니다. 변화가 없는 이유는 완전히 다를 수 있습니다. 옵션:

요청 시 주문이 서버에서 생성되었지만 어떤 이유로 인해 거부되었습니다.

서버 과부하 - 실행 지연,

잠시 연결이 끊어졌습니다.

주문이 실행되지 않았다는 정확한 기준을 알고 싶습니다. 비동기식 시스템의 시간 바인딩은 그다지 정확하지 않아 불확실성을 허용하는 것 같습니다. 기록에서 주문을 선택하고 상태를 확인하거나 sion에서 제안한 대로 HistorySelectByPosition을 사용하는 것이 합리적일 수 있습니다. 개발자가 이 시스템을 이와 같이 설계했다면 이러한 키 작업을 수행하기 위한 "올바른" 방법이 있어야 한다는 사실에서 진행합니다.

 
M24 :

주문이 실행되지 않은 정확한 기준을 알고 싶습니다

당신은 이미 그것을 들었다


모든 종류의 OnTrade()/ OnTradeTransaction()에 신경쓰지 마십시오.

원본으로 작업

따라서 주문선택 하고 상태확인하십시오 .
 

안녕하세요!

스크립트가 시작될 때 "전문가" 탭의 모든 내용을 덮어쓰도록 하는 방법은 무엇입니까? (cls 명령과 유사) 그렇지 않으면 이전 스크립트 실행과 현재 실행에서 인쇄 출력 이 끝난 위치를 파악하기 어려울 수 있습니다.

감사해요!!

 
ns_k :

안녕하세요!

스크립트가 시작될 때 "전문가" 탭의 모든 내용을 덮어쓰도록 하는 방법은 무엇입니까? (cls 명령과 유사) 그렇지 않으면 이전 스크립트 실행과 현재 실행에서 인쇄 출력이 끝난 위치를 파악하기 어려울 수 있습니다.

감사해요!!

그리고 deinit 스크립트에 라인을 추가합니다.

인쇄 ("================================================================================================================================================================

사유: