2009-05-25 3 views
6

서로 통신 (데이터 교환 및 작업 시작)하기 위해 몇 가지 관련 응용 프로그램이 필요합니다. 요구 사항은 패키지가없고 소켓이 없습니다. 그래서 나는 파이프, WM_CopyData (Skype처럼)와 명령 매개 변수를 남겨 두었다고 생각합니다. 최선의 관행은 무엇입니까?소켓없이 델파이에서 애플리케이션 데이터 교환을 수행하는 가장 좋은 방법은 무엇입니까?

+0

명명 된 파이프 또는 WM_CopyData를 선택한 경우 REMObjects SDK로 이동하므로 응답하지 마십시오. 감사. – Mihaela

+0

당신은 기술을 찾고있는 디자인 패턴을 찾고 있지 않습니다. –

+0

네 말이 맞아. 디자인 패턴에 대해 생각하고 있었지만 제 질문은 기술에만 집중되었습니다. 디자인 패턴에는 이미 선택된 기술과 구현이 포함됩니다. 그것을 고쳐 주셔서 감사합니다. – Mihaela

답변

5

아마도 두 가지 옵션이 있습니다. 당신이 이미 가지고있는 것 이상의

:
DDE
메모리 매핑 된 파일 (MMF)
메일 슬롯

나는 아마 파이프 또는 MMF 중 하나와 함께 갈 것입니다.

다운로드 할 수있는 무료 MMF 구성 요소가 두 개 있습니다. Deborah Pate에는 사용할 수있는 프리웨어 클래스 세트가 있습니다. MapFiles.zip

Torry's 사이트의 MailSlots를 확인하십시오.

최종 해결책은 선택한 옵션을 결정하는 데이터 전송의 양, 크기 및 빈도에 따라 달라질 수 있습니다.

4

이 상황에서 COM을 사용하는 것이 좋습니다. (주의 : COM +가 아니라 COM, COM이 아니라 COM, COM이 아닌 COM, COM이 아닌).

Delphi 7 (또는 그 이전 버전은 확실하지 않습니다.)이므로 프로젝트에 유형 라이브러리를 추가하면됩니다 , 및 자동화 개체.

델파이 (유형 라이브러리 편집기에는 필요한 모든 것이 있고 코드를 업데이트하고 COM 내부 및 등록은 ComServ 유닛에서 제공됨)와 델파이 밖에서는 매우 광범위하게 지원됩니다. C++ 프로젝트, VBA, oldskool ASP ...를 사용하는 Word 및 Excel 문서 등 모든 종류의 응용 프로그램과 상호 작용하는 여러 프로젝트에서).

단점은 응용 프로그램을 시작할 때 보통 CoInitialize(nil);이라는 스레드 문제 일 수 있습니다. 더 복잡한 응용 프로그램에서는 '스레드 스레딩'에 대해 생각하거나 자유 스레드를 사용하고 자신의 잠금을 수행해야합니다. . (경우에 따라 이미 수행 한 적이 있습니다.)

+0

COM을 사용하는 모든 스레드에서 CoInitialize() 및 CoUninitialize()를 호출해야합니다. – mghie

+0

COM을 사용하지 않는 것이 좋습니다. – Mihaela

+0

간단히 말해서 COM 객체의 간단한 생성은 Delphi 3 이후부터 가능합니다. –

0

COM을 사용하지 마십시오. 오버 헤드 (변형)가 너무 많으며 .dll 또는 .exe를 등록해야합니다 (이상한 설치 + 업데이트 문제가 많이 발생합니다).).

나는 MMF로 가야하는데, 나는 이것을 Windows Services와의 통신에 사용한다. 나는 다음과 같은 TGpMessageQueueReader와 작가는이를 위해 사용 http://17slon.com/gp/gp/gpsync.htm

+0

이것을 이점으로 봅니다 : 일반적인 자동화 객체에서는 ComServ 핸들이 자동으로 등록되며 원하는 경우 TAutoObjectFactory의 파생 객체를 사용할 수 있습니다 , 당신은 UpdateRegistry 메소드에 추가 할 수 있습니다. (나는이 문제를 언급하기 위해 나의 대답을 편집했다.) –

+0

또한 BSTR (코드에서 WideString과 잘 어울리는)과 네이티브 형식의 숫자 값을 사용한다. 그리고 변종에 문제가 없다. (어쨌든 OleVariants와 관련된 문제는 전혀 없었습니다.) –

2

간단하게 구현할 수 먼지가 또 다른 대안은 정보를 전달하기 위해 데이터베이스를 사용하는 것입니다.

지나치게 우아하지 않고 많은 오버 헤드를 사용하지만 응용 프로그램이 이미 데이터를 인식하고있는 경우 (즉 데이터베이스를 일부만 포함하는 경우) 테이블 하나 또는 두 개를 사용하여 정보를 전달하는 것은 매우 쉽습니다.

2

간단한 파일을 사용할 수 있습니다. 한 쪽이 쓰고 다른 쪽은 읽습니다. 양방향 통신이 필요한 경우 각 방향에 하나씩 두 개의 파일 만 사용하십시오.

물론 이것은 실제로 고성능이 아닙니다.

+0

+1 파일을 통한 통신은 한 번에 매우 편리합니다. 그것은 서로 다른 운영 체제간에 통신 할 수있는 쉬운 방법이며, 모든 프로그래밍/스크립팅 언어가이를 지원합니다. 그리고 독자가 죽으면 정보가 손실되지 않는 몇 가지 방법 중 하나입니다. 날짜 + 시간이 포함 된 파일을 작성하면 원하는대로 대기열이나 스택처럼 작동 할 수 있습니다. 초당 수백 개의 메시지를 보내지 않는 한, 또는 1 마이크로 초가되면 계산이 훌륭합니다. –

0

이런 종류의 RemObjects가 좋은 점은 무엇입니까? Bri

1

명명 된 파이프, 데이터 교환을위한 또 다른 투표. Win32 파이프 API가 동기화/비동기, 바이트 스트림 대 메시지 패킷, 간단한 ReadFile/WriteFile 호출과 같은 유용한 옵션을 제공하기 때문에 mmap 파일보다 약간 더 좋아합니다. 모두 일 수 있습니다. mmap을 사용하면 ... 그러나 파이프는 이미 있습니다 ...

그리고 WM_CopyData의 옵션이 아닌 보안 속성을 사용하여 액세스를 제어 할 수 있습니다. 이 문제는 즉시 발생하지 않을 수도 있지만 앱 메시지를 보내는 사람을 신경 쓰지 않는다고해도 편리 할 수 ​​있습니다. 나에게 이것은 비스타가 등장했을 때 도움이되었고 갑자기 사용자 앱이 내 서비스와 별도로 실행되었다. 보안 속성을 수정하는 것이 다시 작동하도록하는 유일한 방법이었습니다.

"조치 시작"의 경우, 일부 명명 된 이벤트만큼 쉽게 벗어날 수 있으며 전혀 메시지를 보내지 않을 수도 있습니다. 이해 관계자들은 단순히 신호가 전달되기를 기다릴뿐입니다.

COM 기반 클라이언트를 특별히 지원하지 않으면 개인적으로 COM을 피할 것입니다.

0

데이터를 전달하려면 함수 등을 호출 한 다음 COM을 사용합니다. 그러나 호출이 많으면 COM의 속도가 느려집니다. 또한 작동하기 전에 응용 프로그램을 "xxx.exe/Regserver"로 등록해야 할 수도 있습니다.

관련 문제