당신이 말하는 모든 것이 맞습니다. 그리고 한 번에 정착한 OCL(그리고 조금 있다가 갑자기 부활)과 100번이나 논의되었다는 사실에 대해 - 상담원에게 정보 전달과 최적화된 매개변수의 수에서 "현장의 협소함"에 대해.
이미 필요한 기능(MQL5를 사용하여 강조) MT5를 보충하고 동시에 돈을 벌기 위해(그리고 지금 대출과 모기지가 없는 사람) 아이디어가 돌고 있는 것처럼 보이지만 - 절대 안돼.
1. 최적화된 매개변수의 수에 대한 제한.
2. 단일 기준 최적화(새로운 단어 형성에 대해 죄송합니다)
3. 모래 진화 과정을 제어할 수 없음.
이것은 개발자에 대한 비난이 결코 아닙니다. 오히려 이것은 MQL5 프로그램 개발자들의 생각이 날아가는 공간입니다! 그러나 주제의 이름으로 표시되는 병목 현상이 다시 있습니다. 양방향 전송의 기회가 있으면 문제가 해결됩니다. 위의 세 가지 사항을 실천할 필요는 없습니다. 모든 것이 저절로 성장할 것입니다.
이미 dll에 대한 액세스에 대해서만 질문이 있는 경우 전체 작업을 알릴 수 있습니까? Renat이 당신의 시야를 느낄 수 있도록... 그리고 아마도 MK가 해결책을 제안할 것입니다.
글쎄, "준비"로 .... 아니, 준비가되지 않았습니다. 나는 항상 그것을 가지고 있습니다 - 그것은 오랫동안 방황하고 빨리 주장합니다.
네, 완료했습니다. 95%로.
작업(자세한 내용은 생략):
1. 차트의 "서버"와 에이전트의 "클라이언트" 간의 양방향 정보 교환을 위한 정기적인 메커니즘이 필요합니다(먼저 필요)
2. 차트에서 "서버"로 일반 테스터/최적화 프로그램을 실행할 수 있는 일반 메커니즘이 필요합니다(필수지만 중요하지는 않음).
그게 다야.
호라이즌:
1. 최적화 관리를 위해 MQ 스크립팅 언어를 개발할 필요가 없습니다(사용자가 한 번 요청).
2. 클라우드는 무역과 관련된 작업뿐만 아니라(지금보다 훨씬 더 많은 청중을 대상으로 함) 작업에 사용될 것입니다.
3. opt.parameters의 수를 제한하기 위해 표준 GA와 싸울 필요가 없습니다.
4...
더 이상 나열할 수 없습니다.
영형! 추가하는 것을 잊었습니다. 테스터의 상태에서 만들어진 시장 환경은 많은 가치가 있습니다. 집에서 만든 테스터(카운터)가 아무리 정교해도 성능과 테스트 품질 면에서 일반 테스터에 근접할 수는 없습니다. 고려해야 할 사항이 많이 있습니다. 스프레드와 스왑, 그리고... 그리고 각 작업에 대한 운율을 편집하는 것은 원숭이의 일입니다. 일반 테스터/옵티마이저를 사용하고 싶습니다.
2. dll(win api)을 호출하는 코드 부분을 라이브러리로 옮기고 코드베이스에 넣습니다. 소스 코드에서도 가능합니다.
결론은 제품에서 FileMapping을 사용해야 하며, 그것 없이는 방법이 없다는 것입니다.
여러분, 그렇게 하는 것이 아닙니다. MQ 내에서 제품을 만드는 방법에 대해 생각해 보십시오. MQL 하나의 수단으로 만드는 것이 근본적으로 불가능하다면 그것은 시장을 위한 제품이 아니며 그 안에 설 자리도 없다. MetaTrader 생태계와 투명하게 통합되어 간단하고 명확한 결정을 내리십시오. 일반 MQ 통합 환경과 달리 '자신만의 길'을 가는 제품은 아직 미래가 없고 미래도 없다.
A. 바로 그 순간을 topikstarter에게 말해야 한다고 생각합니다. 뜨거운 주제.
간단히 말해서. 우리는 에이전트의 올빼미(지금까지는 로컬이지만 MQ를 고정하면 사용자는 원격 항목을 요청함)와 차트의 올빼미 간의 정보 교환을 위한 양방향 메커니즘이 필요하다고 강조합니다.
Horizons - 클라우드와 OCL 및 mql5를 시작하는 것과 비슷합니다.
궁금한 마음에 더욱 따뜻해지는 기회를 드리겠습니다. 전문가 전문가용 플러그인을 사용할 수 있는 가능성을 발명하기 위해 게에 대해 별도의 인사와 존경을 표합니다 .
Horizons - 클라우드와 OCL 및 mql5를 시작하는 것과 비슷합니다.
앤드류, 준비됐어? 어떤 구현 단계에서?
이미 dll에 대한 액세스에 대해서만 질문이 있는 경우 전체 작업을 알릴 수 있습니까? Renat이 당신의 시야를 느낄 수 있도록... 그리고 아마도 MK가 해결책을 제안할 것입니다.
이미 dll에 대한 액세스에 대해서만 질문이 있는 경우 전체 작업을 알릴 수 있습니까? Renat이 당신의 시야를 느낄 수 있도록... 그리고 아마도 MK가 해결책을 제안할 것입니다.
글쎄요, 재미있네요. OpenCL에서 그랬던 것처럼(지금까지 서비스용 OpenCL 문제로) 바닥으로 가라앉을 것입니다.
와우 같지만 실제로는 3.5명 외에는 아무도 필요로 하지 않습니다.
와우 같지만 실제로는 3.5명 외에는 아무도 필요로 하지 않습니다.
그래서 그것은 Horizons에 관한 것입니다.
잠재 고객이 너무 가깝다면(Joo는 프로젝트 를 밝은 색상으로 MK에 전달하려고 노력할 것입니다) 회의에 참석하여 이에 필요한 기능을 만들 것입니다.
그래서 그것은 Horizons에 관한 것입니다.
(주님은 프로젝트를 밝은 색으로 MC에게 전달하려고 노력할 것입니다.) 그들이 만나서 필요한 기능을 만들어 줄 수 있는 잠재 고객이 있다면 어떨까요?
Claude에서 GA를 슬립하기 위해 일부 통신 기능을 사용하여 간단합니다(100번 논의).
ZY 그러나 여기서 가장 연결된 기능의 지평은 더 넓을 수 있습니다.
ZY 그러나 여기서 가장 연결된 기능의 지평은 더 넓을 수 있습니다.
이것과 연설에 대해.
당신이 말하는 모든 것이 맞습니다. 그리고 한 번에 정착한 OCL(그리고 조금 있다가 갑자기 부활)과 100번이나 논의되었다는 사실에 대해 - 상담원에게 정보 전달과 최적화된 매개변수의 수에서 "현장의 협소함"에 대해.
이미 필요한 기능(MQL5를 사용하여 강조) MT5를 보충하고 동시에 돈을 벌기 위해(그리고 지금 대출과 모기지가 없는 사람) 아이디어가 돌고 있는 것처럼 보이지만 - 절대 안돼.
1. 최적화된 매개변수의 수에 대한 제한.
2. 단일 기준 최적화(새로운 단어 형성에 대해 죄송합니다)
3. 모래 진화 과정을 제어할 수 없음.
이것은 개발자에 대한 비난이 결코 아닙니다. 오히려 이것은 MQL5 프로그램 개발자들의 생각이 날아가는 공간입니다! 그러나 주제의 이름으로 표시되는 병목 현상이 다시 있습니다. 양방향 전송의 기회가 있으면 문제가 해결됩니다. 위의 세 가지 사항을 실천할 필요는 없습니다. 모든 것이 저절로 성장할 것입니다.
앤드류, 준비됐어? 어떤 구현 단계에서?
이미 dll에 대한 액세스에 대해서만 질문이 있는 경우 전체 작업을 알릴 수 있습니까? Renat이 당신의 시야를 느낄 수 있도록... 그리고 아마도 MK가 해결책을 제안할 것입니다.
글쎄, "준비"로 .... 아니, 준비가되지 않았습니다. 나는 항상 그것을 가지고 있습니다 - 그것은 오랫동안 방황하고 빨리 주장합니다.
네, 완료했습니다. 95%로.
작업(자세한 내용은 생략):
1. 차트의 "서버"와 에이전트의 "클라이언트" 간의 양방향 정보 교환을 위한 정기적인 메커니즘이 필요합니다(먼저 필요)
2. 차트에서 "서버"로 일반 테스터/최적화 프로그램을 실행할 수 있는 일반 메커니즘이 필요합니다(필수지만 중요하지는 않음).
그게 다야.
호라이즌:
1. 최적화 관리를 위해 MQ 스크립팅 언어를 개발할 필요가 없습니다(사용자가 한 번 요청).
2. 클라우드는 무역과 관련된 작업뿐만 아니라(지금보다 훨씬 더 많은 청중을 대상으로 함) 작업에 사용될 것입니다.
3. opt.parameters의 수를 제한하기 위해 표준 GA와 싸울 필요가 없습니다.
4...
더 이상 나열할 수 없습니다.
영형! 추가하는 것을 잊었습니다. 테스터의 상태에서 만들어진 시장 환경은 많은 가치가 있습니다. 집에서 만든 테스터(카운터)가 아무리 정교해도 성능과 테스트 품질 면에서 일반 테스터에 근접할 수는 없습니다. 고려해야 할 사항이 많이 있습니다. 스프레드와 스왑, 그리고... 그리고 각 작업에 대한 운율을 편집하는 것은 원숭이의 일입니다. 일반 테스터/옵티마이저를 사용하고 싶습니다.
따라서 MQL 파이프에 서버 모드를 추가하십시오. 그래서 가능합니까? 아니면 보안 문제도 있습니까?
모든 dll 호출은 시장에서 금지됩니다.
확인. 그리고 다음과 같이 하면:
1. 제품 자체를 시장에 내놓습니다.
2. dll(win api)을 호출하는 코드 부분을 라이브러리로 옮기고 코드베이스에 넣습니다. 소스 코드에서도 가능합니다.
결론은 제품에서 FileMapping을 사용해야 하며, 그것 없이는 방법이 없다는 것입니다.