C ++ 코드에서 델파이 클래스를 사용하는 데 문제가 있습니다. 객체를 반환하는 함수를 내보내는 델파이 dll 데모.
내 델파이 DLL 코드는 다음과 같습니다.
라이브러리 DelphiTest; // 부분 사용 .... type IMyObject = interface procedure DoThis (n: Integer); 함수 DoThat: PWideChar; 끝; TMyObject = 클래스(TInterfacedObject, IMyObject) 프로시저 DoThis(n: 정수); 함수 DoThat: PChar; 끝; // TMyObject 구현은 여기로 ... procedure TMyObject.DoThis (n: Integer); showmessage 시작("DoThis 메서드를 호출하는 중입니다." + intToStr(n) + "매개변수"); 끝; 함수 TMyObject.DoThat: PChar; showmessage 시작("DoThat 함수를 호출하고 있습니다"); 결과: = Pchar("안녕하세요."); 끝;
// DLL 함수 내보내기:
함수 CreateMyObject: IMyObject; 표준 호출; 내보내기; var txt: 텍스트 파일; AssignFile 시작(txt, "C:\log.log"); 재설정(txt); Writeln(txt, "안녕하세요"); 결과: = TMyObject.Create; 끝; CreateMyObject 내보내기;
내 C ++ 프로젝트에서 다음과 같이 IMyObject 인터페이스를 선언했습니다.
클래스 IMyObject(공개: IMyObject(), 가상 ~ IMyObject(), 가상 무효 DoThis(int n) = 0, 가상 char * DoThat() = 0;),
내 주요 기능은 다음과 같습니다.
Typedef IMyObject * (__stdcall * CreateFn) (); int main () (HMODULE hLib; hLib = LoadLibrary (L "DelphiTest.dll"); assert (hLib! = NULL); // 통과 !! CreateFn pfnCreate; pfnCreate = (CreateFn) GetProcAddress ((HINSTANCE) hLib, "CreateMyObject "); if (pfnCreate == NULL) (DWORD errc = GetLastError(); printf("% u \ n ", errc); // 오류 127이 발생함) else (printf(" success load \ n ");) IMyObject * objptr = pfnCreate(), objptr-> DoThis(5), FreeLibrary(hLib), int in, scanf_s("% i", & in), return 0;)
이 예에서 내보낸 함수에 액세스하려고 할 때 런타임 오류가 발생했습니다. 줄의 오류:
IMyObject * objptr = pfnCreate();
내 예에서 무엇이 잘못되었는지 말해 줄 수 있습니까?
가능한 경우 C ++ 코드에서 델파이 클래스(DLL 내)에 액세스하기 위한 모든 작업 예제.
해결책
첫 번째 문제는 메서드 규칙을 호출하는 것입니다. 델파이 인터페이스는 델파이 고유의 호출 규칙인 레지스터를 사용합니다. stdcall 사용 예를 들어 인터페이스 메서드의 경우.
다음 문제는 C++에 있습니다. C ++ 인터페이스는 IUnknown에서 파생되어야 하며 생성자 또는 소멸자를 선언하지 않아야 합니다.
이 외에도 Delphi 코드는 char *에 매핑되지 않는 PWideChar에 의해 내보내지고 wchar_t *에 매핑됩니다.
더 나아가 PChar를 반환하면 구현이 리터럴을 반환하기 때문에 여기에서 훌륭하게 작동합니다. 그러나 더 심각한 코드는 동적으로 할당된 문자열을 사용하기를 원할 것입니다. 이 지점에서 설계에 결함이 있습니다.
시스템 드라이브의 루트에 파일을 생성하려면 관리자 권한이 있어야 합니다. 따라서 이것은 또 다른 잠재적인 실패 지점입니다.
다른 오류가 있을 것으로 예상하지만 이것이 내가 지금까지 찾은 전부입니다.
이 기사는 우리 그룹의 젊은 개발자들이 작성한 프로그램을 분석한 결과를 바탕으로 작성되었습니다.
스위칭 구성 요소의 순서를 올바르게 정렬하십시오.
많은 사용자, 특히 이전에 DOS에서 작업한 사용자는 입력 필드 사이를 마우스로 전환하지 않고 Tab 키와 함께 키보드를 사용하는 습관이 있습니다. 또한 마우스로 각 필드를 선택하는 것보다 훨씬 빠릅니다. 따라서 구성 요소를 전환하는 순서를 올바르게 설정해야 합니다. 이것은 모든 컨테이너 구성 요소(패널, GroupBox 등) 내부의 구성 요소와 양식에 여러 구성 요소가 있는 경우 컨테이너 구성 요소 자체에 모두 적용됩니다.
컨테이너 내부의 구성 요소를 전환하는 순서는 TabOrder 속성에 의해 설정됩니다. 첫 번째는 모든 구성 요소가 열거될 때까지 TabOrder가 0인 활성 구성 요소가 되고 두 번째 구성 요소가 1이 되는 식으로 계속 진행됩니다. 또한 구성 요소에는 Tab 키로 전환할 때 구성 요소가 포커스를 받을지 여부를 나타내는 TabStop 속성이 있습니다. 구성 요소로의 전환을 금지해야 하는 경우 해당 TabStop = false를 설정하십시오. 이 경우 마우스를 사용해서만 이 구성 요소로 전환할 수 있습니다.
습관적으로 한 프로그램에서 특정 키를 전환하는 데 익숙해진 사용자가 나머지 프로그램에서 계속 사용하는 경우가 있습니다. 이것은 종종 Enter 키를 사용하여 입력 필드를 탐색할 수 있는 1C 사용자에게 발생합니다. 글쎄요, 그들이 원하면 우리 프로그램에서 이 기회를 주도록 합시다. 양식의 KeyPreview 속성을 true로 설정하고 OnKeyPress 이벤트에 대한 이벤트 핸들러를 작성합니다.
절차 TForm1.FormKeyPress (발신자: TObject; var 키: Char);
시작하다
ord(키) = vk_Return이면
Form1.SelectNext(PrimeForm.ActiveControl, true, true);
끝;
이러한 처리기는 Enter 키를 누를 때 양식 요소를 통해 탐색을 제공합니다. 이 방법은 버튼에서 작동하지 않는다는 점에 유의해야 합니다. 버튼에서 Enter 키를 누르면 버튼이 눌러지고 Tab 키를 누르면 입력 포커스가 토글 시퀀스의 다음 구성 요소로 전송됩니다.
기본 버튼
동일한 모든 사용자는 일반적으로 응용 프로그램 대화 상자에서 Enter 키를 사용하여 선택을 확인하고 Esc 키를 사용하여 취소할 수 있다는 사실에 빠르게 익숙해집니다. 특히 매우 쉽기 때문에 우리 프로그램에서 그들을 실망시키지 말자. Enter에 응답하는 버튼의 경우 Default 속성을 true로 설정합니다. Esc에 응답하는 버튼의 경우 Cancel 속성을 true로 설정합니다. 그리고 그게 다야.
예 혹은 아니오
사용자 작업을 요청하는 모든 대화 상자에는 작업 확인 및 작업 취소(예/아니오, 저장/취소 등) 버튼이 최소 2개 있어야 합니다. 창 제목의 [X] 버튼으로 창을 닫아 작업을 취소할 수 있습니다. 동작을 확인하는 버튼이 하나뿐인 경우에는 용납할 수 없으며, 이를 거부하려면 헤더에 [X] 버튼으로 창을 닫아야 하거나 거부할 가능성이 전혀 없습니다. 이것은 사용자를 혼란스럽게 하여 논리적인 질문을 제기합니다. 거절하는 방법?
또한 위의 "기본 버튼" 섹션에서 말한 내용을 잊지 마십시오.
모든 대화 상자는 화면 중앙에서 열려야 합니다.
디자인 모드에서 생성된 위치가 아닌 중앙에 위치합니다. 첫째, 더 명확하고 둘째, 사용자마다 다른 화면 해상도 문제를 자동으로 제거합니다.
대화 상자가 모달이 아닌 경우는 예외이며 사용자 작업의 결과로 기본 창의 변경 사항이 이 창에서 즉시 발생합니다(예: 데이터 집합 필터링, 그래프 다시 그리기 등).
창은 화면보다 크지 않아야 합니다.
어떠한 경우에도. 창의 일부가 화면 밖으로 크롤링되는 것은 불명예입니다. 이 요구 사항은 사용자의 화면 해상도에 의존하지 않습니다. "더 많은 권한을 얻게 해주세요"와 같은 변명은 통하지 않습니다.
창 요소의 올바른 크기 조정
창의 크기를 조정할 때, 창을 최대화할 때, 최대화한 후 창을 복원할 때 창 요소의 크기를 조정하거나 올바르게 이동해야 합니다.
모든 것이 항상 보입니다.
창의 크기를 줄이면 창 요소가 사라지지 않아야 하며 바람직하게는 창 자체의 스크롤 막대(스크롤)가 나타나지 않아야 합니다. 모든 요소가 표시되고 액세스할 수 있도록 창의 최소 크기를 제한할 수 있습니다. 창에 모두 표시되는 방식으로 구성 요소를 배치할 수 없는 경우 탭(예: PageControl)을 사용하여 구성 요소를 그룹으로 나눌 수 있습니다. 우리는 또한 화면 해상도에 대한 변명을 놓치지 않습니다.
어디서나 힌트, 항상 힌트
버튼, 특히 툴바(예: ToolBar)의 경우 이 버튼이 필요한 이유가 항상 명확하도록 힌트를 설정해야 합니다.
색상 스펙트럼
무지개의 모든 색상으로 구성 요소를 칠하지 마십시오. 이것은 눈을 피로하게 하고 사용자의 주의를 산만하게 합니다. 멋져 보이지 않습니다. 강조 표시는 창의 특정 요소나 특정 부분에 사용자의 주의를 끌 필요가 있을 때 사용됩니다. 예를 들어, 오류가 포함된 밝은 빨간색으로 레코드의 색상을 지정하거나 성공적으로 검사된 레코드의 경우 반대로 밝은 녹색으로 색상을 지정합니다.
결론
일반적으로 프로그램과 특히 인터페이스의 단점을 찾을 수 있는 아주 좋은 방법이 있습니다. 간단합니다. 사용자의 입장에 있는 자신을 상상하고 30분 동안 작동하는 방식으로 작업을 시도합니다. 사용자가 도달 범위 내에 있는 경우(예: 같은 조직에서 근무하는 경우) 더욱 좋습니다. 이 경우 그의 옆에 앉거나 오히려 그를 대신하여 그의 일을 해보십시오. 데이터 입력, 변경, 보고서 표시 등 올바르게 수행하는 방법을 모르는 경우 사용자에게 문의하십시오. 디버그 모드에서와 같이 동일한 유형의 하나 또는 두 개의 작업을 수행하지 말고 다른 순서로 20-30개 또는 그 이상 다른 작업을 수행하십시오. 무언가를 입력하는 것을 잊거나 잘못 입력하고 프로그램이 이에 어떻게 반응하는지 확인하십시오. 당신은 당신의 프로그램의 약점을 빨리 보게 될 것입니다.
기사 작성자는 대학 입학처 업무를 자동화했고, 프로그램 도입 첫해에는 입학처에서 하루 3~4시간을 보내고, 지원자 등록, 개인 데이터 작성, 그들에게 시험 보고서를 제공합니다. 그리고 남은 근무 시간에 그는 실수와 단점을 수정했습니다. 저를 믿으십시오. 내년에는 거의 문제가 없습니다. 인사 모듈 도입도 마찬가지였다.
따라서 사용자 경험을 염두에 두십시오. 그들이 당신의 프로그램으로 작업하는 것을 쉽고 즐겁게 만드십시오.
이 문서는 "DLL에서 문자열을 어떻게 반환할 수 있습니까?", "레코드 배열을 전송하고 반환하는 방법은 무엇입니까?", "양식을 DLL로 전송하는 방법"과 같은 포럼의 질문을 기반으로 합니다.인생의 반을 그것을 알아내는 데 낭비하지 않도록 이 기사에서는 모든 것을 은색 접시에 담아 보겠습니다.
이 기사의 주제는 이 블로그에서 이미 다양한 정도로 다루었지만, 이 기사에서는 그것들을 묶음으로 모아 그 근거를 제시합니다. 간단히 말해서 이 기사에 대한 링크는 DLL을 개발하는 사람들에게 던져질 수 있습니다.
중요 사항: 글을 읽어야 한다 일관되게... 코드 예제는 다음과 같이 제공됩니다. 예, 기사의 각 단계(단락)에서 예제 코드가 새로운 세부 정보와 함께 추가됩니다. 예를 들어, 기사의 맨 처음에는 오류 처리가 없으며 "고전적인" 메소드가 표시되며(예: GetLastError, sdtcall 규칙 사용) 이 메소드는 기사 과정에서 더 적절한 것으로 대체됩니다. 이것은 "새로운"("특이한") 구조가 문제를 제기하지 않기 때문에 수행됩니다. 그렇지 않으면, 각 예에 대해 "이것은 아래의 해당 단락에서 논의되지만 이것은 이 단락에 있습니다."라는 형식의 메모를 삽입해야 합니다. 어쨌든 기사의 끝에 기사에서 말한 모든 것을 고려하여 작성된 기성 코드에 대한 링크가 있습니다. 가져가서 사용하시면 됩니다. 그리고 그 기사는 그 이유와 이유를 설명합니다. "이유와 이유"에 관심이 없다면 결론과 링크로 스크롤하여 예제를 다운로드하십시오.
결과만을 위해
엄격한 기한 준수
투명도
프로젝트 실행
기술 지원을 선물로
프로그래밍, 1C에 대한 조언 수정
우리가 일하는 방법
1. 우리는 전화로 문제를 논의합니다. 원격 액세스 권한이 있는 경우 컴퓨터 화면에 표시합니다.
2. 프로젝트가 큰 경우 루블 단위로 작업을 추정합니다. 그렇지 않은 경우 대략적인 시간입니다.
3. 작업을 완료합니다.
4. 귀하는 귀하의 프로그램에서 작업을 수락하고, 부족한 점이 있으면 수정합니다.
5. 우리가 청구서를 발행하면 귀하가 지불합니다.
작업 비용
1. 모든 작업은 상담, 일반적인 구성 업데이트, 새 보고서 개발 또는 프로그래밍, 처리, 버튼 등의 3가지 범주로 나뉩니다.
3. 10시간 이상의 작업에 대해서는 기술과제와 작업비용을 사전에 작성한다. 작업은 귀하와 참조 조건에 동의한 후 시작됩니다.
기술적 지원
1. 기존에 접수된 저작물에 오류가 있는 경우 3개월 이내에 무료로 수정합니다.
2. 단골 고객의 경우 연중무휴로 업무상의 미비점을 수정해 드립니다.
비즈니스를 관리하는 프로그램.
1C 구매: 엔터프라이즈
우리는 1C의 공식 딜러이며 다양한 소프트웨어 제품과 라이선스를 구입할 수 있습니다. "상자"를 구입하는 것 외에도 프로그램 설정, 조언 및 기본 설정을 도와드립니다.
- 회계
- 매장 자동화
- 모조리
- 패키지에 설치 및 초기 설정 도움말이 포함되어 있습니다!
- 고객의 요구에 맞게 구성을 미세 조정하고 표준 구성에 필요한 기능이 없는 경우 새로운 모듈을 개발합니다.
 |
 |
 |
 |
| 1c 회계 | 1C: 무역 관리 | 1C: 소매 | 1C: 급여 및 인사 관리 |
| 3300 문지름에서. | 6700 문지름에서. | 3300 문지름에서. | 7400 문지름에서. |
서버 제공.
인스턴트 설정 서버 + 1C.
서버가 없으신가요? 그것은 중요하지 않습니다. 우리는 "클라우드"에서 서버를 선택하고 신속하게 설정할 것입니다. 적은 비용으로 매우 안정적인 솔루션을 얻을 수 있습니다.
- 가용성 24/7
- 자체 sysadmin을 유지할 필요가 없습니다(저축으로 서버 비용이 충당됨).
- 서버에 1C를 빠르게 설정하고 설치하면 3일 안에 이미 완전히 작동하는 시스템을 갖게 됩니다.
- 솔루션이 적합하지 않은 경우 언제든지 로컬 서버로 이동할 수 있습니다.
1C의 SMS
고객이 프로모션, 할인에 대해 적시에 알기를 원하십니까? 고객이 돌아오지 않습니까? 1C에서 직접 SMS를 보내도록 설정하십시오!
우리 회사는 1C에서 직접 고객에게 SMS를 보내는 것을 신속하게 설정할 수 있습니다. 자동화할 수 있는 이벤트의 예:
- 다음 구매 직후에 구매 및 보너스 적립에 감사드립니다.
- 다른 중요 또는 휴일을 위한 생일 선물로 카드에 보너스 발생.
- 창고에 상품 도착 알림.
- 선물 보너스 만료.
- 선결제 접수 및 상품 예약 안내
- 매장/사무실까지 가는 방법, 전화번호가 기재된 주소.
- 등.
1C의 설정은 전문가 또는 직원이 수행할 수 있습니다. SMS 관세 페이지에서 관세에 대해 알 수 있습니다.
- SMS 발송 보장, 발송된 SMS에 대해서만 금액이 출금됩니다.
- 각 SMS에 대한 별도의 청구.
- 다양한 방법으로 균형 보충.
- 언제든지 보낸 모든 SMS의 기록을 볼 수 있습니다.
- 메시지 받는 사람의 전화에 있는 디지털 번호 대신 보낸 사람의 이름입니다.
객체 지향 프로그래밍(OOP)은 클래스의 개념과 더불어 인터페이스의 기본 개념도 제공합니다.
인터페이스란 무엇이며 델파이 프로그래밍 언어에서 인터페이스로 작업할 때의 기능은 무엇입니까?
인터페이스는 클래스 또는 구성 요소(Wikipedia)에서 제공하는 서비스를 지정하는 데 사용되는 프로그램 코드의 의미 및 구문 구조입니다.
실제로 인터페이스는 이 인터페이스를 구현하는 클래스와 작업할 때 사용해야 하는 속성 및 메서드 목록과 해당 서명(이름, 데이터 유형, 허용되는 매개변수(프로시저 및 함수용) 등)을 정의합니다. 따라서 특정 인터페이스를 구현하는 클래스는 반드시 모든 구성 요소를 구현해야 합니다. 또한, 그들이 설명하는 방식에 따라 엄격하게 준수합니다.
인터페이스는 종종 추상 클래스와 비교되지만 유사성에도 불구하고 이 비교는 완전히 정확하지 않습니다. 추상 클래스에서는 최소한 멤버의 가시성을 제어할 수 있습니다. 동시에 인터페이스에 대해 정의된 범위가 없습니다.
인터페이스를 사용하면 하나 또는 다른 기능에 대한 액세스를 통합하고 클래스 상속과 관련된 여러 문제를 피할 수 있으므로 아키텍처를 보다 유연하게 만들 수 있습니다(인터페이스는 서로 상속될 수도 있음).
Delphi에서 인터페이스를 선언하려면 interface 키워드를 사용하십시오. 이것은 외부에서 액세스할 수 있는 유닛의 섹션을 정의하는 것과 동일한 키워드입니다(키워드 인터페이스와 구현 사이). 그러나 인터페이스를 선언할 때 클래스 선언과 유사한 다른 구문이 사용됩니다.
델파이/파스칼
IMyNewInterface = 인터페이스 프로시저 InterfaceProc; 끝;
IMyNewInterface = 인터페이스 프로시저 InterfaceProc; 끝; |
따라서 인터페이스 선언 자체의 구문은 다른 프로그래밍 언어와 근본적으로 다르지 않습니다(Pascal 기반 구문의 기능은 포함되지 않음). 동시에 인터페이스 구현에는 여러 가지 특징이 있습니다.
요점은 Delphi 인터페이스가 원래 COM 기술을 지원하기 위해 도입되었다는 것입니다. 따라서 Delphi에서 다른 모든 인터페이스(TObject의 유사체)의 조상인 IInterface 인터페이스에는 이미 이 기술을 사용하기 위한 세 가지 기본 메서드인 QueryInterface, _AddRef, _Release가 포함되어 있습니다. 결과적으로 클래스가 인터페이스를 구현하는 경우 반드시 이러한 메서드를 구현해야 합니다. 이 클래스가 COM과 함께 작동하도록 설계되지 않은 경우에도 마찬가지입니다.
IInterface 인터페이스의 이러한 기능으로 인해 델파이에서 인터페이스를 사용하면 대부분의 경우 의도적으로 사용하지 않는 기능이 클래스에 추가됩니다.
라이브러리 클래스 TInterfaceObject가 있습니다. 이 클래스에는 이미 이러한 메서드의 구현이 포함되어 있으며 이 클래스에서 상속할 때 직접 구현할 필요가 없습니다. 그러나 델파이는 다중 클래스 상속을 지원하지 않기 때문에 델파이를 사용하면 이미 필요한 기능의 설계 및 구현에 추가적인 어려움을 야기하는 경우가 많습니다.
이 모든 것이 인터페이스가 제공하는 모든 가능성에도 불구하고 델파이에서의 실제 사용이 COM 작업을 넘어서지 않는다는 사실로 이어졌습니다.
주로 이 기술, 인터페이스와 함께 작동하도록 최적화되어 있거나, 의무적으로 추가하는 기능 및 아키텍처 제약 조건은 다른 문제를 해결할 때 정당화되지 않습니다.
따라서 많은 델파이 프로그래머는 실제로 여전히 애플리케이션 아키텍처를 개발하기 위한 강력하고 유연한 도구가 부족합니다.
