전문 프로그래머로서 "터미널"에서 바라는 것. MQL5에 대한 소망이 있는 또 다른 주제.
이것은 이미 건설적인 접근 방식이며, 이를 지원하는 것은 죄가 아닙니다.
그리고 나서 - 나는 그것을 좋아하지 않는다. 그러면 나는 그것을 좋아하지 않는다 :-)
분명히 그들은 MT의 대안을 찾지 못하고 개선에 기여하기로 결정 했습니까? :-)
이것은 이미 건설적인 접근 방식이며, 이를 지원하는 것은 죄가 아닙니다.
그리고 나서 - 나는 그것을 좋아하지 않는다. 그러면 나는 그것을 좋아하지 않는다 :-)
분명히 그들은 MT의 대안을 찾지 못하고 개선에 기여하기로 결정 했습니까? :-)
사람들이 말하는 방식이 이상해요... 가끔은 놀랍습니다.
벤츠의 도색 품질이 마음에 들지 않는다고 해서 DB 브랜드가 마음에 들지 않는 것은 아닙니다. 나는 항상 '모든 것'을 자기 것으로 하고, '모든 것'을 남의 것은 항상 싫어하는 '팬'이 아니다. 저는 팬이 아닙니다. 저는 프로그래머일 뿐입니다. 그리고 MT의 컴파일러 품질이 형편없다고 말할 수 있습니다. 이것이 컴파일러가 작성하는 방식입니다!!! 그래서 무엇? 그것은 무엇을 변경합니다. 텍스트 편집기는 일반적으로 2008년의 악몽과도 같습니다. 그래서 무엇. 내가 프로그래머로서 평가할 수 있는 것은 단지 나의 평가일 뿐입니다. _I_가 더 잘 쓸 것이기 때문입니다. 그러나 제품은 사소한 것이 아니라 주된 것으로 좋아하거나 싫어합니다.
그리고 이 아키텍처 아이디어를 제안한 사람들이 "API가 없고 모든 것이 자신의 것"이라는 사실. 마케팅 및 비즈니스 개념에서 100% 잘못되었습니다. 그리고 단순히 게으름 때문에 아무도 자신의 "복제본"을 만들지 않고 있습니다. 이 복제품은 조금 더 나아지겠지만 그렇게 될 것이며, 출시될 경우 단순히 시장을 분할할 것입니다. 게다가 누가 그것을 뱉을지는 아직 알려지지 않았습니다. 그들은 앉을 가지를 잘라냅니다. 그러나 이것은 제 개인적인 전문적인 의견일 뿐입니다. API를 제공하지 않음으로써 클론 생성을 장려합니다. 이것은 이해하는 것이 중요합니다. 그러나 이것이 내가 MT를 세계에서 가장 절름발이 제품으로 간주한다는 것을 의미하지는 않습니다. 거기에서 말해, 당신이 그것을 가져? 솔직히 말하면 더 좋은 제품을 봤다. 그러나 그것들은 모두 BROKERS를 위한 것입니다. 훨씬 낫다. 그러나 그들의 서버는 멀리 떨어져 있고 핑은 높습니다.
1. 차트를 만듭니다. 그것은 너무 좋지만 아마도 과잉입니다.
2. 모든 터미널에서와 같이 추가적인 수제 종소리와 휘파람 없이 메타스톡 및 오메가 파일로 내보낼 수 있어야 합니다. 그리고 외부 프로그램에서 터미널로 거래 명령을 보낼 수 있어야 합니다. 나는 클라이언트 측에서 전문가의 작업을 금지하거나 허용하는 브로커의 능력에 대해 침묵합니다. 내 겸손한 생각에 브로커는 단위 시간당 거래자의 거래 수만 평가하고 이 값을 기반으로 자신의 작업을 차단해야 합니다.
일반적으로 MProgrammer 를 지원합니다.
제 생각에는 MQ가 AutoTrading이라는 올바른 방향을 택했습니다. 그리고 내 생각에 미래는 자동 기계와 반자동 기계에 속합니다. 따라서 프로그래밍은 물론 오늘날과 같은 수준이어야 합니다. API - 이미 삐걱거리는 소리가 납니다. .. DOS 얼굴이 있는 경우 프로그램을 시장에 홍보하는 방법(어쨌든 이 과정을 진행합니다) :(
일반적으로 MProgrammer 를 지원합니다.
제 생각에는 MQ가 AutoTrading이라는 올바른 방향을 택했습니다. 그리고 내 생각에 미래는 자동 기계와 반자동 기계에 속합니다. 따라서 프로그래밍은 물론 오늘날과 같은 수준이어야 합니다. API - 이미 삐걱거리는 소리가 납니다. .. DOS 얼굴이 있는 경우 프로그램을 시장에 홍보하는 방법(어쨌든 이 과정을 진행합니다) :(
엠프로그래머가 표현한 좋은 생각
네, 물론 저는 본격적인 API를 원합니다!
통합이 훨씬 쉬울 것입니다!
하지만 여기서 API 제공을 꺼리는 개발자를 완벽하게 이해합니다...
자체 터미널을 생성하는 "마스터"를 생성하지 않도록 ... "DLL 세트를 사용하고 다른 것은 필요하지 않습니다."
결국, 실제로 API 형태로 수신 - 연결 및 주문 요청
많은 사람들이 자체 터미널이나 프로그램을 작성하기 시작할 것입니다 - 자동화된 거래를 위해 ... 터미널을 전혀 사용하지 않음
C++, VB, Delphi로 차트 그리기, 주문 관리 이것에 맞서 싸울 방법을 찾을 수 있습니다 ... API가없는 방법이 유감입니다
하지만 여기서 API 제공을 꺼리는 개발자를 완벽하게 이해합니다...
많은 사람들이 자체 터미널이나 프로그램을 작성하기 시작할 것입니다 - 자동화된 거래를 위해 ... 터미널을 전혀 사용하지 않음
거의 1000% 확신합니다 :))) 터미널을 전혀 만들 수 없다면 MT에서 온 사람들은 그저 행복할 것입니다. :)) 하지만 안타깝게도 서버만 판매하기는 어렵습니다. :))... 아쉽죠?
아마도 자동 거래는 이미 대부분 현실적일 것입니다. :)
모든 것을 하나의 병으로, 자신의 언어, 컴파일러, 편집기에서 모든 것을 수행하려고 노력하는 개발자를 이해합니다. 아마도 동일한 C와 비교하여 언어가 잘리는 것은 오류에 대한 두려움으로 인해 발생합니다. 예를 들어 모든 것이 원시적이지만 작동은 보장됩니다. 나는 이것이 거래 시스템에 대한 올바른 접근 방식이라고 생각합니다. 여기서 실수의 대가는 높습니다.
외부 프로그램과 통합할 수 있는 접근 방식을 개발해야 하는 것 같습니다. 어쨌든 나는 MQL4에서 진지한 것을 쓰지 않을 것이고, 그것이 비현실적이라고 생각합니다.
나는 모든 분석을 외부 프로그램에서 수행하고 어드바이저를 사용하여 통신할 것입니다. 그리고 지금, 이 연결로서, 내가 이해하는 바와 같이 외부 DLL에서 함수를 호출하는 것만 제안됩니다.
이러한 방법을 보완할 것을 제안합니다.
에디터에 대해. 좋은 편집자가 되는 것이 어렵다는 것을 이해합니다. 음, 외부 편집기를 사용할 수 있는 기회를 주어 파일이 외부에서 변경되면 모든 일반 편집기에서와 마찬가지로 다시 로드됩니다.
뭔가 싫은 스크리머 옆에는 항상 비명을 지르지 않고 그냥 하는 놈, (개 짖는 소리-캐러밴 간다.), 좋은 건지 나쁜 건지, 하지만 어쩔 수 없이 하는 실수를 바로잡고, 왜냐하면 당신도 알다시피 아무것도 하지 않는 사람만이 실수를 하지 않기 때문입니다. 많은 사람들이 - I_가 더 잘 썼을 것이라고 주장할 수 있지만 실제로는 일반적으로 가치 있는 것을 보여줄 수 없으며 모든 것이 말로만 있습니다.
> 그리고 이 아키텍처 아이디어를 제안한 사람들이 "API가 없고 그게 다야"라는 사실. 마케팅과 비즈니스 개념에서 100% 틀립니다.
이 진술로 판단할 때, 귀하는 자신도 마케터라고 생각하십니까? 말하자면 프로그래머-마케터? :-)
자신을 과대평가하시는 것 같아요 :-)
제품 자체에 관해서는 모두가 당신이 없어도 오랫동안 단점을 알고 있었고 개선을 위해 제안하고 있습니다.
그러나 참고: - "개선을 위한 제안"이며 맨손이 아니라 쓸모없는 비판입니다. 이것은 내가 이전 게시물에서 썼던 바로 그 내용입니다.
뭔가 싫은 스크리머 옆에는 항상 비명을 지르지 않고 그냥 하는 놈, (개 짖는 소리-캐러밴 간다.), 좋은 건지 나쁜 건지, 하지만 어쩔 수 없이 하는 실수를 바로잡고, 왜냐하면 당신도 알다시피 아무것도 하지 않는 사람만이 실수를 하지 않기 때문입니다. 많은 사람들이 - I_가 더 잘 썼을 것이라고 주장할 수 있지만 실제로는 일반적으로 가치 있는 것을 보여줄 수 없으며 모든 것이 말로만 있습니다.
+1 ))))) 아무것도하지 않는 사람들 만이 실수하지 않습니다
뭔가 싫은 스크리머 옆에는 항상 비명을 지르지 않고 그냥 하는 놈, (개 짖는 소리-캐러밴 간다.), 좋은 건지 나쁜 건지, 하지만 어쩔 수 없이 하는 실수를 바로잡고, 왜냐하면 당신도 알다시피 아무것도 하지 않는 사람만이 실수를 하지 않기 때문입니다. 많은 사람들이 - I_가 더 잘 썼을 것이라고 주장할 수 있지만 실제로는 일반적으로 가치 있는 것을 보여줄 수 없으며 모든 것이 말로만 있습니다.
> 그리고 이 아키텍처 아이디어를 제안한 사람들이 "API가 없고 그게 다야"라는 사실. 마케팅과 비즈니스 개념에서 100% 틀립니다.
이 진술로 판단할 때, 귀하는 자신도 마케터라고 생각하십니까? 말하자면 프로그래머-마케터? :-)
자신을 과대평가하시는 것 같아요 :-)
제품 자체에 관해서는 모두가 당신이 없어도 오랫동안 단점을 알고 있었고 개선을 위해 제안하고 있습니다.
그러나 참고: - "개선을 위한 제안"이며 맨손이 아니라 쓸모없는 비판입니다. 이것은 내가 이전 게시물에서 썼던 바로 그 내용입니다.
나는 당신의 사람에 대해 논의하지 않았다? 아니요. 그러니 '나 자신을 과대평가하든 말든' 이라는 말은 자제해주시길 부탁드립니다..
나는 이미 썼습니다 - 나는 나의 관점을 표현합니다. 그리고 당신이 변할 것이라는 사실에 의존하지 마십시오. 이것이 분명하기를 바랍니다.
내가 비즈니스 면에서 옳다는 것을 이해하지 못한다면 이것이 분명히 당신의 문제인 것 같습니다. 왜냐하면 제가 일반적으로 본질적으로 부인할 수 없는 진부한 것들을 말하고 있기 때문입니다.
그러므로 나는 당신이 나에 대한 평가를 당신 자신에게만 맡길 것을 제안합니다.
나는 메가 토픽인 "Wishs for MQL5"를 읽었지만 실례합니다. 이 스레드를 만들고 싶었을뿐입니다 ...
그래서 제가 새로운 시스템에서 보고 싶은 것의 본질, 정확히 본질, 바로 아이디어... 그리고 디테일의 바다가 아닌 ...
MT가 하는 일에 대한 자체 비전이 있고 이미 상당한 진전을 이뤘다는 것이 분명하며 "무엇" "필요한 것"에 대한 내 비전은 더 이상 이 버전에 반영되지 않지만 그럼에도 불구하고 나는 원했습니다. 정확히 말하려면 - "프로그래머가 필요로 하는 것." 프로그래머가 아닌 사람들도 이것을 필요로 할 것 같지만 단순히 그것에 대해 알지 못합니다.
그래서 - 현재 터미널의 아날로그인 코어를 보고 싶습니다. 그리고 차트를 그리는 프로그램을 만드는 능력. 표시기 버퍼 를 첨부할 수 있고 이 클래스가 창에 표시하는 관리되는 차트 클래스를 가정해 보겠습니다. 창에는 몇 가지 표준 버튼, 표준 속성 및 기타 표준 항목이 있어야 합니다. 그러나 그 창은 터미널의 하위 창이 아니라 무료였습니다. 그러나 나는 또한 터미널 하위 창으로 창을 가질 수 있기를 원합니다. 왜 필요합니까? 우선 "무료" 창을 통해 보다 유연하게 배치할 수 있습니다.
둘째, MT의 프로그래머에게 소스 코드 등의 메가 편집기 개발을 들이고 싶지 않습니다. 이것은 본질적으로 자전거의 발명품이기 때문입니다. 그리고 예를 들어 스튜디오를 사용합니다. 그러나 중요한 것은, 예를 들어 스튜디오에서 작성된 C#과 같은 프로그램은 차트 창에 차트를 표시할 수 있는 일종의 관리 클래스를 사용한다는 것입니다.
셋째, 거래를 위해 API를 제공하기를 꺼리는 경우 - 완전히 터미널 내부에 유지하고 외부 세계와의 데이터 교환은 일부 데이터를 통해서만 진행됩니다. 이러한 방식으로 늑대와 양 모두에게 먹이를줍니다. 가격 ... 글쎄, 당신은 그래프를 그리고 외부 프로그램의 과거 데이터를 가지고 있어야 할뿐만 아니라 전문적인 환경에서 이러한 프로그램을 만들어야합니다. 이제 데이터를 가질 수 있지만 원하는대로 직접 그리면 이것이 약한 작업이 아닙니다.
그게 다 한마디로...