시장 상황을 비역사적이라고 생각하는 입장에서 님의 의견에 동의하지 않겠습니다만... 이건 제 개인적인 생각입니다. 수익성 있는 주문의 경우 결정을 내리기 위해 더 높은 시간 프레임을 살펴보거나 약간의 롤백을 두고 더 높은 시간 프레임에 주문 작업을 계속하거나 단순히 잠재 고객이 없기 때문에 종료하는 것이 합리적입니다.
나는 당신이 시장의 역사를 고려해서는 안된다고 말하는 것이 아닙니다. 사실 이것이 고려되어야 하는 유일한 것입니다.
나는 주문 개시 날짜와 가격을 고려하는 것이 이치에 맞지 않는다고 (유해하다) 말한다. 그런 의미에서 마법은 환상을 유지하는 수단이에요 :) 반복하고 싶지 않아요 여기 보세요 .
그리고 전선에는 마술이 없을 것이라고 생각합니다. 얼마나 많은 불행한 프로그래머가 있는지 상상해보십시오. 일부 프로그램에서 매직 요청은 반드시 루프에 빠지고 서버를 로드합니다. 그리고 적어도 하나의 그러한 프로그램이 유통된다면 모든 기술의 칸이 있을 것입니다.
SK. (a) 작성: 얼마나 많은 불행한 프로그래머가 있는지 상상해보십시오. 일부 프로그램에서 CHANGE 마법에 대한 요청은 반드시 루프에 빠지고 서버를 로드합니다.
무슨 말인지 이해했습니다 ..... 그런 위험이 실제로 존재합니다. SL과 TP의 순열과 마찬가지로
이것들은 그들이 우리 없이도 당신에게하지 않을 일에 대한 세부 사항입니다. :) 그러나 .., 요청이나 응답도 예상됩니다 - 보는 방법. 예를 들어, 계정에 연결된 한 PC에서 SL 서버에 변경 사항은 계정에 연결된 모든 PC에 새 SL 값을 표시하여 반영됩니다.
우리는 Dobchinsky 및 Bobchinsky로서 귀하와 함께합니다.
밥친스키. .. "어!" 나는 표트르 이바노비치에게 말한다... 돕친스키. 아니요, Pyotr Ivanovich, "어!"라고 말한 사람은 나였습니다. 밥친스키. 먼저 당신이 말했고, 내가 말했어요. "어!" 표트르 이바노비치와 내가 말했다. 사라 토프 지방에 있습니까?
네... 사용자가 시스템을 망치기 위해 할 수 있는 모든 것을 그는 확실히 할 것입니다. 의식을 되찾지 않아도 :-)
불행히도 그 결과 많은 제품이 확인 및 재확인 기능, "바보"에 대한 인터페이스 보호 및 임의의 예측할 수 없는 사용자 작업으로 과부하가 걸립니다.
최근에 나는 공식 문서와 관련하여 "승인됨" 상태를 다소 특이한 방식으로 처리하는 고객과 통신해야 했습니다. 형식 문서는 승인되고 서명되지만 후속 재협상 및 재승인 없이 그 안의 모든 내용을 변경할 수 있습니다. 예를 들어 상상해보십시오. 은행에 지불 주문을 보내고 선의로 이행 한 다음 원본 문서를 수정 한 다음 은행에 와서 "지불 주문의 잘못된 실행"이라는 문구와 충돌합니다. "
시장 상황을 비역사적이라고 생각하는 입장에서 님의 의견에 동의하지 않겠습니다만... 이건 제 개인적인 생각입니다. 수익성 있는 주문의 경우 결정을 내리기 위해 더 높은 시간 프레임을 살펴보거나 약간의 롤백을 두고 더 높은 시간 프레임에 주문 작업을 계속하거나 단순히 잠재 고객이 없기 때문에 종료하는 것이 합리적입니다.
나는 당신이 시장의 역사를 고려해서는 안된다고 말하는 것이 아닙니다. 사실 이것이 고려되어야 하는 유일한 것입니다.
나는 주문 개시 날짜와 가격을 고려하는 것이 이치에 맞지 않는다고 (유해하다) 말한다. 그런 의미에서 마법은 환상을 유지하는 수단이에요 :) 반복하고 싶지 않아요 여기 보세요 .
그리고 전선에는 마술이 없을 것이라고 생각합니다. 얼마나 많은 불행한 프로그래머가 있는지 상상해보십시오. 일부 프로그램에서 매직 요청은 반드시 루프에 빠지고 서버를 로드합니다. 그리고 적어도 하나의 그러한 프로그램이 유통된다면 모든 기술의 칸이 있을 것입니다.
그리고 전선에는 마술이 없을 것이라고 생각합니다. 얼마나 많은 불행한 프로그래머가 있는지 상상해보십시오. 일부 프로그램에서 매직 요청은 반드시 루프에 빠지고 서버를 로드합니다. 그리고 적어도 하나의 그러한 프로그램이 유통된다면 모든 기술의 칸이 있을 것입니다.
제 자신을 잘못 표현한 것 같습니다. 서버와 별도로 요청을 제안하지 않았으며 이에 대한 OrdersTotal 및 OrderSelect가 있습니다. OrderModify를 호출할 때 재정의만 가정했습니다.
무슨 말인지 이해했습니다 ..... 그런 위험이 실제로 존재합니다. SL과 TP의 순열과 마찬가지로
무슨 말인지 이해했습니다 ..... 그런 위험이 실제로 존재합니다. SL과 TP의 순열과 마찬가지로
이것들은 그들이 우리 없이도 당신에게하지 않을 일에 대한 세부 사항입니다. :) 그러나 .., 요청이나 응답도 예상됩니다 - 보는 방법. 예를 들어, 계정에 연결된 한 PC에서 SL 서버에 변경 사항은 계정에 연결된 모든 PC에 새 SL 값을 표시하여 반영됩니다.
우리는 Dobchinsky 및 Bobchinsky로서 귀하와 함께합니다.
밥친스키. .. "어!" 나는 표트르 이바노비치에게 말한다...
돕친스키. 아니요, Pyotr Ivanovich, "어!"라고 말한 사람은 나였습니다.
밥친스키. 먼저 당신이 말했고, 내가 말했어요. "어!" 표트르 이바노비치와 내가 말했다.
사라 토프 지방에 있습니까?
네... 사용자가 시스템을 망치기 위해 할 수 있는 모든 것을 그는 확실히 할 것입니다. 의식을 되찾지 않아도 :-)
불행히도 그 결과 많은 제품이 확인 및 재확인 기능, "바보"에 대한 인터페이스 보호 및 임의의 예측할 수 없는 사용자 작업으로 과부하가 걸립니다.
최근에 나는 공식 문서와 관련하여 "승인됨" 상태를 다소 특이한 방식으로 처리하는 고객과 통신해야 했습니다. 형식 문서는 승인되고 서명되지만 후속 재협상 및 재승인 없이 그 안의 모든 내용을 변경할 수 있습니다. 예를 들어 상상해보십시오. 은행에 지불 주문을 보내고 선의로 이행 한 다음 원본 문서를 수정 한 다음 은행에 와서 "지불 주문의 잘못된 실행"이라는 문구와 충돌합니다. "
불행히도 그 결과 많은 제품이 확인 및 재확인 기능, "바보"에 대한 인터페이스 보호 및 임의의 예측할 수 없는 사용자 작업으로 과부하가 걸립니다.
네, 잘 알고 있습니다. 이 때문에 프로그램을 완전무결하게 만들기 위해 많은 시간을 투자해야 했기 때문에 작업이 반년이나 연장되었습니다. 사용자가 컨트롤 아이콘의 색상이나 유형을 변경한 다음 소유권을 주장할 수 있기 때문입니다.
그건 그렇고, 스레드의 주제에 . 프로그래밍 방식으로 조정 가능한 개체 속성이 필요합니다. 색상, 크기, 글꼴, 선택, 삭제 등의 변경을 허용/금지합니다.
예를 들어, 동일한 챔피언십에서 디버그된 전문가에게는 그래픽 인터페이스가 필요하지 않다는 것이 분명합니다.
새로운 틱이 도래했을 때 뿐만 아니라 다양한 방식으로 어드바이저(인디케이터, 스크립트)를 런칭할 수 있도록 해달라는 큰 요청
필요
아마도 이와 같이 3 가지 기능이 시작됩니다.
시작 0 {} // 틱으로 작동
Start 1 {} // 정시에 실행(매초, 분, 시 등 선택)
시작 2 {} // 예를 들어 외부 프로그램이 계산을 완료하고 이 프로그램의 계산 결과 파일에 있는 데이터가 업데이트된 경우와 같이 외부 이벤트에서 작동합니다.
미리 감사드립니다.
여기에 또 다른 방법이 있습니다. 사용자 지정 표시기 를 파일 시스템의 폴더에 있는 그룹으로 구성하는 기능을 제공하는 것이 유용할 것입니다. 그런 다음 한 폴더에 표시기 덤프가 있으면 어떻게 든 음란합니다 :-)
또한 지정된 값의 배수(예: 5 또는 10포인트)로 자동 변경되는 스케일 제한으로 고정 가격 스케일 (포인트/픽셀)을 설정할 수 있기를 바랍니다.