Microsoft Access의 직렬 포트를 통해 연결된 바코드 스캐너와 통신해야합니다. 이전 버전의 Access에서는 더 이상 작동하지 않는 MSCOMM32.ocx 주위에 래퍼를 사용할 수있었습니다. RS232 인터페이스를 통해서만 지원되는 ACK/NACK을 사용해야하므로 RS232 인터페이스를 통해서만 지원되는 스캐너에 메시지를 보내야하므로 웨지 통신을 사용할 수 없습니다.Access 2007의 직렬 통신에 대한 권장 사항
Access 2007의 직렬 통신을 지원하는 컨트롤이 널리 보급되어 있습니까?
EDIT : 누구든지이 문제가 발생하면 최신 버전의 MSCOMM32.ocx (필자의 3/09 일자)는이 글을 쓰면서 여전히 잘 작동합니다. 작동하지 않는 MSCOMM32.ocx의 이전 버전입니다.
나는 대답에 대한 신뢰도를 보장 할 수 없습니다,하지만 난 토니 Toews이 신뢰할 수있는 사람이라고 말할 수 있고,이 주제에, 그는 자신의 블로그 작년에 게시 :
An older version of MSCOMM32.OCX has had the "kill bit" flag set.
Tony가 말했듯이 ActiveX 컨트롤에 연결하여 앱을 빌드하는 것보다 Windows API에 의존하는 것이 거의 항상 좋습니다. Windows API에는 ActiveX 컨트롤과 OCX의 버전 관리 문제가 없습니다.
귀하의 답변은 의견입니다. MSCOMM32.OCX는 더 이상 사용할 수 없으며 직접 액세스 할 수 있는지 여부가 아니라 컨트롤 가용성에 대해 묻습니다. – bglenn
Windows API를 사용하는 것이 문제의 해결책입니다. 즉, ActiveX killbit 패치가이 OCX를 중단시키는 것입니다 (다른 것들 중에서). 좀 더 최신 버전을 사용해 볼 수도 있지만 언젠가 MS는 그 패치를 해제하는 패치를 발표 할 수도 있습니다. Windows 버전이 더 이상 Win32 API를 지원하지 않으면 API가 중단되지 않습니다. 저에게 진짜 해결책 인 것 같습니다. 통제 할 수없는 행동으로 쉽게 깨지는 방법을 사용하지 마십시오. –
"직렬 통신을 지원하는 널리 사용되는 컨트롤이 있습니까?" 컨트롤을 사용하는 다른 방법은 없습니다. 관련성이 없지만 Win32 API를 컨트롤에 사용하는 것에 대한 귀하의 요점은 개발 환경 (Access 2007)을 고려할 때 우스운 것입니다. – bglenn
과거에 깨 졌다고 알려진 외부 종속성이있는 응용 프로그램을 작성하는 것은 실제로는 잘못된 프로그래밍입니다. 제 의견으로는. 업데이트 된 버전을 사용하는 것이 해결 방법이지만 근본적인 문제를 수정하는 것은 아닙니다. 실제 문제에 대해 수행 한 모든 작업은 미래의 언젠가는 Windows Update에서 중단 한 다음 궁극적 인 솔루션을 언젠가는 이전하는 것입니다. –
Microsoft는 3 월에 Windows 7의 지원 기간을 통해 vb6 런타임 (mscomm32.ocx와 함께)을 지원한다고 발표했습니다. 웹에서의 보고서에 따르면 Microsoft가 실제로 컨트롤을 죽이고 있다고 표시 한 것 같습니다. 이전 버전의 킬 비트 설정. 가장 최근 버전은 1 년 전입니다. – bglenn
Windows Update에서 언제든지 죽일 수 있습니다. 왜 Win32 API가 더 이상 지원되지 않을 때까지 깨지지 않는 코드를 사용할 수있을 때 종속성을 구축합니까? –