전화와 노트북은 분명히 올바른 결정입니다. 논의조차 되지 않고 있다. 누군가가 무언가를 하려고 했을 수도 있지만 .... 운명은 아닌 것 같아 흥미로웠습니다.
기본적으로 놀라운 결정이 있으며 이러한 경우에만 해당되는 것은 아닙니다. 거래 서버에서 직접 웹 서버를 만드십시오 . https를 통한 권한 부여(개발자가 새로운 것을 생각해내지 않도록). 페이지에 들어가면 계정 상태(잔액, 이익 ...)와 미결 주문 목록(티켓 기호 로트 정지 이익 획득)이 표시됩니다. + 텍스트 입력 필드와 제출 버튼. 필드 위에 약간의 힌트:
업데이트
SYMBOL LOT STOP TAKE 매수 [SLIPAGE]
SYMBOL LOT STOP TAKE 매도 [SLIPAGE]
새로운 정류장 TICKET STOP
새로운 테이크 티켓 테이크
닫기 주문 번호
모든 주문 닫기
옵션 6에서 숫자 목록을 지정할 수 있습니다(6 1234 65433 2345).
그리고 휴대폰에서나 가까운 인터넷 카페나 게임방에서라도 이 7점만 있으면 뭐든지 할 수 있다. 그러나 그들은 그것을하지 않을 것입니다 .... 4 일이나 5 일에도 :(((
그리고 맞아. 이 작업을 수행하려면 서버 API 메타카에서 - 그냥 침을 뱉으세요. DC만이 일반적으로 귀찮게 하기에는 너무 게으르다 - 좋은 90년대와 같이 전화 거래:)
일괄 주문 마감에 관해서. 명백한 이유로 그러한 기능은 단순히 존재할 수 없습니다. 첫째, 오류보고가 어렵습니다(10개의 주문 중 8개가 마감되었으며 가격과 다른 슬리피지/편차가 있음). OFF QUOTES는 각각 2개씩 왔습니다. 어떻게 처리합니까? 또한 한 클라이언트의 요청 대기열은 단 하나뿐입니다. 분명한 이유가 있습니다(예: 마진 요구 사항 확인 ). 따라서 시간 비용 측면에서 주문을 순차적으로 마감하는 것과 같습니다.
문제는 사실 손가락에서 나옵니다. 먼저 랩톱을 사용합니다(위에서 작성함). 둘째, VPS를 사용합니다. 셋째, 전화를 통해 인터넷으로 이동합니다(집선이 끊어진 경우). 문제를 최소화하십시오.
맨 처음에 저는 "대답은 아니오입니다. 하지만 당신은 절대 모릅니다 ...."라고 썼습니다. 희망은 대담했습니다. 예를 들어, 스크립트에서 표시기를 강제로 다시 그릴 수는 없지만 차트에 눈금을 보내면 표시기가 다시 그려집니다. 여기도 누군가가 발견한 문서화되지 않은 무언가가 있을 거라고 생각했어
맨 처음에 저는 "대답은 아니오입니다. 하지만 당신은 절대 모릅니다 ...."라고 썼습니다. 희망은 대담했습니다. 예를 들어, 스크립트에서 표시기를 강제로 다시 그릴 수는 없지만 차트에 눈금을 보내면 표시기가 다시 그려집니다. 여기도 누군가가 발견한 문서화되지 않은 무언가가 있을 거라고 생각했어
전화와 노트북은 분명히 올바른 결정입니다. 논의조차 되지 않고 있다. 누군가가 무언가를 하려고 했을 수도 있지만 .... 운명은 아닌 것 같아 흥미로웠습니다.
기본적으로 놀라운 결정이 있으며 이러한 경우에만 해당되는 것은 아닙니다. 거래 서버에서 직접 웹 서버를 만드십시오 . https를 통한 권한 부여(개발자가 새로운 것을 생각해내지 않도록). 페이지에 들어가면 계정 상태(잔액, 이익 ...)와 미결 주문 목록(티켓 기호 로트 정지 이익 획득)이 표시됩니다. + 텍스트 입력 필드와 제출 버튼. 필드 위에 약간의 힌트:
옵션 6에서 숫자 목록을 지정할 수 있습니다(6 1234 65433 2345).
그리고 휴대폰에서나 가까운 인터넷 카페나 게임방에서라도 이 7점만 있으면 뭐든지 할 수 있다. 그러나 그들은 그것을하지 않을 것입니다 .... 4 일이나 5 일에도 :(((
그리고 맞아. 이 작업을 수행하려면 서버 API 메타카에서 - 그냥 침을 뱉으세요. DC만이 일반적으로 귀찮게 하기에는 너무 게으르다 - 좋은 90년대와 같이 전화 거래:)
일괄 주문 마감에 관해서. 명백한 이유로 그러한 기능은 단순히 존재할 수 없습니다. 첫째, 오류보고가 어렵습니다(10개의 주문 중 8개가 마감되었으며 가격과 다른 슬리피지/편차가 있음). OFF QUOTES는 각각 2개씩 왔습니다. 어떻게 처리합니까? 또한 한 클라이언트의 요청 대기열은 단 하나뿐입니다. 분명한 이유가 있습니다(예: 마진 요구 사항 확인 ). 따라서 시간 비용 측면에서 주문을 순차적으로 마감하는 것과 같습니다.
문제는 사실 손가락에서 나옵니다. 먼저 랩톱을 사용합니다(위에서 작성함). 둘째, VPS를 사용합니다. 셋째, 전화를 통해 인터넷으로 이동합니다(집선이 끊어진 경우). 문제를 최소화하십시오.
...
문제는 사실 손가락에서 나옵니다. 먼저... 문제를 최소화하십시오.
네, 알겠습니다 ;)
맨 처음에 저는 "대답은 아니오입니다. 하지만 당신은 절대 모릅니다 ...."라고 썼습니다. 희망은 대담했습니다. 예를 들어, 스크립트에서 표시기를 강제로 다시 그릴 수는 없지만 차트에 눈금을 보내면 표시기가 다시 그려집니다. 여기도 누군가가 발견한 문서화되지 않은 무언가가 있을 거라고 생각했어
네, 알겠습니다 ;)
맨 처음에 저는 "대답은 아니오입니다. 하지만 당신은 절대 모릅니다 ...."라고 썼습니다. 희망은 대담했습니다. 예를 들어, 스크립트에서 표시기를 강제로 다시 그릴 수는 없지만 차트에 눈금을 보내면 표시기가 다시 그려집니다. 여기도 누군가가 발견한 문서화되지 않은 무언가가 있을 거라고 생각했어
따라서 간단할 수 없습니다.) 서버 논리에 대해 참조하십시오.
ForexTools :
그러나 "휴식 시간 시뮬레이션"에도 시간이 걸리며 분명히(예: 동일한 계정에 다시 로그인) 주문을 종료하기 위해 정상적인 응답을 기다리는 것보다 시간이 덜 걸립니다.
따라서 간단할 수 없습니다.) 서버 논리에 대해 참조하십시오.
나는 이상한 것을 많이 원한다. 프로그래머는 기존 수단을 포함하여 실제적인 방법으로 문제를 해결하기 위해 노력해야 하며 종소리와 휘파람으로 새로운 문제를 만들지 않아야 합니다.
그것을 원칙으로 삼으십시오.
당신은 아마도 프로그래머가 아닐 것입니다 :) . 가끔은 이런 식으로 두뇌를 확장하고 싶을 때가 있습니다.
아니요, 방금 몇 가지 슈퍼 시스템을 구축하고 진실을 배웠습니다. 하나의 특정 프로그램 프레임워크 내에서만이 아니라 복잡한 애플리케이션에서 모든 것을 살펴봐야 합니다. 모두가 최종 시스템에 참여합니다: 개발자, 사용자 및 유지 관리자.
MT 개발자들이 혁신에 그렇게 반대하는 것도 당연합니다. 모든 것을 구현하려고 하면 모든 것이 무너지기 시작할 것입니다. 중간 지점이 있어야 합니다.
하지만 왜? 누가 서버에 "배치 로직"을 넣는 것을 방해합니까? 패키지의 각 위치에 대해 명령 목록(list \ package)을 받았습니다. 반환 코드 를 배열에 반환했습니다. .... 원할 것입니다.)
엔티티를 불필요하게 생성하는 이유는...
그것이 실제로 MQL을 방해하지 않는 것입니다. 일종의 스레드 모델입니다. 그리고 코드 최적화 . 그러나 이것은 별개의 문제입니다.
아마도 누군가 8월에 상트페테르부르크에 정전이 있었다는 소식을 들었을 것입니다. 2시간 동안 전기도 없고 물도 없고 라디오 방송국도 작동하지 않고 인터넷도 TV도 유선전화도 작동하지 않았고
이동통신은 이론상 비상권력을 가지고 있었지만 약간의 패닉으로 모두가 전화를 걸었다. 이러한 상황에서 UPS는 쓸모가 없으며 실제로 전화도 마찬가지입니다. 그때 떠오른 유일한 것은 유지하는 것이 었습니다.
vps의 또 다른 터미널 , 그리고 이것이 가능한지 여부와 방법을 모르겠습니다. vps의 별도 소프트웨어는 주 컴퓨터에서 인터넷의 존재를 모니터링해야 하며, "가입자가 응답하지 않는" 경우 스크립트를 실행하여 모든 포지션을 닫습니다.
그러나 그들은 빛을 주었다
일반적으로 의미의 법칙에 따르면 물론 많은 것을 잃을 수 있습니다.