«   2026/02   »
1 2 3 4 5 6 7
8 9 10 11 12 13 14
15 16 17 18 19 20 21
22 23 24 25 26 27 28

델파이 관련 글을 찾다보면, 옛날 델파이 프로그램과 최신과의 차이가 여럿 발생해 혼란을 겪는데, 최근까지도 구형 버전도 많이 쓰이다보니 좋은 팁이지만 업로더도 뭐가 문제인지 모를 때가 간혹 있다.

 

이 표는 구형과 신형(정확한 경계는 모르겠으나)의 uses 에서의 명칭 차이를 개발하면서 발견하는 것 하나 하나 비교표로 만들고자 한다.

예를 들어, messages 를 그냥 uses 해도 사용엔 문제가 없지만, 디버깅 시 라이브러리를 찾지 못해 함수의 원형을 볼 수가 없다. 그러나 Winapi.messages 로 호출할 경우 ide 상에서 곧바로 원형과 그 동작을 살펴볼 수 있다.

 

구버전 신버전
Messages Winapi.Messages
ShellApi Winapi.ShellApi

 

,

최근 한 프로젝트로 인해 C언어 라이브러리를 델파이로 포팅할 일이 있었다.

대부분 구글링을 통해서 쉽게 변환할 수 있었는데 익명 공용체의 포팅에서 쉽게 알기 어려웠던 점이 있어 포스팅으로 남긴다.


먼저 구조체는 아래와 같이 사용된다.


 C Style

 Delphi Style

struct MyStruct {

int a;

char b;

double c;

}

MyStruct = record a:integer; b:char; c:double; end;


그리고 공용체는 아래와 같이 사용된다.


 C Style

 Delphi Style

struct MyStruct {

union {

int a;

char b;

double c;

} u;

}

MyStruct = record

case Integer of 0: (a:integer); 1: (b:char); 2: (c:double); end;


위와 같이 C에서 델파이로의 변환이 어렵지 않게 이뤄질 수 있는데 문제는 다음의 코드에서 발생했다.



#ifdef __GNUC__

  #define PACKED( __Declaration__ ) __Declaration__ __attribute__((packed))
#else
  #define PACKED( __Declaration__ ) __pragma( pack(push, 1) ) __Declaration__ __pragma( pack(pop) )
#endif

PACKED(
typedef struct param_union {
    union {
        float param_float;
        int32_t param_int32;
        uint32_t param_uint32;
        int16_t param_int16;
        uint16_t param_uint16;
        int8_t param_int8;
        uint8_t param_uint8;
        uint8_t bytes[4];
    }; // 익명 공용체
    uint8_t type; // 공용체 이후 unsigned 8-bit int
}) param_union_t;


익명이 아니라면 공용체 레코드를 별도로 만들어서 아래와 같이 해결할 수 있지만



union_t = packed record case Integer of 0: (param_float:single); 1: (param_int32:Int32); 2: (param_uint32:UInt32);

...

...
end; param_union_t = packed record u: union_t; UInt8 type; end;


익명 구조체이므로 어떻게 해결해야할지 Stack Overflow에 질문을 했었다.

(link: https://stackoverflow.com/questions/54613312/how-do-i-convert-a-c-union-to-delphi )


문의 결과 익명 공용체 이후에 기술되는 변수들은 가장 사이즈가 큰 case 뒤에 같이 서술하면 된단다.

동일한 byte 크기의 case가 여럿이면 그중 아무곳에나 서술하면 된다고 한다.



 param_union_t = packed record
  case Integer of
    0: (param_float: Single);
    1: (param_int32: Int32);
    2: (param_uint32: UInt32;
        &type: UInt8);
    ...
    ...
end;

'컴퓨터 > Delphi' 카테고리의 다른 글

델파이 uses 이름 표  (1) 2020.07.20
[Delphi] 프로그램 현재 경로 확인  (0) 2020.07.15
[QuantumGrid] CheckBox 사용  (0) 2018.11.30
이상한 Undeclared  (0) 2017.06.16
[Component] Indy 에서 예외처리 하기  (0) 2016.11.26
,

퀀텀그리드를 사용하기 위해 학습하면서 체크박스 사용이 필요할 경우, 


cxgrid 선택 후


Data Controller.DataModeController.GridMode property =  False

Data Controller.DataModeController.SmartRefresh property =  True

Data Controller.KeyFieldNames property = UniqueField 명 설정(PrimaryKey 등)


View 선택 후


36800


View -> Column 선택 후


DataBinding.FieldName property = null

DataBinding.ValueType = Boolean

Properties property = CheckBox

Properties.NullStyle = nssUnchecked

Properties.ValueChecked = True / Type = Boolean //체크시 입력할 값

Properties.ValueGrayed = Null / Type = Null // 중간선택시 입력할 값

Properties.ValueUnchecked = False / Type = Boolen //체크해제시 입력할 값

AllowGrayed := False; //중간 선택 허용할 경우 True

ValueChecked := True; //체크값 기준

ValueUnchecked := False; //해제값 기준


,

델파이는 잘 만든듯 하면서 엉뚱한데서 허술하다.
예를들어 요즘엔 당연시 되는 자동 uses 따위 없다.
컴포넌트를 올리고 저장하면 그 부분은 자동으로 되지만 함수나 클래스를 당겨올 경우는 자동 uses 가 안된다.
데브기어 측에서는 여러가지 말을 해줬지만 그냥 결론은 엠바가 이걸 만들줄 모른다 라고 밖에 안들린다.
철학은 무슨 델파이 기본이 빠른 생산성인데 uses 해야할 라이브러리 찾아 다니다가 시간만 다 잡아먹는다.
이상한데서 개발 능력이 떨어지는 엠바가 또 한가지 버그가 있는데 기본 클래스가 ide에서 에러로 걸린다는 거다.
이건 진짜 내가 쓰는 도쿄버전에 국한된 문제가 아니라 전의 전의 전의 전의 내가 델파이를 처음썼던 xe2부터 이미 보고가 된 것인데 고치지 못했다는건
엠바 IDE 개발 수준은 딱 거기까지 라는 것.
이런 엉뚱한 점을 이의제기하면 덮기 일쑤던데 (특히 나같이 입문한지 얼마 안된 사람은) 기본은 좀 하고 덮자.

 

어쨌든 아래와 같은 상황이 있다.

 

 

보면 델파이의 가장 기본 클래스인 TObject가 밑줄이 들어가있다.

이런 식으로 기본 기능 자체가 좀... 이상하다 델파이는.. 심각하게..

그대로 빌드해도 큰 문제는 없지만 찝찝해도 이대로 해야된다.. 아님 IDE를 재시작하거나..

엠바에 신고한 버그 리포트에 따르면 ide가 기본적으로 system을 먹고 들어가야 하는데 이걸 못먹는단다.

근데 이게 내가 본것이 08년도 글인데 10년째 못고치고 있다는 소리다..

,

C#을 배우기에 앞서 내가 왜 C#을 배우게 되었는지에 대해 먼저 포스팅해보려고 한다. 많은 학생분들이나 선배 개발자님들도 C#을 많이 학습하고 있는데 이러한 흐름에 몸을 실으면서 학습을 하게 된 것은 아니다. 먼저 델파이와 C#의 차이를 먼저 비교해야한다. 먼저 난 델파이가 싫어져서 C#을 배우기 시작한 것이 아니다. C#에 그렇게 큰 비중을 두고 학습하는 것도 아니고 여전히 내 주력 언어는 델파이일지도 모른다. 하지만 한 우물만 파면 더 좋은 것이 있어도 보질 못하고 생각또한 갇히게 된다. 나는 C#을 통해 델파이에서의 불편했던 점을 찾고, 하일스베르 등이 델파이에서는 이렇게 생각하고 구현한 것을 C#에서는 어떻게 처리했는지, C#에서 더 매끄럽거나 더 뛰어난 컨트롤이 있다면 보고 배워 델파이의 컴포넌트로 포팅해 보기까지 다양한 호기심을 충족하고자 학습을 시작한다.


이 글을 적는 이유는 먼저 C#은 델파이가 아니다. 델파이의 많은 철학이 그대로 녹아있지만 동일하게 봐서는 안된다. 오히려 나는 이것을 배우면서 현재까지는 자바와 드림위버같은 느낌을 더 크게 받았다. 게다가 계속 개발되어지고 있는 언어이다. 너무 델파이만 신봉하여선 안된다는 소리다. MS 닷넷 특성상 델파이처럼 코드 단일화가 되기는 조금 힘들겠지만. (MS의 Object-C 같다는 소리도 한다고 한다) 


최근들어 델파이를 잘 사용하지 못하게 되었고, 간간히 내가 찾은 팁이나 국내 책에서 알려주지 않는 소소한 기능 설명을 위해 업로드하던 포스팅도 겨우 4건에서 그쳤다.

가만 고민해보면 우선 델파이의 지원 범위가 아직은 내가 원하는 범위까지 지원되지 못하는 탓이 클 것이다. 

라자루스를 통해 오브젝트 파스칼을 쓸 수 있다지만 라자루스 또한 다양한 리눅스 제품군을 커버하지는 못하고 있고 나의 경우 임베디드 리눅스와 TUI 환경의 프로그램을 주로 접하다보니( 그러고보니 요 몇년간 리눅스에서 GUI를 쓴 적은 X11 포워딩을 통한 gedit 밖에 없다.) 더욱 델파이와 거리를 두게 되었다고 할까.

사실상 델파이는 내게 있어서 아직은 임베디드의 제어를 위한 서브 도구에 지나지 않는다고 하면 되겠다.


그렇다고 델파이가 별로 좋지 않다는 것은 아니다. 오히려 내가 비록 보잘것없으나 이 정도의 언어 실력까지 올라올 수 있었던 것은 델파이의 단순함과 직관적인 UI를 통해 빠른 생산성을 얻을 수 있음은 부정할 수 없다. 네이티브이기 때문에 자바나 닷넷보다 빠를 수 있음은 두말할 것 없고. 델파이는 여전히 훌륭한 도구이고 훌륭한 개발자들의 손을 통해 오늘날에도 철학을 지키며 만들어져 오고 있다. 많은 개발자들이 많은 훌륭한 프로그램을 만들어 내고 있으며 때로는 기존의 많은 프로그래머들이 찬양하던 자바 언어로 된 프로그램이 하나 둘 델파이로 대체되는 경향도 없잖아 보이고 있다. 


많은 사람들이 델파이는 너무 마이너적인 언어라고 한다. 인정할 수 밖에 없다. 마이너라는 것은 아무리 훌륭한 언어라도 비주류라면 어디에나 붙을 수 있는 칭호고 델파이는 여전히 마이너라고 생각한다. 많은 프로젝트가 여전히 자바와 닷넷 위에서 진행되고 있고 임베디드 또한 C와 C++로 작성되어지고 있다. 한때 빠른 취직을 위해 찾아볼 때도 구인 구직 또한 자바가 압도적이었으니까. (물론 대부분 제값 받을 수 있는 일은 아니었다.) 하지만 나는 이 부분이 한창 IDE 플랫폼 시장이 격화될 때 인재 유출로 인해 많은 개발자와 고객사를 잃어버린 탓이 크다고 생각한다. 만약 당시에 MS가 Delphi, Turbo Pascal의 개발자들을 전원 스카웃하지 않았다면 어땠을지는 개개인의 의견차가 크니 별다로 언급하지 않겠다.


내가 이런 좋은 언어를 배웠음에도 C#을 배우려는 점은 몇 가지가 있는데 그중 하나는 Visual Studio라는 IDE 플랫폼의 매력이 크다. 델파이는 언어 철학과 직관적인 배치, 사용법은 확실히 VS보다 편하다. 적응의 문제가 아니다. 나는 작년 이맘 때 처음 델파이를 학습했고, c#을 학습하는 지금 벌써부터 불편함이 느껴진다. 디폴트 환경에 도구 상자가 감춰져 있어야 하는 이유를 모르겠으며 Control의 Drag & Drop 시 왜 내가 끌어다 놓은 곳에 정확히 안착하지 못하고 좌상단 모서리에 안착이 되는지는 여전히 이해할 수가 없다. 





위치 포인트는 무시하더라도 여러 도구를 가져오는 시간도 상당히 오래 걸린다. 내가 왜 xaml을 봐야하는지 이것 또한 이해할 수 없는 요소이다. 그렇다고 보기 좋게 작성되는 것도 아니며 속성 팔레트가 존재하는데도!


하지만 델파이가 VS를 따라오지 못하고 있는 부분도 보이는데, 델파이는 라이브러리 확인이 다소 불편하다. 델파이의 라이브러리를 살펴보기가 어렵다는 것이 아니다. 라이브러리 자체는 훨씬 쉬운데, 그 방법론의 문제다.

우선 델파이에서의 정의 확인부터 간단히 넘어가보자.

델파이에서 어떤 변수가 어디에 선언 되었는지, 사용되었는지 찾기는 VS보다 쉽다.

Ctrl 누른 상태에서 해당 변수든 프로시저든 펑션이든 누르면 넘어간다.


그렇다. 누르면? 넘어간다. 그냥...


완전히 커서가 해당 구역으로 넘어가버린다는 의미이다.

라이브러리에서의 정의를 확인하기 위해 누르면?



VS에서는 이 기능이 윗처럼도 가능하지만 이렇게 구현이 될 수도 있다.



델파이를 공부하다가 후배가 물어봐서 VS를 오랜만에 설치해서 연 적이 있는데 이 기능은 정말... 정말이지 놀라웠다.

델파이는 단일 모니터에 최적화된 툴의 느낌이라면 VS는 넓은 화면을 효율적으로 볼 수 있다고 봐야겠다.(그것이 도구 팔레트를 기본으로 고정시켜주지 않은 것을 변명할 수는 없지만) 실제 델파이를 코딩하다보면 라이브러리를 직접 확인할 일이 생각보다 많은데 다른 언어는 레퍼런스를 주로 보고 의지한다면 델파이는 각 변수의 용도 정도만 알아도 초보 개발자가 라이브러리를 보는데 큰 지장이 오지는 않는다. 되려 델파이의 레퍼런스나 책을 볼 일보다 책에 나오지 않는 컴퍼넌트의 명확한 용도를 알고자 구글링할 때가 더욱 많으니까. 그런데 그 보는 방식이 너무 불편하다는 것이다. 무조건 탭이 넘어가고 동시에 두가지 탭을 보기 힘들다. 하지만 이 기능은 내가 수정하고자 하는 코드 바로 근처에서 내가 원하는 정보를 찾아주므로 비교해보고 내용을 파악하기에 최적화되어 있다는 거다.


그 외에 차이점을 더 느끼지만 한번에 다 공개해버리면 뭔가 언어간 디스전과 같이 흘러갈 것같다. 나는 특정 언어가 우월하다는 것에는 반대하는 입장이고, 디스보다는 이 언어는 이게 낫고 저 언어는 이게 좋더라.. 정도로 봐주었으면 한다. 앞으로의 c# 학습 글은 얼마나 올라올 지 모르겠지만 전체적인 흐름은 델파이나 이클립스와의 비교로 진행하게 될 듯하다. 급할땐 한번에 내가 필요한 정보를 제공하는 것도 좋고 따라함으로써 금세 성취감을 느낄 수 있는 구성도 좋지만, 그런 책이나 강의, 강사님들은 많다. 하지만 처음부터 여러 언어의 차이나 해당 언어의 원리에 대해 맛보기나마 호기심을 채워주는 글은 많지 않다. 


나 또한 언어의 학습에 있어 많은 부분이 부족했지만 초보자 수준에서 접할 수 있는 정보의 양은 한계가 있었고 지금도 나는 초보자일 뿐이다. 하지만 초보자가 초보자의 입장에서, 책만으로는 알기 어려웠던 접시물의 깊이를 내가 겪었던 그대로 풀어 설명을 하고 싶다. 결국 나는 나중에도 언제나 초보자일 것이고 나 또한 이 글들을 통해 다시금 배우고 새로운 것을 알게 될 것이니까.


PS. 실제로 나는 중학생 때 C를 배우면서도 왜 이게 이러는지 모르고 배웠다. 이 글을 어쩌다가 읽게된 몇몇 당신도 찔리지는 않으시는지..?

,

델파이는 Try ... except ... end 로 예외처리를 지원하고 있고 Indy 또한 Error Exception을 지원합니다.

하지만 예전에는 Indy의 exception이 IdException에 정의되어 있었습니다.

하지만 지금은 IdException을 uses 하면 파일이 있다고 나오지만




예전 코드나 예제는 더이상 사용할 수 없습니다.



왜냐하면 에러 정의가 IdException이 아닌 IdStack으로 옮겨졌기 때문입니다. 

그래서 옛날 코드나 예제를 사용하면 특정 인디 버전부터는 E2003 Undeclared identifier 에러가 발생합니다.

델파이는 대부분의 예제가 08년 09년을 기점으로 그 이전에 많이 기록이 남아 있습니다.


이제는 인디 컴포넌트의 예외처리를 하려면 IdStack을 uses해야 합니다.




위와 같이 처리하면 됩니다.

위 코드는 서버 접속 시 10060 Time Out 에러에 대한 예외처리를 하고 있습니다.

어느 상황의 에러가 어떤 코드인지 알고 싶다면, 아래 사이트를 참고하세요.



'컴퓨터 > Delphi' 카테고리의 다른 글

[QuantumGrid] CheckBox 사용  (0) 2018.11.30
이상한 Undeclared  (0) 2017.06.16
TAlphaColor의 색상 표현  (0) 2016.11.19
TEdit 클릭 시 내용 지워지기, 다시 나타내기  (0) 2016.11.05
[FMX][Timage] 이미지 복사  (0) 2016.09.25
,

TEdit은 단일 라인의 입력 컴포넌트로 많이 쓰이는 컴포넌트입니다.

TEdit은 기본적으로 네모 박스 하나만 나오고 이것이 무슨 값을 취하려는지 나오지 않습니다.


이렇게 네모 박스만 생기죠.

그래서 이 박스가 무엇인지를 위해 앞에 TLabel을 달거나 이미지를 붙여줍니다.



하지만 이렇게 하면 VCL이나 PC같이 큰 화면에서는 문제가 없지만 FMX에서는 가용 면적이 줄어드는 역효과가 있습니다.

이를 위해 델파이는 TLabel이 아닌 TEdit의 TextPrompt 프로퍼티가 정의되어 있습니다.

이 프로퍼티는 Prompt 즉, 해당 TEdit에 사용자가 입력한 내용과 별개로 배경처럼 해당 TEdit이 무엇을 입력받으려는지를 명시해주는 역할을 합니다.



이렇게 TEdit을 선택한 뒤, 해당 TEdit에서 입력받을 것이 무엇인지 명시해주면 아래와 같이 희미하게 나타납니다.



문제는 이렇게만 하면 입력 시에 프롬프트가 지워지지 않아 내가 무얼 입력했는지 글자가 겹쳐 보기 힘들다는 점입니다.




TEdit의 OI의 Events를 보면 OnCanFocus 라는 이벤트가 있습니다. 이 이벤트는 해당 개체에 포커스(초점)이 있으면 발생하는 이벤트로 TEdit에서 내용을 입력하기 위해 커서가 들어가는 것도 초점이 들어가는 것입니다.

이제 이 이벤트에 내용을 채웁니다.


(Sender as TEdit).TextPrompt := '';


간단합니다.

우리의 목적은 입력 시에 내용을 지워주면 되는 거니까요.

문제는 여기서 발생합니다.

만약 포커스가 있었다가, 아무 내용도 없이 떠나면 이게 무슨 입력이었는지 알 수가 없습니다.

내용이 빈값이면 다시 보여주어야겠죠.


Events에 OnExit라는 이벤트가 있습니다.

이 이벤트는 포커스가 떠날 때 발생하는 이벤트입니다.

그럼 이 이벤트의 내용을 채워봅시다.


if (Sender as TEdit).Text = '' then

(Sender as TEdit).TextPrompt := '이것은 프롬프트';


이렇게 해주시면 TEdit에 포커스가 발생했을 때, 포커스가 떠났을 때 TextPrompt의 내용을 없애기도, 다시 보여주기도 합니다.

이를 응용하면, 항시 프롬프트가 있어야 하면 프롬프트의 색을 더 옅게 한다던지, 프롬프트가 아닌 Text그 자체에 대한 수정도 가능합니다.

반대로 Text에 명시를 해줬다가 입력을 시작하면 Prompt로 바꿔줄 수도 있죠.


이에 대한 응용은 여러분의 몫입니다.

'컴퓨터 > Delphi' 카테고리의 다른 글

[QuantumGrid] CheckBox 사용  (0) 2018.11.30
이상한 Undeclared  (0) 2017.06.16
[Component] Indy 에서 예외처리 하기  (0) 2016.11.26
TAlphaColor의 색상 표현  (0) 2016.11.19
[FMX][Timage] 이미지 복사  (0) 2016.09.25
,

델파이 FMX에서 이미 생성된 TImage의 이미지를 다른 TImage(또는 TBitmap도 되는 것 같다.) 로 복사할 때

MultiResBitmap 프로퍼티나 CopyFromBitmap 에서 헤메지 말고


TImage.Bitmap.Assign(TargetImage.Bitmap);


으로 한방에 해결할 수 있다.

'컴퓨터 > Delphi' 카테고리의 다른 글

[QuantumGrid] CheckBox 사용  (0) 2018.11.30
이상한 Undeclared  (0) 2017.06.16
[Component] Indy 에서 예외처리 하기  (0) 2016.11.26
TAlphaColor의 색상 표현  (0) 2016.11.19
TEdit 클릭 시 내용 지워지기, 다시 나타내기  (0) 2016.11.05
,
1
프로필 이미지
It's the Only NEET Thing to do. written by 나즈나
분류 전체보기 (256)
포트폴리오 (2)
여러가지 (160)
Windows (26)
Linux (1)
Server (5)
컴퓨터 (48)
전자기기 (3)
자격증 (3)
모바일 (1)
공유기 (4)
초소형컴퓨터 (3)