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

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

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

프로그램 패키지 내 특정 파일을 로드해야 하는 경우, 아래 코드로 현재 프로그램이 실행된 실제 경로를 취득할 수 있음.

ExtractFilePath(Application.ExeName)

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

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

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

struct MyStruct {
  int a;
  char b;
  double c;
}

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

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

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;

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

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년째 못고치고 있다는 소리다..

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

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

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

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

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

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

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

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

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

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

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

TRectangle, TEdit... 등등 TBrush나 기타 TAlphaColor를 프로퍼티로 갖는 객체의 색상 값은 일반적으로 BGR코드를 사용합니다.

델파이는 RGB코드가 아닌 BGR코드를 사용하며 #RRGGBB가 아닌 $LLBBGGRR형식을 따릅니다.

기존에 웹이나 포토샵을 많이 다루던 분들은 생소한 포맷이나 기존의 RGB에 HSL의 Lightness 가 추가된 형태라 생각하시면 쉽게 이해하실 수 있으실 겁니다.

LL의 두 자리를 활용하여 해당 색상의 밝기를 조절함으로써 색의 밝기도 같이 표현하죠.

하지만 안그래도 더 복잡해진 코드, 정해진 색상표는 없을까요?

델파이는 이러한 고민을 위해 사전에 색상을 정의하고, 이 색상의 느낌에 맞는 이름을 부여하고, 이를 const 상수화 했습니다.

이 상수화된 색상에는 밝기 부분이 정의되있지 않은 가장 밝은 색에 가까운 색상들입니다.

예를들어 핏빛색에 가까운 claCrimson 을 사용한다면, 델파이의 코드는 이렇게 동작하죠.

어라? 앞에서 분명 델파이의 코드는 $LLBBGGRR이라고 했는데 6자리밖에 없다구요?

델파이의 색상은 별도로 밝기가 정의되지 않으면 밝기는 무조건 FF가 됩니다.

Alpha라는 상수를 보세요.

$FF000000 의 값으로 LL에만 FF 나머지는 00의 값을 가집니다.

이것이 Crimson으로 정의된 BGR 컬러와 or 연산이 되어 $$FFDC143C로 넘어오는 것이죠.

OR은 두 값의 비트를 비교했을 때 둘 중 하나라도 1이 있다면 해당 비트는 1이 되는 연산입니다.

그래서 FF00 0000 과 00DC 143C 를 연산한

이 되죠.

그런데 이 편한 기능이 종종 동작하지 않을 때가 있습니다.

델파이 IDE는 언어와 프레임웍은 정말 좋지만,  다소 불안정한 면이 있어 다른 IDE에서는 부드럽게, 유연하게 동작하는 기능들이 델파이 IDE에서는 정상적으로 동작하지 않는 경우가 있습니다.

예를들어 델파이는 사용한 객체에 따라 자동으도 uses가 되지만, 이것이 사용하지 않을 때 자동으로 해제가 되지 않습니다.

점을 찍어 하위 프로시저 등을 참고하려 해도, 전혀 상관없는 다른 부분의 코드에 문제가 있으면 그 부분을 지적하는 것이 아니라 전체의 소스에서 이 기능이 동작하지 않습니다.(심지어 빌드시에도 알려주지 않습니다)

이러한 불안정한면 중에서, 사용을 하지만 프로그래머가 생성하지 않은 객체에 대한 uses는 되지 않는 것같습니다.

예를들어, TRectangle.Fill.Color 에서 프로그래머는 TRectangle을 선언했지 Color의 TAlphaColor을 선언한 것이 아닙니다.

델파이는 그렇기에 프로그래머가 전혀 사용하지 않는다고 판단하고 상수화된 색상 사용을 위해 반드시 uses 되어야 할 'System.UIConsts' 라이브러리가 자동으로 uses가 안되는 경우가 있습니다.

다른 언어의 IDE는 이런 날코딩으로 사용된 객체도 필요하면 자동으로 인클루드나 임포트가 됩니다만, 델파이 IDE는 아직 보완되어야 할 부분이겠지요.

결론은,

델파이의 색상은 $LLBBGGRR로 저장됩니다.

기본 색상코드를 단어가 사용된 상수를 사용할 수 있습니다.

상수는 cl, 또는 cla + 색상명입니다.

색상에 상수 사용 시 'E2003 Undeclared identifier' 이 발생한 경우 자신의 프레임웍에 맞는 접두사가 아니거나(cl, cla) System.UIConsts가 uses되지 않은 경우입니다.

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

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

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

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

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

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

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

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

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

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

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

간단합니다.

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

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

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

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

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

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

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

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

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

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

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

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

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

TImage.Bitmap.Assign(TargetImage.Bitmap);

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