동료. 어떤 개발 환경이 더 좋고, 어떤 코드가 더 빠르다는 논쟁은 무의미하다고 생각합니다. 이것은 모두 취향의 문제이며 해결해야 할 작업에 따라 다릅니다. 개발 환경에 관계없이 외부 응용 프로그램과 MT 도구 간의 상호 작용 문제가 여전히 있습니다. 가장 간단한 예를 살펴보겠습니다. 네이티브 dll에서 복잡한 수학 계산 을 위한 알고리즘을 구현했습니다. 필요한 매개변수가 MT 도구에서 이 라이브러리로 전송되고 계산이 시작되었으며 도구는 계산이 끝날 때까지 작업을 계속했습니다. 외부 응용 프로그램이 계산을 완료했으며 여기에서 간단한 질문이 발생합니다. 계산이 완료되었음을 MT에서 기기에 알리는 방법은 무엇입니까? 데이터 전송은 문제가 아니라 알림에 문제가 있습니다. 그리고 다시 말하지만, 이 질문은 개발 환경에 의존하지 않습니다!
몇 가지 옵션이 표시됩니다.
1. 예를 들어 PostMessage를 사용하여 외부 프로그램에서 OnChartEvent 메서드를 호출하는 기능
2. Renat이 제안한 MT 도구에 새로운 메소드 추가: 이벤트의 유형 또는 일반적으로 전송되는 데이터를 나타내는 OnExternal, 즉 이 메소드에서 데이터 자체를 반환할 수 있습니다.
3. Winsocket MT 도구에서 구현. 이것은 두 번째 포인트와 유사하지만 MT의 도구가 특정 포트에 연결하여 데이터를 수신하도록 허용합니다.
첫 번째 및 두 번째 지점이 한 기계 수준에서 상호 작용을 허용하는 경우 세 번째 지점은 MT 도구에 대한 네트워크 상호 작용을 제공합니다.
그러나 여기서 다시 문제가 발생합니다. 소켓에 데이터가 있는지 지속적으로 직접 확인해야 합니다.
즉, 모든 경우에 콜백 문제가 남아 해결되지 않습니다.
타이머 모니터링은 솔루션이 아니라 목발입니다. 예, 다른 옵션이 없으면 이것이 지금 결정하는 방법입니다.
개발자가 플랫폼 수준에서 이러한 문제에 대한 솔루션을 구현하면 터미널 API에 액세스할 필요가 없습니다. 결국 그는 좋은 삶에서가 아니라 MT와 생성되는 응용 프로그램 사이에 본격적인 상호 작용이 없기 때문에 묻습니다. 반복합니다. 이 문제는 외부 응용 프로그램에 대해 선택한 개발 환경에 관계없이 존재합니다.
Сокеты… Что вообще сейчас в нашем информационном мире может без них существовать? Впервые появившиеся в 1982 г. и практически не изменившиеся до настоящего времени, они исправно работают на нас каждую секунду. Это основа сети, нервные окончания нашей Matrix, в которой мы живем. Утром вы включили терминал MetaTrader, и он сразу создал сокеты и...
동료. 어떤 개발 환경이 더 좋고, 어떤 코드가 더 빠르다는 논쟁은 무의미하다고 생각합니다. 이것은 모두 취향의 문제이며 해결해야 할 작업에 따라 다릅니다. 개발 환경에 관계없이 외부 응용 프로그램과 MT 도구 간의 상호 작용 문제가 여전히 있습니다. 가장 간단한 예를 살펴보겠습니다. 네이티브 dll에서 복잡한 수학 계산 을 위한 알고리즘을 구현했습니다. 필요한 매개변수가 MT 도구에서 이 라이브러리로 전송되고 계산이 시작되었으며 도구는 계산이 끝날 때까지 작업을 계속했습니다. 외부 응용 프로그램이 계산을 완료했으며 여기에서 간단한 질문이 발생합니다. 계산이 완료되었음을 MT에서 기기에 알리는 방법은 무엇입니까? 데이터 전송은 문제가 아니라 알림에 문제가 있습니다. 그리고 다시 말하지만, 이 질문은 개발 환경에 의존하지 않습니다!
몇 가지 옵션이 표시됩니다.
1. 예를 들어 PostMessage를 사용하여 외부 프로그램에서 OnChartEvent 메서드를 호출하는 기능
2. Renat에서 제안한 대로 MT 도구에 새로운 방법 추가: 이벤트의 유형 또는 일반적으로 전송되는 데이터를 나타내는 OnExternal, 즉 이 방법에서 데이터 자체를 반환할 수 있습니다.
3. Winsocket MT 도구에서 구현. 이것은 두 번째 포인트와 유사하지만 MT의 도구가 특정 포트에 연결하여 데이터를 수신하도록 허용합니다.
첫 번째 및 두 번째 지점이 한 기계 수준에서 상호 작용을 허용하는 경우 세 번째 지점은 MT 도구에 대한 네트워크 상호 작용을 제공합니다.
그러나 여기서 다시 문제가 발생합니다. 소켓에 데이터가 있는지 지속적으로 직접 확인해야 합니다.
즉, 모든 경우에 콜백 문제가 남아 해결되지 않습니다.
타이머 모니터링은 솔루션이 아니라 목발입니다. 예, 다른 옵션이 없으면 이것이 지금 결정하는 방법입니다.
개발자가 플랫폼 수준에서 이러한 문제에 대한 솔루션을 구현하면 터미널 API에 액세스할 필요가 없습니다. 결국 그는 좋은 삶에서가 아니라 MT와 생성되는 응용 프로그램 사이에 본격적인 상호 작용이 없기 때문에 묻습니다. 반복합니다. 이 문제는 외부 응용 프로그램에 대해 선택한 개발 환경에 관계없이 존재합니다.
모든 사람이 이것을 아는 것은 아니지만 모니터링 및 폴링에 대해 추가하겠습니다. 각 폴링에서 DLL을 가져오지 않기 위해 int[]를 사용하여 플래그를 "공유"할 수 있습니다. DLL 내부에서 모든 액세스는 __atomic__ 입니다. 원칙적으로 이것은 작동하고 리소스 측면에서 상당히 경제적이지만 MQL 측면에서 증감/감소도 원자적이며 옵티마이저가 값에 대해 가정하지 않는다는 사실에 의존해야 합니다.
int flags[1]={0}; // когда DLL досчитает она инкрементит флаг handle=InitDLL(flags); // ... // опрос типично выглядит так: while ( flags[0] ) // проверить один int это очень быстро { flags[0]--; ReadDataFromDLL(handle); }
그것이 절대적으로 더 예쁘다는 것은 원자(휘발성?) 속성과 이에 상응하는 프리미티브 세트로 충분할 것입니다. 내 생각에 이것은 시스템에 새로운 메커니즘을 포함하는 것보다 쉽고 기존 DLL 프로토콜을 변경하지 않습니다.
모든 사람이 이것을 아는 것은 아니지만 모니터링 및 폴링에 대해 추가하겠습니다. 각 폴링에서 DLL을 가져오지 않기 위해 int[]를 사용하여 플래그를 "공유"할 수 있습니다. DLL 내부에서 모든 액세스는 __atomic__ 입니다. 원칙적으로 이것은 작동하고 리소스 측면에서 상당히 경제적이지만 MQL 측면에서 증감/감소도 원자적이며 옵티마이저가 값에 대해 가정하지 않는다는 사실에 의존해야 합니다.
int flags[1]={0}; // когда DLL досчитает она инкрементит флаг handle=InitDLL(flags); // ... // опрос типично выглядит так: while ( flags[0] ) // проверить один int это очень быстро { flags[0]--; ReadDataFromDLL(handle); }
그것이 완전히 더 예쁘다는 것은 원자(휘발성?) 속성과 해당하는 기본 요소 집합으로 충분합니다. 내 생각에 이것은 시스템에 새로운 메커니즘을 포함하는 것보다 쉽고 기존 DLL 프로토콜을 변경하지 않습니다.
Maxim, 이 솔루션이 더 나은 이유는 무엇입니까? 결국 플래그의 상태를 폴링하기 위해서는 MQL에서도 주기적으로 체크가 필요하다. 파헤치지 않은 곳에서 데이터를 수집할 때임을 이해하기 위해 무언가의 상태 변화를 지속적으로 모니터링해야 합니다. 그리고 이 조각은 dll 자체에 저장하고 거기에서 확인할 수 있습니다. 귀하의 예에는 플래그 상태를 반환하는 암시적 dll 호출이 있습니다.
사실, 방법이 없습니다. 외부 프로그램과 MT의 프로그램은 차이가 없습니다. 가능성은 동일하고 상호 작용은 동일합니다.
전혀 설명하지 않았습니다. 명확하게 대답하십시오 plz - 어떻게 MT에서 * 샤프의 패널에서 데이터를 얻습니까?
타이머 폴링으로 메모리 매핑을 통해 피드백을 했습니다. 패널은 다른 설정과 느린 계산 결과만 전송했습니다.
무지는 자신감을 줍니다. 그러나 지식은 슬픔을 배가시킵니다.
좋습니다. 그러면 패널을 분리하여 메모리 매핑을 통해 연결하겠습니다. 예전에는 2000년대 후반에 파이프로 했는데 그게 맘에 안들었어요.
직접 연결해 보았지만 별 공포감은 느끼지 못했습니다.
터미널에 COM 인터페이스 - 일반적으로 krutoten이 있습니다. 빠르게 구식이지만.
그것은 실시간과 맞지 않습니다. :-(
COM 인터페이스 대부분 그렇지 않을 것입니다.
하지만 왜 구식인지 알 수 있습니까?
또한 빠릅니다.
COM 인터페이스 대부분 그렇지 않을 것입니다.
하지만 왜 구식인지 알 수 있습니까?
또한 빠릅니다.
자체 통신 인터페이스가 있는 .net으로 대체되었습니다.
자체 통신 인터페이스가 있는 .net으로 대체되었습니다.
COM에서 일부 GUID는 가치가 있습니다.
MS는 여전히 사용하지 않는 GUID를 10개에 1달러에 다시 구매합니다. 옛날부터 뒹굴뒹굴 하다보면 돈 많이 벌 수 있어요!
COM에서 일부 GUID는 가치가 있습니다.
MS는 여전히 사용하지 않은 GUID를 10개에 1달러에 다시 구매합니다. 옛날부터 뒹굴뒹굴 하다보면 돈 많이 벌 수 있어요!
나는 가득 찼습니다 :-) 나는 줄 수 있습니다 - 당신은 MS에서 그것을 던질 수 있습니다
066cd265-e2fe-468e-9492-4228e9759e38
8e1040ba-dc3e-4e2a-9208-e3ea8da9ad05
03dcd7cd-4b9b-4ff7-bff0-e0839a0f9d8b
d69f2c8c-de51-4557-8188-4ebb870da7da
a79a8cc6-f785-4268-bc4e-2deda0f1ecd0
f4f59f52-1da8-4f74-a71e-9aec1992674d
85608797-6015-456d-af64-ad7890120372
9289991a-e287-47fb-b595-6d719c1b7dbd
63d3b953-3229-4045-a82a-fc9e7795bb01
c75c4e0f-8320-42df-943c-9aada54b60eb
무엇이든 저에게 연락하십시오. 아마도 더 많이 찾을 수 있을 것입니다.
동료. 어떤 개발 환경이 더 좋고, 어떤 코드가 더 빠르다는 논쟁은 무의미하다고 생각합니다. 이것은 모두 취향의 문제이며 해결해야 할 작업에 따라 다릅니다. 개발 환경에 관계없이 외부 응용 프로그램과 MT 도구 간의 상호 작용 문제가 여전히 있습니다. 가장 간단한 예를 살펴보겠습니다. 네이티브 dll에서 복잡한 수학 계산 을 위한 알고리즘을 구현했습니다. 필요한 매개변수가 MT 도구에서 이 라이브러리로 전송되고 계산이 시작되었으며 도구는 계산이 끝날 때까지 작업을 계속했습니다. 외부 응용 프로그램이 계산을 완료했으며 여기에서 간단한 질문이 발생합니다. 계산이 완료되었음을 MT에서 기기에 알리는 방법은 무엇입니까? 데이터 전송은 문제가 아니라 알림에 문제가 있습니다. 그리고 다시 말하지만, 이 질문은 개발 환경에 의존하지 않습니다!
몇 가지 옵션이 표시됩니다.
1. 예를 들어 PostMessage를 사용하여 외부 프로그램에서 OnChartEvent 메서드를 호출하는 기능
2. Renat이 제안한 MT 도구에 새로운 메소드 추가: 이벤트의 유형 또는 일반적으로 전송되는 데이터를 나타내는 OnExternal, 즉 이 메소드에서 데이터 자체를 반환할 수 있습니다.
3. Winsocket MT 도구에서 구현. 이것은 두 번째 포인트와 유사하지만 MT의 도구가 특정 포트에 연결하여 데이터를 수신하도록 허용합니다.
첫 번째 및 두 번째 지점이 한 기계 수준에서 상호 작용을 허용하는 경우 세 번째 지점은 MT 도구에 대한 네트워크 상호 작용을 제공합니다.
다음은 예입니다. https://www.mql5.com/ru/articles/2599
그러나 여기서 다시 문제가 발생합니다. 소켓에 데이터가 있는지 지속적으로 직접 확인해야 합니다.
즉, 모든 경우에 콜백 문제가 남아 해결되지 않습니다.
타이머 모니터링은 솔루션이 아니라 목발입니다. 예, 다른 옵션이 없으면 이것이 지금 결정하는 방법입니다.
개발자가 플랫폼 수준에서 이러한 문제에 대한 솔루션을 구현하면 터미널 API에 액세스할 필요가 없습니다. 결국 그는 좋은 삶에서가 아니라 MT와 생성되는 응용 프로그램 사이에 본격적인 상호 작용이 없기 때문에 묻습니다. 반복합니다. 이 문제는 외부 응용 프로그램에 대해 선택한 개발 환경에 관계없이 존재합니다.
넷 라이브러리 사용 가능성에 대한 정보))) https://www.mql5.com/ru/forum/13388
주제는 실제로 매우 오래되었습니다. 개발자 스스로가 문제없이 그물을 사용할 수 있다는 가능성을 발표 한 적이 있습니다. 그 이후로 많은 물이 다리 아래로 흘러 들었지만 문제는 해결되지 않은 채로 남아있었습니다 ...
또는 다음은 Renat 자신의 메시지입니다. https://www.mql5.com/en/forum/3153/page2#comment_298866
https://www.mql5.com/en/forum/3153/page2#comment_298892
동료. 어떤 개발 환경이 더 좋고, 어떤 코드가 더 빠르다는 논쟁은 무의미하다고 생각합니다. 이것은 모두 취향의 문제이며 해결해야 할 작업에 따라 다릅니다. 개발 환경에 관계없이 외부 응용 프로그램과 MT 도구 간의 상호 작용 문제가 여전히 있습니다. 가장 간단한 예를 살펴보겠습니다. 네이티브 dll에서 복잡한 수학 계산 을 위한 알고리즘을 구현했습니다. 필요한 매개변수가 MT 도구에서 이 라이브러리로 전송되고 계산이 시작되었으며 도구는 계산이 끝날 때까지 작업을 계속했습니다. 외부 응용 프로그램이 계산을 완료했으며 여기에서 간단한 질문이 발생합니다. 계산이 완료되었음을 MT에서 기기에 알리는 방법은 무엇입니까? 데이터 전송은 문제가 아니라 알림에 문제가 있습니다. 그리고 다시 말하지만, 이 질문은 개발 환경에 의존하지 않습니다!
몇 가지 옵션이 표시됩니다.
1. 예를 들어 PostMessage를 사용하여 외부 프로그램에서 OnChartEvent 메서드를 호출하는 기능
2. Renat에서 제안한 대로 MT 도구에 새로운 방법 추가: 이벤트의 유형 또는 일반적으로 전송되는 데이터를 나타내는 OnExternal, 즉 이 방법에서 데이터 자체를 반환할 수 있습니다.
3. Winsocket MT 도구에서 구현. 이것은 두 번째 포인트와 유사하지만 MT의 도구가 특정 포트에 연결하여 데이터를 수신하도록 허용합니다.
첫 번째 및 두 번째 지점이 한 기계 수준에서 상호 작용을 허용하는 경우 세 번째 지점은 MT 도구에 대한 네트워크 상호 작용을 제공합니다.
다음은 예입니다: https://www.mql5.com/en/articles/2599
그러나 여기서 다시 문제가 발생합니다. 소켓에 데이터가 있는지 지속적으로 직접 확인해야 합니다.
즉, 모든 경우에 콜백 문제가 남아 해결되지 않습니다.
타이머 모니터링은 솔루션이 아니라 목발입니다. 예, 다른 옵션이 없으면 이것이 지금 결정하는 방법입니다.
개발자가 플랫폼 수준에서 이러한 문제에 대한 솔루션을 구현하면 터미널 API에 액세스할 필요가 없습니다. 결국 그는 좋은 삶에서가 아니라 MT와 생성되는 응용 프로그램 사이에 본격적인 상호 작용이 없기 때문에 묻습니다. 반복합니다. 이 문제는 외부 응용 프로그램에 대해 선택한 개발 환경에 관계없이 존재합니다.
모든 사람이 이것을 아는 것은 아니지만 모니터링 및 폴링에 대해 추가하겠습니다. 각 폴링에서 DLL을 가져오지 않기 위해 int[]를 사용하여 플래그를 "공유"할 수 있습니다. DLL 내부에서 모든 액세스는 __atomic__ 입니다.
원칙적으로 이것은 작동하고 리소스 측면에서 상당히 경제적이지만 MQL 측면에서 증감/감소도 원자적이며 옵티마이저가 값에 대해 가정하지 않는다는 사실에 의존해야 합니다.
int flags[1]={0}; // когда DLL досчитает она инкрементит флаг
handle=InitDLL(flags); //
...
// опрос типично выглядит так:
while ( flags[0] ) // проверить один int это очень быстро
{
flags[0]--;
ReadDataFromDLL(handle);
}
그것이 절대적으로 더 예쁘다는 것은 원자(휘발성?) 속성과 이에 상응하는 프리미티브 세트로 충분할 것입니다. 내 생각에 이것은 시스템에 새로운 메커니즘을 포함하는 것보다 쉽고 기존 DLL 프로토콜을 변경하지 않습니다.
모든 사람이 이것을 아는 것은 아니지만 모니터링 및 폴링에 대해 추가하겠습니다. 각 폴링에서 DLL을 가져오지 않기 위해 int[]를 사용하여 플래그를 "공유"할 수 있습니다. DLL 내부에서 모든 액세스는 __atomic__ 입니다.
원칙적으로 이것은 작동하고 리소스 측면에서 상당히 경제적이지만 MQL 측면에서 증감/감소도 원자적이며 옵티마이저가 값에 대해 가정하지 않는다는 사실에 의존해야 합니다.
int flags[1]={0}; // когда DLL досчитает она инкрементит флаг
handle=InitDLL(flags); //
...
// опрос типично выглядит так:
while ( flags[0] ) // проверить один int это очень быстро
{
flags[0]--;
ReadDataFromDLL(handle);
}
그것이 완전히 더 예쁘다는 것은 원자(휘발성?) 속성과 해당하는 기본 요소 집합으로 충분합니다. 내 생각에 이것은 시스템에 새로운 메커니즘을 포함하는 것보다 쉽고 기존 DLL 프로토콜을 변경하지 않습니다.
Maxim, 이 솔루션이 더 나은 이유는 무엇입니까? 결국 플래그의 상태를 폴링하기 위해서는 MQL에서도 주기적으로 체크가 필요하다. 파헤치지 않은 곳에서 데이터를 수집할 때임을 이해하기 위해 무언가의 상태 변화를 지속적으로 모니터링해야 합니다. 그리고 이 조각은 dll 자체에 저장하고 거기에서 확인할 수 있습니다. 귀하의 예에는 플래그 상태를 반환하는 암시적 dll 호출이 있습니다.