LazarusCompleteGuide:3.1

라자루스 메인 메뉴

메인 메뉴의 상위에 위치한 라자루스 메뉴는 일상 프로그래밍에서 필요로 하는 기능으로 접근할 수 있도록 해준다. 내장된 기능 외에도 IDE를 다양한 방식대로 맞춤 사용할 수 있으며 자주 사용하는 메뉴 옵션을 키보드에 단축키로 설정할 수 있다 (Environment ⇒ Options... ⇒ Editor, Key Mappings).

파일 메뉴

파일 메뉴는 파일을 작업할 때 필요한 기본 기능에 접근하도록 해준다.

그림 3.1: 파일 메뉴

일부 프로그램들은 하나의 파일만 가지는데, 언젠가는 더 많은 파일이 필요할 것이다. 이때 File ⇒ New form 을 이용해 새로운 (빈) 폼을 생성한다. 모든 폼은 유닛을 기반으로 하기 때문에 새로운 폼과 함께 새로운 유닛이 자동으로 생성된다.

기능 또는 프로시저 묶음을 구분하여 유지하고자 하는 경우 File ⇒ New Unit 옵션을 사용한다. 이는 그러한 프로시저를 위치시킬 수 있는 빈 유닛을 (폼 없이) 제공한다.

새로운 프로젝트 또는 다른 상황에서 위의 두 가지 옵션으로 충분하지 않은 경우, File ⇒ New…라는 또 다른 옵션이 있다. 다양한 프로젝트 타입에 관한 자세한 정보는 4장에서 찾을 수 있다.

File ⇒ Open... 과 File ⇒ Close 는 자체 설명적(self-explanatory) 옵션이다. File ⇒ Open Recent는 사용자가 최근에 마지막으로 열었던 몇 개의 파일을 리스트로 보여준다 (기본 값: 10개). 최근 연 파일의 수는 Environment ⇒ Options... ⇒ Environment ⇒ Files ⇒ Max recent files를 통해 변경할 수 있다.

완성된 프로젝트를 다른 이름으로 저장해야 하는 경우 (예: 다른 프로그래머에게 배포용) 파일마다 따로 처리하기보다는 Project ⇒ Publish Project... 를 이용하는 편이 수월하다.

그림 3.2: 디렉터리 제거 대화창

프로젝트를 작업하면서 사용자는 많은 불필요한 파일들을 저장하게 될 것이다 (예: 백업 카피). 델파이 프로젝트를 라자루스로 변환하면 오래된 델파이 파일이 더 이상 필요하지 않음에도 불구하고 디렉터리에 남아 있다. 그러한 파일들은 File ⇒ Clean directory... 옵션을 이용해 제거할 수 있다. 최종 대화창의 Directory 필드에서 제거하고자 하는 디렉터리를 선택한다. 프로젝트가 열려 있다면 해당 디렉터리가 기본적으로 표시될 것이다. 하위 디렉터리를 정리하고 싶다면 해당 확인상자를 클릭한다.

제거할 (정리할) 파일을 선택하기 위해서는 Remove files matching filter 콤보 상자를 이용해 필터를 설정하라. 제공되는 필터 중 하나를 선택하거나 사용자의 기본 필터를 입력한다.

삭제되지 않은 파일들은 Keep files matching filter 필드로 들어간다. 이러한 파일들은 Remove file matching filter 필터에 포함시켜도 여전히 남는다. 이 두 필터가 중복된 엔트리를 가진 경우 혼동될지도 모른다! 첫 1000 바이트에 특수 문자가 포함되면 파일은 '텍스트' 파일로 확인된다.

File ⇒ Print 옵션은 라자루스 패키지 printers4lazide가 설치되었을 때만 표시된다. 설치되지 않았다면 Package ⇒ Install Uninstall packages... 를 이용해 설치할 수 있다.

에디터에서 텍스트를 선택하여 Print 옵션을 이용하는 경우 변경된 설정은 사용자가 다음에 라자루스를 시작할 때 적용된다. 따라서 File ⇒ Restart 옵션을 이용하는 편이 더 빠르다.

편집 메뉴

그림 3:3 편집 메뉴

Edit 메뉴는 클립보드의 사용과 소스 코드의 조작에 예상되는 명령을 포함한다. 편집 도중에 버튼 또는 키를 잘못 눌렀거나 옵션에서 원하는 효과가 나타나지 않은 경우 Undo 버튼을 ([Ctrl] + [Z]) 눌러 실행을 취소할 수 있다.

실행을 취소하면 에디터는 사용자가 실수하기 전 상황으로 복구시킨다. 실수로 실행 취소를 너무 많이 실행할 경우 Redo 는 Undo의 효과를 취소할 수 있다.

Edit 메뉴는 소스 코드를 포맷팅(formatting)하는 데 사용하는 다수의 명령을 포함한다. 하지만 소스 코드의 포맷팅에 관해 보편적으로 수용되는 규칙은 없다.

Pascal의 프로그램식 규칙을 따르는 한 (예: 각 문장 끝에 세미콜론을 붙임) 컴파일러는 사용자의 소스 코드의 포맷에 대해 불평하지 않을 것이다.

하지만 프로시저를 두 칸(two characters)씩 들여 쓰는(indenting) 규칙 등 특정 규칙들을 따름으로써 자신의 코드 가독성을 향상시킬 수 있다.

그림 3.4: 편집 메뉴에서 이용 가능한 텍스트 선택 옵션

포맷팅 명령은 텍스트 중 일부가 (또는 전체가) 선택되었다고 가정한다. 텍스트는 수동으로 선택하거나 Edit ⇒ Select 메뉴를 통해 선택할 수 있다. Indent selection 옵션은 선택한 텍스트를 우측으로 이동시키고, Unindent selection은 선택한 텍스트를 특정 문자 수 만큼 좌측으로 이동시킨다.

몇 자를 들여 쓸 것인지는 Environment ⇒ Options... ⇒ Editor ⇒ General ⇒ Indent and Tabs ⇒ Block indent 를 이용해 변경할 수 있다.

기본 값은 두 칸이다.

Edit ⇒ Enclose selection... 메뉴는 선택한 텍스트 주변에 추가하고자 하는 인클로징(enclosing) 구조를 선택할 수 있는 대화창이 나타난다. 여기서 루프 (예: while...do) 또는 시퀀스를 (예: begin...end) 선택할 수 있다.

그림 3.5: 선택한 텍스트의 인클로징을 위한 대화창, Edit ⇒ Enclose selection...을 통해 접근

Edit ⇒ Comment selection은 행이 시작되는 지점에 두 개의 슬래시(//)를 추가하여 선택한 텍스트를 주석문(comment)으로 만든다. 주석문을 다시 코드로 변경하려면 모든 // 주석문 표시를 제거하는 Edit ⇒ Uncomment selection을 통해 실행할 수 있다. 일시적으로 코드 섹션을 코멘트 아웃(comment out)하는 것은 코드의 일부분에 문제가 있을 때 유용하다. 해당 부분을 제외한 나머지 코드 부분을 검사하므로 의심이 가는 코드를 삭제하고 재입력하는 수고를 덜어 준다.

Edit ⇒ Toggle comment 는 주석 처리되지 않은 행을 주석 처리하거나 이미 주석 처리된 행은 주석 해제를 하여 현재 주석문 상태를 되돌린다. 해당 기능으로 빠른 접근을 가능하게 하려면 Environment ⇒ Options... ⇒ Editor, Key mapping 에서 단축키를 할당하면 된다.

그림 3.6: 정렬 선택 대화창

Edit ⇒ Sort selection은 선택한 에디터 텍스트를 여러 방식으로 정렬하도록 해준다. Pascal은 소스 코드 내 키워드의 순서와 관련해 특정 규칙을 따르기 때문에 (begin이 먼저 오고 뒤에 end가 붙는다) 프로시저 내에서 코드를 알파벳순으로 정렬하는 것은 의미가 없다.

하지만 값의 리스트를 정렬하는 것은 매우 유용하다. 대화창의 미리보기 창에서는 선택한 정렬 옵션을 선택된 텍스트에 적용시켰을 때 결과를 보여준다. Direction 옵션은 Ascending 또는 Descending으로 정렬하도록 해준다. Ascending은 오름차순, 즉 a, b, c 순이며, Descending은 내림차선, c, b, a 순으로 정렬한다.

Domain 옵션은 정렬을 실행할 수준을 설정하는 데 사용한다:

Lines는 각 행의 첫 문자를 정렬하는데, 다음과 같다:

1.  procedure Button1Click(Sender: TObject);
2.  procedure FormCreate(Sender: TObject);
3.  procedure FormMouseMove(Sender: TObject; Shift: TShiftState; X, Y: Integer);
4.  procedure FormPaint(Sender: TObject);
5.  procedure FormMouseUp(Sender: TObject; Button: TMouseButton; Shift: TShiftState; X, Y: Integer);
6.  procedure FormMouseDown(Sender: TObject; Button: TMouseButton; Shift: TShiftState; X, Y: Integer);
7.  procedure FormDestroy(Sender: TObject);

위는 다음과 같이 바뀐다:

1.  procedure Button1Click(Sender: TObject);
2.  procedure FormCreate(Sender: TObject);
7.  procedure FormDestroy(Sender: TObject);
6.  procedure FormMouseDown(Sender: TObject; Button: TMouseButton; Shift: TShiftState; X, Y: Integer);
3.  procedure FormMouseMove(Sender: TObject; Shift: TShiftState; X, Y: Integer);
5.  procedure FormMouseUp(Sender: TObject; Button: TMouseButton; Shift: TShiftState; X, Y: Integer);
4.  procedure FormPaint(Sender: TObject);

단어가 사전처럼 정렬되며 아래 uses 절이

관련자료1

아래와 같이 바뀐다.

관련자료2

Paragraph를 이용하면 선택한 텍스트를 단락(paragraph)으로 나눈 후 정렬한다. Paragraph는 들여쓰기가 적게 된 텍스트로 시작된다. 앞의 예제를 다시 들자면,

1.  procedure Button1Click(Sender: TObject);
2.  procedure FormCreate(Sender: TObject);
3.  procedure FormMouseMove(Sender: TObject; Shift: TShiftState; X, Y: Integer);
4.  procedure FormPaint(Sender: TObject);
5.  procedure FormMouseUp(Sender: TObject; Button: TMouseButton; Shift: TShiftState; X, Y: Integer);
6.  procedure FormMouseDown(Sender: TObject; Button: TMouseButton; Shift: TShiftState; X, Y: Integer);
7.  procedure FormDestroy(Sender: TObject);

위의것이 아래와 같이 바뀐다.

1.  procedure Button1Click(Sender: TObject);
2.  procedure FormCreate(Sender: TObject);
7.  procedure FormDestroy(Sender: TObject);
6.  procedure FormMouseDown(Sender: TObject; Button: TMouseButton; Shift: TShiftState; X, Y: Integer);
3.  procedure FormMouseMove(Sender: TObject; Shift: TShiftState; X, Y: Integer);
5.  procedure FormMouseUp(Sender: TObject; Button: TMouseButton; Shift: TShiftState; X, Y: Integer);
4.  procedure FormPaint(Sender: TObject);

Case Sensitive 옵션을 설정 시 정렬하기는 소문자와 대문자의 차이를 고려한다. Ignore Space 옵션으로 설정 시 여러 개의 빈 칸(space)을 하나의 빈 칸으로 취급한다.

다음 메뉴 옵션인 Edit ⇒ Uppercase selection 은 선택된 텍스트 내 모든 문자를 대문자로 변환하고, Edit ⇒ Lowercase selection 은 문자를 모두 소문자로 변환한다.

식별자 이름과 키워드의 일관된 대·소문자 표기법(casing)은 코드의 명료성을 증가시키고 식별자를 쉽게 검색할 수 있도록 해준다. 소스 코드를 쓰는 동안 포맷하지 않는 경우 추후에 포맷할 수 있다.

Edit ⇒ Tabs to spaces in selection 은 Environment ⇒ Options... ⇒ Editor ⇒ General ⇒ Indent and Tabs ⇒ Tab widths 로부터 설정을 이용해 탭(tab)을 공백(space)으로 변환한다. 공백의 수는 정해져있지 않지만 tabulator의 남은 공간을 채울 필요가 있다. 선택한 텍스트에서 한 행의 문자가 80자를 초과하는 경우 Edit ⇒ Break lines in selection 옵션을 이용해 워드랩(word-wrap)할 수 있으며, 다음 행부터 시작된다. 워드랩이 실행되기 전에 행의 최대 길이는 Environment ⇒ Options... ⇒ Editor ⇒ Display ⇒ Right margin 에 설정된 값이다. 기본 값인 80을 원하는 값으로 수정할 수 있다. IDE는 클립보드의 내용 삽입뿐 아니라 다른 요소들도 삽입도 허용한다. Edit ⇒ Insert from Character Map 은 표준 키보드 키로 입력할 수 없는 특수 문자의 입력을 가능하게 한다. 문자 맵(Character map)은 두 페이지로 나뉘는데, 하나는 ANSI 문자이고 하나는 유니코드용으로, 원하는 문자로 빠르게 접근할 수 있도록 해준다. 문자를 한 번 클릭하면 코드 내에서 커서 앞에 문자가 삽입된다.

Edit ⇒ Insert text를 사용 시 제공하는 하위메뉴, CVS keyword, General, Insert ToDo를 통해 사전에 정해진 단어나 문구(phrase)를 (보일러 플레이트 텍스트) 삽입할 수 있다. CVS keyword는 버전 제어 시스템에 구체적인 제어 단어를 삽입 시 사용된다. 하위메뉴에 열거된 각 제어 단어의 의미는 버전 제어 시스템의 문서를 참고한다.

General 하위메뉴는 유닛에 포함시키고자 하는 다양한 문서 요소들과 텍스트 GUID를 생성 및 삽입시키는 기능을 제공한다. Insert ToDo 는 사용자가 ToDo note의 상세 내용을 입력할 수 있는 대화창을 보여주는데, 이는 이후에 에디터의 현재 커서 위치에 삽입되는 ToDo comment로 포맷된다. 사용자는 View ⇒ ToDo list 를 통해 사용자의 모든 ToDo notes를 검토할 수 있다.

소스 코드가 너무 길거나 너무 복잡해지면 코드의 섹션을 구분된 프로시저로 구성해야 한다. 여기에 Edit ⇒ Extract procedure... 를 이용할 수 있다. 아래와 같은 예제에서,

procedure DoSomething;
begin
  CallSomething;
end;

CallSomething; (;도 포함) 행을 선택하고 Extract 프로시저 옵션을 선택하면 그림 3.8에 나타나는 대화창이 표시된다.

그림 3.7: 문자 맵에서 이용 가능한 문자, Edit ⇒ Insert from Character Map을 통해 접근

그림 3.8: Edit ⇒ Extract procedures… 대화창

Procedure 라디오 버튼을 선택하고 Name of new procedure에 NewProc을 입력하면 코드는 다음으로 변경된다:

procedure NewProc;
begin
  CallSomething;
end;

procedure DoSomething;
begin
  NewProc;
end;

선택한 코드에서 새로운 프로시저가 생성되고, 본래 코드는 새로운 프로시저로의 호출로 대체된다. Extract procedure... 은 사용된 변수는 무엇이든 살펴본 후 자동으로 파라미터 리스트와 로컬 변수를 생성한다. 예를 들어, Form1에 대한 해당 메소드를 고려해보자:

procedure TForm1.DoSomething(var Ernie, Bert);
  var
  i: Integer; // comment
begin
  Ernie := Ernie + Bert;
  for i:= Ernie to 5 do begin
  end;
end;

for 루프(loop)를 선택하고 새로운 프로시저 NewProc를 생성한다. 변수 i는 선택된 코드에서만 발견되기 때문에 새로운 프로시저로 이동한다. Ernie는 선택된 코드 외부에서 사용되므로 파라미터가 된다.

procedure NewProc(const Ernie: Integer);
  var
  i: Integer; // comment
begin
  for i:= Ernie to 5 do begin
  end;
end;

procedure TForm1.DoSomething(var Ernie, Bert: Integer);
begin
  Ernie := Ernie + Bert;
  NewProc(Ernie);
end;

변수 i 뿐만 아니라 주석문 또한 새로운 프로시저로 이동된다. Pascal은 매우 광범위한 언어이므로 Extract procedure가 가능한 파스칼 구조를 모두 다 지원하지는 않음을 발견할 것이다.

그림 3.9: 검색 메뉴

검색하기

객체 지향 프로그래밍은 전체적 디자인이 더 많은 객체를 모듈화할수록 복잡성이 증가한다는 단점이 있다. 따라서 사용자가 소스 코드의 키 비트(key bit)를 빠르게 위치시킬 수 있는 강력한 검색 기능의 이용성이 매우 중요해진다. 라자루스의 오픈 소스 특성에서 장점 중 하나는 사용자의 코드뿐만 아니라 소스 코드를 검색할 수 있다는 점이다. 사용자는 정확한 스펠링이 알려지지 않은 부분 기억된(half-remembered) 식별자를 검색할 일이 생길 것이다. 라자루스는 개발자가 검색 필드에 사용할 수 있는 정규 표현식으로 된 집합을 제공함으로써 수많은 가능한 스펠링 중에 하나가 들어맞길 기다릴 필요성을 없앤다.

메타문자	의미
\	search에게 뒤에 따라오는 메타문자(metacharacter)를 리터럴(literal) 문자로 처리할 것을 알린다.
^	행의 시작을 의미한다.
.	모든 문자를 의미한다 (행의 시작은 제외). 예: a.c는 abc, aBc, a3c 등을 의미하고 $는 행의 끝을 의미한다.
|	변경.
()	그룹화, 예: (abc) + 는 abc, abcabc, abcabcabc 등을 의미한다.
[]	문자 집합을 정의, 예: [abc], [a-z], [a-zA-Z0-9]
[^]	문자의 역 집합(inverse set), 예: [^a-z].
표 3.1: 정규 표현식 검색에 사용되는 특수 문자의 의미 (메타문자)

백 슬래시 (＼)는 특수 문자의 의미를 되돌리는 데 사용하므로, 점(point)은 일반 텍스트로 돌아간다. 백 슬래시 뒤에 붙은 일부 심볼(symbol)은 검색 시 특별한 의미를 지닌다.

메타문자	의미
\.	.(dot)을 나타낸다.
\d	0부터 9까지 숫자를 나타낸다.
\D	숫자가 아닌 문자를 나타낸다.
\s	빈 공간이나 제어문자를 나타낸다 (><, #9, #10, #12, #13).
\S	빈 공간이 아닌 (non-empty) 또는 비 제어 문자를 나타낸다.
\w	알파뉴메릭(문자와 숫자가 섞인) 문자를 나타낸다.
\W	비-알파뉴메릭 문자를 나타낸다.
\b	단어 구분 문자(word delimiter)를 나타낸다.
\B	비 단어 구분 문자를 나타낸다.
\A	행의 시작을 나타낸다.
\Z	행의 끝을 나타낸다.
표 3.2: 정규 표현식에 이용 가능한 심볼

하나 또는 이상 회수에 일치한다.

심볼	정규 표현식에서 허용하는 반복(repeat) 횟수
*	어떠한 회수든 일치하며, none도 포함한다.
?	0 또는 하나의 일치 문자.
{n}	정확히 n회에 일치한다.
{n,}	최소 n회에 일치한다.
{n,m}	최소 n회에 일치하지만 m회 이하이다
표 3.3: 정규 표현식 가중법(weightings).

일부 대화창에서는 대화 상자로 Simple Syntax를 활성화하여 다른 사용자 프로그램이 사용하는 wildcards를 사용할 수 있게 한다. 간단한 프로그램식은 아래 정규 표현식으로 내부적으로 변환된다:

. 이것을 ＼.

• 이것을 .*

? 이것을 . , 이것을 ｜

이것을 ｜

Search ⇒ Find 와 Search ⇒ Replace 로 표시되는 대화창은 기본적으로 동일하다. [Ctrl]+[F] 키를 이용해 호출하면 교체 옵션과 토글이 비활성화되고, [Ctrl]+[R]로 호출 시 활성화된다. Text to Find 와 Replace With 콤보 상자는 가장 최근 검색한 텍스트와 필터를 포함한다. 아래 방향키 (↓)를 이용하여 히스토리로 돌아가 이전에 검색한 텍스트를 선택할 수 있다. 팁: 아래 옵션을 이용해 커서에 위치한 단어로 대화창을 미리 채워놓을 수도 있고, 아니면 빈 공간으로 남길 수도 있다. Environment ⇒ Options... ⇒ Editor ⇒ General ⇒ Misc ⇒ Find text at cursor.

검색된 텍스트의 해석에도 여러 개의 설정이 있다:

• 대.소문자 구분. 대문자와 소문자를 구별한다 (a와 A는 다름).
• 온전한 단어만. 발견한 텍스트는 단어의 시작에서 시작하여 단어 끝에서 끝나야 한다.
• 정규 표현식. 검색 텍스트는 정규 표현식을 포함할 수 있다.
• 다중행 패턴. 검색은 행의 끝에서 중단되지 않으므로 발견한 텍스트는 하나 이상의 행을 포함할 수 있다. 소스 에디터로부터 다수의 행을 복사하여 Text to Find 필드로 붙여넣기 할 수 있다. 정규 표현식을 사용 시 백 슬래시와 n의 조합, \n은 검색할 행의 끝을 상징한다.
• Prompt on replace: 대체(replace) 실행을 승인할 것인지 물을 것이다 (Replace 대화창에서만 활성화 가능).

Origin 섹션에서는 검색을 어디서 시작할 것인지 설정할 수 있다:

• 커서부터 시작. 검색이 커서 위치부터 시작된다. 방향은 전방향이며 검색은 파일의 끝에서 완료된다.
• 전체 범위. 검색 방향은 전방향이며 검색은 파일의 시작부터 끝까지 진행된다.

Scope 섹션은 검색의 범위를 결정한다.

• Selected text. 선택된 텍스트만 검색한다.
• Global. 전체 파일을 검색한다.
  팁: 여러 개의 파일을 검색하려면 Search ⇒ Find in files... 메뉴를 사용하라.

Direction 섹션은 검색 방향을 설정하도록 해준다:

• Backwards search. 파일을 끝에서부터 시작해 시작 부분까지 검색한다. 모든 행을 좌측에서 우측으로 검색한다. (라자루스는 우측에서 좌측으로 쓰인 언어도 IDE에서 사용할 수는 있지만, 설정이 어떻건 파스칼 소스는 항시 좌측부터 우측으로 쓰여야 한다)
• Forward search. 시작부터 끝까지 파일을 검색한다. 모든 행은 좌측에서 우측으로 검색된다.

Search ⇒ Find Next (주로 [F3] 키로 호출)는 사용자가 마지막으로 입력한 검색 텍스트에 대해 새로운 검색을 시작하며, 검색이 실패하지 않는 한 어떠한 대화창도 표시되지 않는다. 대체 실행 이후에는 다음 일치 결과(hit)가 대체될 것이다 (승인 메시지에 동의할 경우). Search ⇒ Find Previous ([Shift]+[F3])은 검색 텍스트의 이전 일치 결과(hit)를 위치시킨다. 대체 실행이 끝난 후 사용자가 승인 시 이전 일치 결과도 대체될 것이다.

Search ⇒ Find in files 메뉴는 검색을 설정하고 다중 파일의 검색을 위한 필터를 대체하도록 해준다. 텍스트 파일만 검색한다는 점이 논리적이다. 여기에는 소스 텍스트 파일을 포함하지만 (.pas, .pp, .inc, .rc, .po, .txt 등) 컴파일된 파일이나 라이브러리는 포함하지 않는다. 모든 옵션을 적절하게 설정했다면 Find 버튼을 클릭하여 검색을 시작할 수 있다. 일치하는 결과는 Search Results 창에 표시될 것이다. 해당 창은 후에 View ⇒ Search Results를 이용해 원할 때마다 열 수 있는데 마지막 검색 결과를 기억하기 때문이다. unit 혹은 end 와 같은 일반적인 용어로 검색하면 무용지물인 이유는 결과로 나오는 일치 결과(hit) 리스트가 매우 길기 때문이다. 따라서 이러한 성과 없는 검색을 막기 위해 Cancel 버튼이 제공된다.

Text to find 필드에서 Search 가 텍스트를 해석하는 방식에 영향을 미치는 몇 가지 설정이 있다.

• 대.소문자 구분. 대문자와 소문자를 구별한다 (a와 A는 다름).
• 온전한 단어만. 발견한 텍스트는 단어의 시작에서 시작하여 단어 끝에서 끝나야 한다.
• 정규 표현식. 검색 텍스트는 정규 표현식을 포함할 수 있다.
• 다중행 패턴. 검색은 행의 끝에서 중단되지 않으므로 발견된 텍스트는 하나 이상의 행을 포함할 수 있다. 소스 에디터로부터 다중행을 복사하여 Text to Find 필드로 붙여넣기 할 수 있다. 정규 표현식을 사용 시 백 슬래시와 n의 조합, \n은 검색할 행의 끝을 상징한다.

검색을 실행해야 하는 장소를 Where 섹션에서 설정할 수 있다.

• Search in all files in project: 프로젝트에 포함된 모든 파일을 검색한다.
• Search all open files: 에디터에 열린 모든 파일을 검색한다.
• Search in directories: 어떠한 검색 디렉터리든 명시하고 File mask 필드를 이용해 추가 설정을 명시할 수 있다. 제공되는 기본 필터를 이용해 검색을 표준 파일 타입으로 제한할 수 있다. 콤보 상자는 사용자가 마지막으로 사용한 필터들을 포함한다.
• Include sub directories 확인상자는 큰 디렉터리 또는 알려지지 않은 디렉터리를 검색할 때 중요하다. 상자를 체크하면 모든 하위디렉터리를 재귀적으로 검색한다. 오랜 시간이 소요될 수 있다.

Search 메뉴는 검색 옵션 외에도 여러 개의 jump 옵션을 포함한다. 따라서 특정 행 번호, 발생한 오류, 또는 북마크 지점으로 (당연히 북마크를 설정하는 옵션도 있겠다) 건너뛸 수 있다. 건너뛰기(jump)는 전방향 또는 후방향으로 가능하고, 현재 파일의 처음 또는 끝으로 이동할 수도 있다.

File Declaration at cursor 옵션은 커서 아래의 메소드 또는 식별자가 선언된 위치로 데려가고, 식별자가 현재 파일 외부에서 선언된 경우 해당하는 파일을 연다. 해당 옵션은 특히 그것이 선언된 곳에서만 찾을 수 있는 식별자 정보가 필요하나 도움이 될 만한 툴팁(tooltip)이 없을 때 유용하다.

유닛이 다른 유닛을 참조할 경우 (uses 절을 통해 연결) 다른 유닛의 이름 위에 커서가 위치할 때 Open filename at cursor를 이용해 유닛을 열 수 있다.

그림 3.10: Search→Find Identifier References…는 식별자를 위치시킬 수 있는 (선택적으로 재명명할 수 있는) 대화창을 표시한다.

라자루스는 Search menu options, Find Identifier References…, Rename Identifier…를 이용해 식별자를 검색하도록 (재명명도 가능) 해준다.

해당 옵션을 실행하려면 소스 코드 내에 식별자 위에 커서를 위치시켜야 한다. Rename to area는 Rename Identifier 메뉴에서 호출되었을 때만 활성화된다. 검색할 식별자의 이름은 Identifier 그룹 상자의 제목에 표시된다. 아래는 해당 유닛 또는 그 include 파일 내에서 식별자가 발견된 위치를 표시한다.

Rename은 식별자의 이름을 변경할 필요가 있을 때 새로운 이름을 입력하도록 해준다.

검색은 구체적 파일 또는 디렉터리로 제한된다:

• 현재 유닛 내: 현재 유닛 내에서만 검색하고 재명명한다.
• 메인 프로젝트: 현재 프로젝트 파일 내에서만 검색하고 재명명한다.
• 현재 유닛을 소유하는 프로젝트/패키지: 프로젝트(또는 패키지)를 선택하고 나면 해당 프로젝트 (또는 패키지) 내 모든 파일에 대해 검색과 재명명을 실행한다.
• 모든 개방 패키지와 프로젝트: 위와 같지만 좀 더 광범위한데, 검색 및 재명명이 모든 의존적 패키지 또는 프로젝트까지 변경하기 때문이다.

검색에 더 많은 파일을 포함해야 하는 경우 Additional files to search 필드에 입력할 수 있다.

Search in comments too 확인상자에서 Search를 이용해 주석문의 검색도 추가할 수 있다.

그림 3.11: 프로시저 리스트

프로시저 리스트(Procedure List)는 현재 유닛의 모든 프로시저와 메소드에 대해 엄청나게 빠르게 정렬된 리스트를 만들고, 리스트에 이름을 더블 클릭하여 선택된 프로시저의 implementation 부로 (include 파일이더라도) 건너뛰도록 해준다. 대화창 상단의 툴바에서 속도 버튼을 이용해 여러 개의 함수를 호출할 수도 있다. 프로시저 리스트가 너무 길어지면 부분적 메소드 이름을 타입하여 동적으로 리스트를 필터해주는 Search 필드의 도움을 받아 구체적인 메소드 또는 프로시저를 검색할 수 있다.

보기 메뉴

보기(View) 메뉴는 다수의 특정 창을 호출하도록 (또는 특정 창을 볼 수 없을 경우 맨 앞으로 가져오도록) 허용한다.

보기 메뉴의 첫 두 항목인 오브젝트 인스펙터와 소스 에디터에 관한 상세한 정보는 3.2장에서 찾을 수 있다.

그림 3.12: 메시지 창

Messages 창은 기본 적으로 소스 에디터 아래에 위치하지만 원하는 위치로 이동할 수 있다. Messages 창은 라자루스의 코드툴(Codetools), 프리 파스칼 컴파일러, 그리고 링커로부터 메시지를 표시한다. 이러한 메시지들은 필터링되므로 라자루스 개발자가 중요하다고 생각하는 메시지만 표시된다. 컨텍스트(Context) 메뉴를 이용해 (Messages 창 안의 어디서든 오른쪽 마우스 클릭) 메시지를 클립보드에 복사하여 틈이 날 때 살펴볼 수 있다.

메시지 창이 재시작 시 비어있기 때문에 라자루스 자체를 컴파일 할 때는 Restart after building IDE (Tools ⇒ Configure "Build Lazarus"…) 확인상자를 비활성화 시키길 원할지도 모른다.

소스 코드에서 단순한 클릭 한 번으로 메시지가 참조하는 장소로 건너뛸 수도 있다. Environment ⇒ Options... ⇒ Environment ⇒ Desktop ⇒ Jump from messages to source line on double click (또는 single click)에서 건너뛰기를 단일 또는 더블 클릭으로 설정할 수 있다.

Messages 창의 컨텍스트 메뉴는 여러 유용한 실행을 제공한다. Clear은 리스트에서 메시지를 모두 제거한다. Copy selected messages to clipboard는 선택부분을 클릭보드로 복사한다. 버그를 보고하고 있다면 정확한 메시지가 중요할 것이다. Copy all shown messages to the clipboard는 모든 표시된 메시지들을 복사하지만 (모두 스크롤해야함) 라자루스에 의해 숨겨진 메시지는 제외한다. 모든 가능한 메시지를 보고 싶다면 Copy all shown and hidden messages to clipboard를 선택하면 된다. 그림 3.12에 나타나는 메시지 뒤에는 다음 컴파일러 출력이 숨어 있다:

Hint: Start of reading config file C:\Lazarus\fpc\2.4.3\bin\i386-win32\fpc.cfg
Hint: End of reaind config file C:\Lazarus\fpc\2.4.3\bin\i386-win32\fpc.cfg
Free Pascal Compiler version 2.4.3 [2011/02/05] for i386
Copyright (c) 1993-2010 by Florian Klaempfl
Target OS: Win32 for i386
Compiling HelloLazarusConsole.lpr
Compiling resource C:\LazProjects\LazarusBook\lib\i386-win32\HelloLazarusConsole.or
Linking HelloLazarusConsole.exe
47 lines compiled, 2.5 sec , 1205744 bytes code, 295266 bytes data
2 hint (s) issued
Project "HelloLazarusConsole" successfully built

말(Help) 옵션은 사용자가 메시지를 먼저 선택하였는데 어딘가에 위치한 지원자(volunteer)가 특정 오류에 관한 정보를 제공한 경우 오류에 관한 더 많은 정보를 제공한다. 종종 메시지를 클립보드로 복사하는 것을 제한하지만 모든 메시지를 항상 파일로 저장할 수 (Save all messages to file) 있다. 사용자는 명시한 텍스트 파일로 직접 메시지를 저장한다 (숨김 메시지도 포함)

그림 3.13: 코드 익스플로러를 이용한 소스 코드 네비게이션

Code Explorer는 유닛의 세부 내용과 조직(organisation)을 볼 수 있도록 도와주고 소스 코드에 걸쳐 빠른 네비게이션을 돕는 툴이다. Code 탭은 유닛의 파스칼 구조를 보여준다 (타입, 변수, 상수, 클래스 등). 요소를 클릭하면 소스 코드 내 해당 위치로 건너뛴다.

필터는 엔트리를 제한하여 필터에 일치하는 엔트리만 표시하도록 해준다. Refresh 버튼은 사용자가 소스 코드를 변경 시 리스트를 갱신한다. 사용자는 툴 스피드버튼을 (스패너와 스크루드라이버 아이콘이 있다) 이용하여 코드 익스플로러를 구성하는 다양한 설정을 편집할 수 있다. 코드 익스플로러 설정은 Environment ⇒ Options... ⇒Code Explorer 에서도 구성 가능하다.

Directives 탭은 컴파일러 지시어의 발생을 표시한다. 다시 말하지만, 특정 지시어를 클릭하면 소스 코드 내 위치로 데려다준다.

FPDoc Editor는 사용자의 코드를 문서화하고 기존의 문서를 볼 수 있도록 도와주도록 설계되었다. 사용자는 유닛의 interface 부에서 선언된 모든 식별자에 대해 주석문과 설명을 추가할 수 있다. 생성된 XML 도움말 파일은 (<unitname>.xml) 주로 'docs' 하위디렉터리에 저장된다. 그러한 파일에서 도움말 정보를 이용할 수 있는 경우 커서를 문서화된 식별자 위에서 움직이면 툴팁 창에 자동으로 표시된다.

그림 3.14: 보기 메뉴의 Restriction Browser

Restriction browser는 라자루스가 지원하는 다양한 위젯 셋에서 비주얼 컴포넌트의 행위(behavior)에 관한 상세한 정보를 표시한다. 크로스 플랫폼 GUI 프로그래밍은 사용자가 특정 위젯 셋에서는 일부 프로퍼티를 제한하며 특정 프로퍼티는 일부 플랫폼에서는 전혀 존재하지 않을 수도 있다는 사실을 이해하길 요한다. 아마도 미래에는 현재 제한되는 프로퍼티에 대한 해결책을 발견하여 전체적인 플랫폼 독립성을 허용할는지도 모른다. 단, 이를 제외한 다른 프로퍼티들은 해당하지 않을 것이다.

Filter 섹션은 (스피드버튼의 행) 원하는 위젯 셋(들)을 설정하도록 해준다 (기본 설정: 모든 셋). 의심이 가는 프로퍼티는 좌측 리스트에 표시되고, 우측의 메모는 관련 정보를 보여준다. 현재 이 정보는 영어로만 제공된다.

그림 3.15: 설치된 컴포넌트를 열거하는 3 페이지, View ⇒ Components를 통해 접근 가능

View ⇒ Components 는 구체적(설치된) 컴포넌트를 검색하여 현재 폼에 삽입하도록 해주는 창을 보여준다. 하단 부분은 세 페이지로 나뉘어 컴포넌트 리스트를 구성하는 대안 방법들을 제시한다. List는 모든 컴포넌트를 알파벳순으로 정렬하고, Palette는 다양한 컴포넌트 팔레트 탭에서 그 위치에 따라 표시한다. Inheritance는 컴포넌트 상속 계층구조(hierarchy)를 보여준다 (따라서 컴포넌트 팔레트에서 이용할 수 없는 많은 컴포넌트도 포함됨). 상단 검색 필드는 이름에 현재까지 타입이 정해진 문자를 포함하는 컴포넌트로 리스트를 제한한다. 선택한 컴포넌트를 더블 클릭하면 소스 코드 내 커서 위치에 컴포넌트의 새 인스턴스를 삽입하고, 추가적으로 비주얼 컴포넌트가 관련 폼에 추가된다.

Jump History... 창은 현재 세션에서 사용자가 실행한 점프(jump)를 모두 기록한다. 해당 항목을 클릭하면 소스 코드 내 해당 위치로 다시 데려간다.

Units와 Forms 메뉴 옵션은 프로젝트 내 사용된 모든 유닛과 폼을 각각 열거한다. 엔트리를 더블 클릭하면 선택한 파일을 소스 에디터 (유닛에 해당) 또는 폼 디자이너 (폼에 해당) 내에서 연다.

ToDo list는 프로젝트 내 모든 파일로부터 모든 ToDo 엔트리를 보여준다 (즉, 패키지 유닛을 포함해 현재 .lpr 파일에 열거된 모든 파일). Refresh는 다시 ToDo 항목에 해당하는 프로젝트 파일을 검색한다.

리스트에서 ToDo 엔트리를 더블 클릭하면 (또는 엔트리를 선택하여 Go를 클릭하면) 소스 내 ToDo 엔트리로 건너뛴다.

Unit Dependencies 메뉴 옵션은 해당 의존성을 계층구조식 순서로 표시하는 대화창을 연다.

그림 3.16: 유닛 의존성 대화창

프로젝트가 열려 있을 때 Unit Dependencies을 열면 기본 값으로 프로젝트의 메인 소스 코드 파일이 (.lpr) 열린다. 다른 파일들은 파일을 선택하여 Open 버튼을 이용해 연다. 내용을 변경되면 Refresh가 리스트를 재빌드할 것이다. Project 버튼은 메인 프로젝트 파일을 선택한다.

하위엔트리는 uses 절에 열거된 유닛이다. 나타나면 interface 부와 implementation 부가 적색 선으로 분리된다. 순환 참조는 이중 화살표(double arrow)의 아이콘으로 표시된다. 유닛을 더블 클릭하면 에디터에서 열린다.

Unit information 메뉴 옵션은 소스 에디터에 현재 열린 유닛에 관한 정보를 보여주는 창을 표시한다. 대화창은 4개의 페이지로 구성된다: General, Unit paths, Include paths, Source Paths.

General 페이지는 유닛에 관한 전체적인 정보를 포함한다. Name은 소스 코드 내에서 참조되는 유닛의 이름, 또는 확장이나 경로를 제외한 파일명이다. Type은 하이라이터(highlighter)의 타입이다 (에디터의 컨텍스트 메뉴를 통해 변경 가능). In Project는 유닛이 프로젝트의 일부인지를 표시한다. 이는 Project ⇒ Add editor file to Project 를 통해 Project 메뉴에서 변경할 수 있으며, Project ⇒ Remove from Project...Size 는 유닛의 크기를 바이트로 나타낸다. Lines 는 코드 행의 수, Path는 완전한 파일명이다. Included by는 유닛에 포함된 마지막 파일이다 (예: {$I filename.inc} 지시어). 이는 Include 지시어를 포함하는 유닛이 IDE에 의해 분석될 때 자동으로 설정된다. 이전 파일의 Include 지시어로 건너뛸 필요가 있다면 Search→Goto include directive를 사용하라. Clear include cache 버튼을 클릭하면 Included by 필드를 삭제한다:

Unit paths 페이지는 IDE에서 .ppu, .pas, .pp, .p 파일을 검색할 때 필요로 하는 유닛 경로를 모두 열거한다. 보통은 이러한 경로들이 컴파일러로 전달되지만 항상 그런 것은 아니다. 구성 파일에서 (fpc.cfg) 정의된 유닛 경로가 항상 여기서 표시되는 것은 아니다. 이러한 경로들은 Environment ⇒ CodeTools defines editor... 를 통해 구축되는 규칙을 따라 생성된다. 디렉터리 내 모든 파일은 동일한 검색 경로를 알고 있다 (유닛 경로, include 경로, ...).

프로젝트 디렉터리에 관한 한 모든 프로젝트 유닛 경로가 추가된다. 디렉터리가 패키지의 일부인 경우 패키지의 경로가 추가된다. 프로젝트와 패키지가 동일한 디렉터리에 저장되면 두 경로가 모두 추가된다. 따라서 프로젝트와 패키지는 각 디렉터리에 따로 저장할 것을 권한다. compiler 검색 경로와 IDE 검색 경로에는 차이가 있다 (보통은 그다지 중요하지 않다).

컴파일러는 일련의 검색 경로가 있는 디렉터리로 호출된다. 4개의 패키지를 사용하는 아래 프로젝트의 예를 살펴보면, 각 패키지는 그 파일들을 소스 디렉터리에 컴파일한다:

- /home/user/package1/package1.lpk
- /home/user/package2/package2.lpk
- /home/user/package3/package3.lpk (uses package1 and package2)
- /home/user/package4/package4.lpk (uses package1 and package2)

Package 3는 유닛 경로 /home/user/package1; /home/user/package2/ 를 이용해 /home/user/package3 에서 컴파일된다. 컴파일러가 /home/user/package2/ 디렉터리에서 유닛을 찾아 컴파일하면 /home/user/package3/ 의 경로를 포함해 모든 유닛 경로를 사용한다. 일반적으로 권장하지 않은 방법이기 때문에 표준 패키지가 output directory를 정의하는 것이다. 해당 예제에서는 패키지가 그 파일들을 소스 디렉터리로 컴파일한다고 가정한다. 컴파일러로 package4를 호출하면 다른 검색 경로를 가진 다른 디렉터리에서 시작되는데, /home/user/package1; /home/user/package2/ 의 유닛 경로를 가진 /home/user/package4/ 를 예로 들 수 있겠다.

컴파일러가 /home/user/package2/ 디렉터리에서 유닛을 찾아 컴파일하면 /home/user/package4/ 의 경로를 포함해 모든 유닛 경로를 사용한다.

결과가 경로의 순서에 따라 좌우되기 때문에 만족스럽지 못한데, package3이 package4 보다 이전에 컴파일 되거나 그 반대의 경우가 발생할 수 있다. 이는 사용자가 인식하는 것보다 더 많이 발생하며, 패키지가 동일한 이름을 가진 유닛들을 포함하는 경우 검색 경로 내 파일 경로의 순서가 중요해진다.

그림 3.17: Codetools Directory Values는 View ⇒ Unit Informaiton 메뉴 옵션을 통해 호출되는 유닛. 정보 대화창의 하단에 위치한 Show CodeTools Values 버튼으로 호출된다.

IDE는 이를 각 디렉터리로부터 검색 경로를 수집하여 이 문제를 해결한다. 예를 들자면, 라자루스 소스에 대한 검색 경로는 고유의 유닛 경로를 가질 뿐 프로젝트의 유닛 경로는 포함하지 않는다. 프로젝트의 일부가 아닌 디렉터리는 프로젝트의 유닛 경로를 얻지 않는다. 이렇게 Delphi-VCL과 Lazarus-LCL 소스는 동일한 이름의 유닛을 포함한다 하더라도 모호성(ambiguity) 없이 검색할 수 있다. Unit paths(두 번째 탭)에서 true는 Include paths (세 번째 탭), 즉 include 지시어 ( {$I filename.inc} 또는 {$INCLUDE filename.inc})를 이용해 명시되는 파일에 대한 검색 경로에도 true가 된다.

Source paths 탭에 열거되는 경로는 컴파일된 소스의 경로와 함께 Unit paths의 결과를 보여준다. 이에 대한 예를 아래 소개하겠다:

/home/user/project 에 프로젝트가 있고, /home/user/package/lib에 패키지가 있다. 프로젝트는 패키지를 결합(binding)한다. 패키지 소스는 /home/user/package에 위치하고 패키지의 결과 파일(.ppu)은 /home/user/package/lib에 위치한다.

프로젝트의 유닛 경로는 패키지의 출력 디렉터리에 대한 경로를 포함한다.

프로젝트를 컴파일하면 컴파일러는 패키지의 .ppu 파일을 찾지만 소스 파일은 (.pas) 찾지 않는다. 따라서 컴파일러는 패키지를 재컴파일 할 수 없게 되는데, 프로젝트의 컴파일러 설정은 아마도 패키지의 설정과 다를 것이므로 좋은 현상이다. IDE는 소스 파일을 찾아야 한다. IDE는 /home/user/package/lib이 패키지의 출력 디렉터리라는 정보를 알고 있기 때문에 패키지의 유닛 경로를 프로젝트의 소스 코드 경로로 추가한다. 이러한 조합을 Compiled Source Path라고 부른다. Show CodeTools Values 버튼은 대화창을 열어 이러한 값을 보여준다. Directory 섹션에서는 사용자가 보고 싶어 하는 CodeTools 값을 가진 디렉터리를 선택할 수 있다.

View ⇒ Toggle form / unit view는 디자이너에서의 폼과 에디터에서의 소스 코드로 포커스를 전환한다. [F12] 단축키도 같은 기능을 한다. 에디터에 더 많은 유닛을 열면 스위치가 활성화된 유닛에서 작동한다. Window 메인 메뉴를 끌어 내리면 모든 폼과 유닛이 열거되어 있으므로 해당 메뉴 리스트의 폼으로 전환할 수 있다. 아니면 키보드 [F12] 키를 눌러 에디터로 포커스를 두고 [Ctrl]+[Tab]을 눌러 다른 유닛으로 변경한 후 다시 [F12]를 누르면 유닛의 폼으로 빠르게 전환할 수 있다.

View ⇒ Search results 옵션은 라자루스를 시작한 후 최근 검색 결과를 모두 표시한다. 각 검색 결과는 구분된 행에 표시된다. 행을 더블 클릭하면 소스 내 동일한 행으로 데려간다. 여러 번의 검색을 완료하였다면 각 검색 결과는 구분된 페이지에 표시되는데 그 탭들은 사용된 검색 텍스트들을 제목으로 한다.

그림 3.18: 고정(Anchor) 에디터

Anchor Editor 메뉴는 비주얼 컨트롤을 폼의 특정 측면으로 (또는 서로에게) 고정(anchor)시키기 위한 파라미터의 설정 창을 연다. 컨트롤의 (좌측, 상단, 우측, 하단) 사면 각각은 다른 컨트롤 측면으로 고정시킬 수 있다. 예를 들어, TEdit의 좌측면을 TLabel의 우측면으로 고정시킬 수 있다.

고정된 라벨(label)이 이동하거나 크기가 변경될 때마다 고정된 에디트(edit)의 좌측면이 따라가며 결국 에디트(edit)가 라벨(label)과 똑같이 따라다닌다.

Enabled 확인상자는 컨트롤의 Anchors 프로퍼티와 일치한다. 상단면은 akTop enum을 사용하고 좌측면은 akLeft enum을 사용하며 나머지도 마찬가지로 적용된다. Sibling은 AnchorSide[xxx] Control 프로퍼티이다. 이는 빈값으로 (nil) 놔둘 수 있고, 컨트롤의 Parent 또는 형제(sibling)들 중 하나로 (동일한 Parent를 둔 컨트롤) 설정할 수 있다. 세 개의 속도 버튼은 AnchorSides[xxx].Side 프로퍼티이다. 테두리 간격(Border spacing)은 다섯 가지 프로퍼티를 가진다: Around, Left, Top, Right, Bottom. Around 프로퍼티는 중앙 편집 필드이다. Top은 상단 편집 필드에 속하며 나머지도 동일하게 적용된다. 바탕화면이 너무 작아지면 View ⇒ Component Palette와 View ⇒ IDE Speed buttons를 통해 컴포넌트 팔레트와 IDE 속도 버튼을 끌 수 있다 (필요 시 다시 켜는 것도 가능).

Debug windows 메뉴는 본장의 마지막 단락에 소개된 툴 / 디버거에서 상세히 설명하겠다.

그림 3.19: 패키지 링크 대화창

View ⇒ IDe internals에는 Package links 라는 하위메뉴가 있는데, 이는 라자루스에서 사용되는 패키지 링크를 보여주는 창을 연다. 세 가지 옵션을 조합하여 패키지를 필터링할 수 있다. 0.9.29 버전부터는 두 가지 하위메뉴를 더 이용할 수 있다: About FPC와 About IDE.

About IDE는 라자루스 버전과 다양한 전역 IDE 설정 및 환경 변수가 열거된 창을 보여준다. AboutFPC는 해당 정보와 함께 많은 FPC 설정에 관한 추가 정보를 보여준다.

그림 3.20: View ⇒ IDE internals ⇒ About IDE는 위의 정보를 보여준다.

프로젝트 메뉴

프로젝트란 무엇인가? 파스칼 프로그램을 빠르게 쓰려면 어떠한 텍스트 에디터든 프로젝트를 사용할 것이다. 당연히 라자루스 IDE에서도 프로젝트를 사용할 수 있다. 그 성능을 모두 이용할리는 만무할 것이다. 하지만 애플리케이션에 소스 코드가 여러 개의 파일로 나뉘고 리소스 파일이 더 추가되어 애플리케이션이 광범위해진다면 간단한 텍스트 에디터로 충분하지 않다. 게다가 라자루스와 같이 큰 프로젝트는 여러 명의 프로그래머들이 협력하여 작업하도록 요한다.

project는 애플리케이션이 필요로 하는 파일의 총체(totality)로 정의된다. 이는 모든 소스 코드 파일과 어떠한 프로젝트 설정 파일이든 포함한다. 예를 들어, 다음 파일들은 간단한 프로젝트의 일부가 될 수 있다:

• unit1.pas: Pascal 소스 파일
• unit1.ppu: 컴파일된 유닛
• unit1.lfm: unit1.pas에 의해 생성된 폼의 레이아웃 정보가 있는 파일 (오브젝트 인스펙터에서 설정)
• unit1.lrs: 생성된 리소스 파일 (윈도우 리소스 파일과 혼동하지 말 것)
• project1.lpr: 메인 프로그램 파일, 아래와 같은 모양을 할 수 있다:

  program project1;
  {$mode objfpc}{$H+}
  
  uses
    {$IFDEF UNIX}{$IFDEF UseCThreads}
    cthreads,
    {$ENDIF}{ENDIF}
    Interfaces, // this includes the LCL widgetset
    Forms
    { you can add units after this }, Unit1;
  
  begin
    Application.Initialize;
    Application.CreateForm(TForm1, Form1);
    Application.Run;
  end.
  

• project1.lpi: 메인 프로젝트 파일(Delphi의 .dpr 파일에 해당)
• project1.exe: 생성된 실행 파일

Project 메뉴는 프로젝트 특정적 설정을 변경하도록 해준다. 어떠한 프로젝트가 다른 프로젝트에서 (예: Lazarus IDE) 사용할 수 있는 기능을 제공할 경우 그것을 패키지라 부른다 (Package 메뉴 참고).

그림 3.21: 프로젝트 메뉴

Project 메뉴에서 맨 위 옵션들은 새 프로젝트를 열고, 저장하고, 생성하기 위한 옵션이다. File ⇒ Open을 사용해 각 파일을 열기보다 Open Project 를 사용하는 편이 프로젝트를 열기 수월하다.

그림 3.22: Project ⇒ Publish Project 대화창

Project→Publish Project로 프로젝트의 복사본을 생성할 수 있다. 이 방법은 사용자의 프로젝트에 대한 소스 및 컴파일러 설정을 다른 프로그래머들에게 전달하는 가장 쉬운 방법이다. Destination directory가 생성되고 삭제(clean)된다. 기본 값은 $(TestDir)/publishedproject/이다.

Command after 필드에 입력된 명령은 라자루스가 파일을 복사한 후에 실행된다. 이를 이용해 아카이브를 .zip 파일로 압축할 수 있다. 소스를 공유하되 수신자가 스스로 생성 가능한 (큰) 실행 및 기타 컴파일된 파일들은 공유 대상에 포함시키지 않고자 한다면 Ignore binaries 옵션을 체크하라. 두 개의 필터를 이용해 어떠한 파일을 게시(publish)할 것인지 정확히 명시할 수 있다. Include Filter는 복사될 파일을 명시한다. 어떠한 Include Filter도 사용하지 않는다면 모든 파일이 복사된다. Simple Syntax 옵션의 효과는 3.1.3절을 참고한다. Exclude Filter는 복사해서는 안 될 파일을 명시한다 (예: 백업 파일 또는 압축된 파일). 어떠한 Exclude 필터도 사용되지 않은 경우 모든 파일이 복사된다.

Save info of closed editor files를 이용하면 에디터에서 연 모든 파일에 관한 정보를 published .lpi 파일로 저장할 수 있다.

Save editor info of non project files를 체크하면 프로젝트에 속하지 않는 편집된 파일에 대한 정보가 published .lpi 파일로 저장된다.

그림 3.23: 프로젝트 인스펙터

프로젝트 인스펙터(Project Inspector)는 프로젝트의 파일과 의존성을 모두 보여주는 툴이다. 맨 앞 버튼은 선택된 파일 또는 패키지를 연다. 새 파일이나 의존성을 추가하려면 두 번째 [+]버튼을 클릭하라.

프로젝트로부터 파일이나 의존성을 제거하려면 세 번째 [-] 버튼을 클릭하라. 의존성에서 오른쪽 마우스를 클릭하면 옵션 범위를 보여주는 컨텍스트 메뉴가 나타난다.

프로젝트의 설정은 가장 우측에 위치한 버튼으로 접근할 수 있는데, 버튼을 클릭하면 프로젝트 옵션 대화창이 나타난다 (Project ⇒ Project Options... 를 통해서도 접근 가능).

프로젝트 옵션을 통한 변경 내용은 (Environment ⇒ Options... 설정과 반대로) 현재 프로젝트에만 적용된다.

그림 3.24: Project Options ⇒ Application 페이지.

Project Options 대화창의 Application 페이지는 여러 개의 애플리케이션 파라미터를 설정하도록 해준다. Title 필드에 입력되는 이름은 코드 내에 Application.Title := ‘A string value';로 설정할 수 있다. 제목의 표시는 운영체제에 따라 다양하다.

프로젝트의 아이콘은 프로젝트로부터 명시, 로딩(여러 개의 아이콘 포맷이 허용), 저장, 또는 (후에 마음이 바뀌면) 삭제하도록 해준다. 아이콘 크기도 여러 개의 플랫폼에 맞춰 조정할 수 있다.

Mac 개발자들은 Use Application Bundle for running and debugging (Darwin only) 옵션을 체크하여 IDE가 연결된 실행 파일(linked executable) 대신 애플리케이션 번들을 시작 또는 디버깅하도록 한다. (Darwin은 Mac OS X의 기반이다.) 이 설정은 다른 운영체제의 사용자에겐 적용되지 않는다. 애플리케이션 번들이 존재하지 않는 경우 Creat Application Bundle 버튼으로 생성할 수 있다.

윈도우 테마를 (XP 또는 그 이후 버전) 사용할 수 있으려면 manifest 파일이 필요하다. 이 파일은 Use manifest file to enable themes (Windows only)를 활성화시켜 생성할 수 있다. Target file name 필드는 생성된 실행 파일의 이름을 설정한다. 상대 경로를 포함한 경우 프로젝트 디렉터리 경로로 (예: .lpi 파일의 위치) 확장된다. 대화창의 하단에는 세 개의 버튼이 있는데 모든 탭에서 접근할 수 있다. OK는 변경한 내용을 저장하고, Cancel은 변경한 내용을 취소한다. Help는 프로젝트 설정에 관한 라자루스 위키 페이지를 연다.

Project Options 대화창의 Forms 페이지는 폼 설정을 변경하도록 해준다. 폼은 애플리케이션을 시작 시 자동으로 생성할 수 있다.

이를 활성화시키려면 Available forms 리스트에서 Auto-create forms 리스트로 폼을 이동시킨다. 해당 절차를 반대로 실행하면 폼이 자동 생성되는 것을 막을 수 있다. Application.CreateForm(FormX, TFormX)를 이용해 코드 내에 폼을 생성할 수 있다.

When creating new forms, add them to auto-created forms 확인상자는 이 코드를 작성할 수고를 아껴준다.

참고: 자동으로 생성된 폼은 자동으로 표시되지 않는다. 폼 디스플레이는 Visible 프로퍼티가 True로 설정되었을 때만 표시된다. 예를 들어, FormX.Show 또는 FormX.ShowModal 를 호출할 때 표시된다.

Project Options 대화창의 Miscellaneous 페이지는 여러 프로젝트 옵션을 설정하도록 해준다. 보통은 .lpr 파일이 프로젝트의 메인 유닛이다. 해당 업무를 Pascal 소스 (.pas) 파일이 맡게 된 경우 Main Unit is Pascal Source 설정을 활성화시켜야 한다.

Main Unit has Uses Section containing all Units of project 설정은 유닛이 프로젝트에 추가되거나 그로부터 삭제될 때마다 IDE가 메인 유닛의 uses 섹션을 업데이트하도록 강요한다.

Main Unit has Application.CreatForm statements 설정은 프로젝트에 새 폼이 추가될 때마다 IDE가 Application.CreateForm (FormX, TFormX)를 추가하고 폼이 제거되면 문장을 제거하도록 한다.

설정이 비활성화되면 IDE는 어떠한 CreateForm 문장도 추가, 삭제 또는 변경하지 않는다.

Main Unit has Application.Title statements 설정을 활성화할 경우, 프로젝트에 새 폼이 추가되면 IDE는 Application.Title: = SomeTitle; (Project Options→Application→Title 에 값이 있을 시)를 추가하고, 폼이 제거되면 문장을 제거한다. Title이 비어 있다면 문장은 제거된다.

Title 이 변경되면 행도 그에 따라 변경된다. 설정을 비활성화시키면 명령어는 무시된다 (Application.Title 문장은 삭제, 추가 또는 변경되지 않는다).

Project is runnable 설정은 디버거가 프로젝트를 호출할 수 있는지 여부를 결정한다 (원하는 플랫폼에서 디버거를 이용할 수 있다고 가정).

Always build(even if nothing is changed) 옵션이 비활성화되면 IDE는 시작 전에 프로젝트가 변경되었는지 검사한다.

변경되지 않았다면 컴파일을 건너뛴다.

이를 위해 라자루스는 컴파일러 설정, projectname.compiled 파일에 열거된 실행 파일명 및 일자, 프로젝트 인스펙터 내 열거된 파일의 파일 내용을 확인한다.

라자루스는 프로젝트 디렉터리 내 파일이나 fpc.cfg (프로젝트 인스펙터에 열거된 파일만 검사) 또는 어떠한 포함(included) 유닛도 검사하지 않는다.

이것이 바로 프로젝트에 포함되고 소스 에디터에서 열린다 하더라도 프로젝트 인스펙터에 열거되지 않은 포함 유닛에 발생한 변경내용은 무시되는 이유이다.

Save .lrs files in the output directory 설정은 생성된 리소스 파일을 출력 디렉터리에 저장한다. FPDoc Editor 페이지에서 사용자는 프로젝트의 문서화를 위해 생성한 FPDoc 도움말 파일에 대한 경로를 설정할 수 있다.

모든 프로젝트는 소스 에디터에서 연 파일에 관한 메타 정보(meta-information), 모든 북마크 셋, 파일을 통해 이동시킨 점프, 파일 실행 정보를 보유하는 현재 session을 가진다. 최신 편집 세션에 관한 정보는 원한다면 저장이 가능하다.

해당 기능에 관한 설정은 Project Options 대화창의 Session 페이지에서 찾을 수 있다. IDE는 에디터 정보를 저장하는데 (커서 위치, 헤더, 페이지 인덱스, 북마크, 점프 리스트) 닫힌 파일에 대한 에디터 정보도 저장시키며, Save editor info for closed files 확인상자를 활성화시키면 다음에 파일을 다시 열 때 복원시킨다.

Save editor info only for project files를 이용해 IDE가 각 프로젝트 파일에 대한 정보를 저장하도록 할 수 있다 (에디터 정보, 파일 실행 정보, 리소스 이름).

보통 IDE는 이 정보를 프로젝트 세션 정보와 함께 .lpi 프로젝트 파일에 저장한다 (또는 .lps 파일에 따로 저장).

해당 정보를 저장하지 않으려면 설정을 비활성화하라.

활성 프로젝트의 세션 정보를 저장할 위치는 아래와 같이 지정할 수 있다.

• Save in .lpi file: .lpi 에 저장 시 단점은 자주 변경되어 버전 제어를 복잡하게 만든다.
• Save in .lps file in project directory: 세션 정보가 .lpi 파일이 아닌 분리된 .lps 파일에 저장된다.
  .lpi 파일이 버전 제어의 대상일 때 (예: SVN) 유용하다.
• Save in the IDE config directory: 예: 프로젝트 디렉터리가 쓰기 보호되어 있을 때.
• Do not save any session info: 해당 옵션은 paranoid 개발자들에게 알맞을 것이다.

Version Info 페이지는 버전 정보를 실행 가능 파일에 어떻게 추가할 것인지를 제어한다.

모든 비윈도우 플랫폼에서 해당 기능을 신뢰할 수 있는 것은 아니다.

그림 3.25: Project Options ⇒ i18n 페이지

프로젝트의 국제화를 가능하게 하려면 Enable i18n 확인상자를 표시하고 Project Options 대화창의 i18n 페이지 PO Output Directory에 디렉터리 경로를 입력해야 한다. 프로젝트에 사용자가 정의한 모든 리소스 문자열은 후에 PO 출력 디렉터리에서 .po 파일로 변환된다.

첫 .po 파일은 프로젝트를 컴파일 할 때 자동으로 생성된다. 이후 사용자는 원하는 언어로 .po 파일을 해석할 수 있다.

컴파일러 옵션

Project Options 대화창은 프로젝트를 어떻게 빌드해야 하는지, 각 프로젝트에서 무엇을 개별적으로 설정할 수 있는지에 관한 상세한 정보를 담은 11페이지로 된 Compiler Options 을 제공한다.

Compiler Options 페이지의 다양한 필드에 설정된 값은 라자루스가 사용자의 명령어에 따라 컴파일을 제약하도록 컴파일러에 전달하는 파라미터가 된다. 명령 행으로부터 컴파일러를 호출 시 이러한 파라미터를 수동으로 입력해야 할 것이다. 이용 가능한 컴파일러 옵션에 관한 더 많은 정보는 프리 파스칼 프로그래밍 매뉴얼에 문서화되었는데 본 저서와 동일한 출판회사에서 발행하였다.

매크로 이름	의미
Col	소스 에디터에 활성화된 열(column)
Row	소스 에디터에 활성화된 행(row)
CompPath	환경 설정에 설정된 컴파일러 경로
curtoken	소스 에디터 내 커서에 위치한 문자
EdFile	소스 에디터 내 최근 파일의 이름
ExeExt	실행 가능한 파일 확장
FPCSrcDir	환경 설정에 설정된 FPC 소스 코드 디렉터리
LazarusDir	환경 설정에 설정된 라자루스 소스 디렉터리
LCLWidgetType	프로젝트가 사용하는 위젯-셋
TargetCPU	프로젝트 개발의 목표 CPU
Target OS	프로젝트 개발의 목표 운영체제
Src OS	Linux, Darwin용 Unix, win32, win64, winCE용 Win
FPCVer	FPC 버전 (라자루스 0.9.25부터 이용 가능)
LanguageID	IDE 언어, 예: 영어는 en, 독일어는 de
LangaugeName	IDE에서 사용되는 언어에 대해 네이티브, 해석된 이름, 예: 독일어 Deutsch
Params	활성 프로젝트의 run 파라미터
Prompt	사용자에게 값을 요청 (대화형 매크로)
ProjFile	활성 프로젝트에 대한 메인 프로그램 파일의 (.lpr) 완전한 파일명
ProjPath	프로젝트 디렉터리 (.lpi 파일의 디렉터리)
Save	소스 에디터에서 활성 파일을 저장
SaveAll	모든 개방 파일을 저장
TargetFile	활성 프로젝트의 출력 파일 (주로 실행 가능한 orpackage)
TargetCmdLine	run 파라미터로 실행 가능한 프로젝트
TestDir	환경 설정에서 시험 프로젝트를 위해 명시된 디렉터리
RunCmdLine	프로젝트를 시작하기 위한 명령 행
ProjPublishDir	활성 프로젝트가 게시될 디렉터리
ProjUnitPath	활성 프로젝트의 유닛 디렉터리
ProjIncPath	활성 프로젝트의 include 디렉터리
ProjSrcPath	활성 프로젝트의 소스 디렉터리
ConfDir	IDE가 그 구성파일을 저장하는 디렉터리
MakeExec	make 프로그램으로의 경로 (또는 BSD에서 gmake)
Project( )	아래 표시되는 여러 개의 값에 대한 매크로 함수:
Project(UnitPath)	프로젝트 인스턴스의 유닛 경로
Project(SrcPath)	프로젝트 인스턴스의 소스 경로
Project(IncPath)	프로젝트 인스턴스의 include 경로
Project(InfoFile)	프로젝트 인스턴스의 정보 경로
Ext( )	ExtractFileExt에 대한 매크로
Path( )	ExtractFilePath.Name( )에 대한 매크로. ExtractFileName에 대한 매크로.
NameOnly( )	ExtractFileNameOnly에 대한 매크로
MakeDir( )	AppendPathDelim에 대한 매크로
MakeFile( )	ChompPathDelim에 대한 매크로
Env(name)	(프로젝트나 디버거가 아니라) IDE로 전달된 환경 파라미터에 대한 매크로
PkgDir( )	파라미터로서 전달된 패키지-ID의 (.lpk 파일의 위치) 디렉터리에 대한 매크로
PkgSrcPath( )	파라미터로서 전달된 패키지-ID의 소스 경로에 대한 매크로
PkgUnitPath( )	파라미터로서 전달된 패키지-ID의 유닛 경로에 대한 매크로
PkgIncPath( )	파라미터로서 전달된 패키지-ID의 include 경로에 대한 매크로
PkgOutDir( )	패키지의 출력 디렉터리에 (예: .ppu 파일이 생성되는) 대한 매크로
표 3.4: 경로와 파일명을 요하는 대화창에 사용 가능한 매크로

Paths 페이지는 컴파일러와 협력하기 위해 IDE에서 필요로 하는 경로 설정을 포함한다. 상대 경로는 프로젝트의 (또는 패키지의) 경로로 확장된다. 이러한 경로들은 검색 경로에 추가된다.

패키지가 프로젝트 또는 패키지를 포함하면 그러한 검색 경로들도 포함된다. 상속된 검색 경로는 Inherited 페이지에서 볼 수 있다. 프리 파스칼 컴파일러는 추가 검색 경로들을 정의하는 고유의 구성파일인 fpc.cfg를 갖는다. 다중 검색 경로는 세미콜론으로 구분되며, 문장 앞 공백(leading space)은 무시된다. 이러한 경로에 Macros가 허용된다. 현재 이용 가능한 매크로는 표 3.4에 열거되어 있다(추후 라자루스 버전에서는 새 매크로를 추가되거나 기존 매크로가 제거될지도 모른다).

Other Unit Files는 프로젝트 또는 패키지의 파스칼 유닛을 위한 ( .ppu, .pp, .pas, .p) 검색 경로이다. 해당 경로는 컴파일러로 전달되고 컴파일러는 이를 유닛 경로로 추가한다. 유닛 또는 패키지가 프로젝트에 추가되면 유닛 경로는 자동으로 업데이트된다.

경고: 패키지에 .ppu 파일을 위해 구분된 출력 디렉터리가 있는 경우 그 소스 코드 디렉터리는 이 경로로 추가되어선 안 되며, 만일 추가 시 컴파일러는 새로운 .ppu 파일을 생성하여 프로젝트 디렉터리로 위치시킬 것이다. 이는 .ppu 파일에 대한 다중 인스턴스를 야기하여 때로는 잘못된 오류 메시지를 생성하는데 (예: ‘유닛을 찾을 수 없음…’) 그 원인을 추적하기가 힘든 경우가 종종 있다.

Include Files 는 Include 파일에 대한 검색 경로이다 (예: .inc 또는 .lrs 파일). 해당 경로는 프리 파스칼 컴파일러로 전달되어 컴파일러가 이를 Include 경로에 추가하는데, 이는 include 지시어 {$I filename.inc} 또는 {$INCLUDE filename.inc}에 의해 사용된다.

Other sources 는 파스칼 소스 파일에 대한 검색 경로이다. 이는 IDE에만 유효하고 컴파일러에선 유효하지 않다. .pas와 .ppu 파일에 대해 구분된 디렉터리를 가진 프로젝트의 경우, .ppu 디렉터리는 Other Unit Files 에 열거되고, .pas 디렉터리는 Other sources에 열거된다. 이렇게 컴파일러는 .ppu 파일을 검색하며 매번 생성하지 않아도 된다. 그리고 IDE는 그 검색과 선언 함수에 관한 소스를 검색할 수 있다.

Libraries는 라이브러리에 대한 검색 경로를 포함한다 (.DLL, .so, .dylib, 또는 .a 파일).

Unit output directory는 컴파일러가 모든 출력 파일을 보관하는 디렉터리이다 (예: .ppu, .o, 또는 .rst 파일).

Debugger path addition (none): 에 열거된 디렉터리들은 IDE 디버거가 소스 코드 파일을 (예: 인스턴스 유닛 또는 Include 파일) 검색할 때 디버거의 검색 경로에 추가된다.

Build modes 페이지는 사용자가 기본(Default) 빌드 방식(build mode)을 위한 매크로의 의미를 정의하고 다른 플랫폼을 대상으로 한 새로운 빌드 방식을 생성하도록 해준다. 크로스 컴파일 시 사용자는 기본 위젯 셋을 변경해야 하므로 LCLWidgettype 매크로에 대해 다른 위젯 셋을 선택할 수 있다. 이용할 수 있는 위젯 셋으로는, gtk, gtk2, win32 (win64), wince(또는 Windows CE), carbon (OS X용), qt, fpGUI, noGUI, cocoa(OS X용), android가 있다. 패키지의 기본 위젯 셋은 활성 프로젝트의 위젯 셋이다. 이는 다시 운영체제에 따라 좌우되겠다.

Parsing 페이지는 컴파일러의 분석과 사용자가 전송하는 코드의 해석을 관리하는 설정을 포함한다. Syntax mode 설정을 이용하면 소스 코드를 쓰는 것이 가능해져 다른 컴파일러에서 수용할 것이다. 하지만 컴파일된 유닛은 바이너리 호환이 되지 않는 컴파일러들 간 혼합될 수 없다. 이러한 설정에서 선택한 모드는 유닛 내에 어떠한 지시어도 주어지지 않을 때 사용된다. 유닛 지시어는 ({$mode objfpc}와 같은) 이 대화창에서 설정된 내용을 오버라이드한다.

Syntax mode를 선택했음에도 불구하고 컴파일러가 각 명령어를 처리하지 못할 수도 있다. 따라서 사용자는 해당 명령어를 교체할 수 있는지 검사해야 한다. 다양한 언어 모드에 대한 상세 정보는 프리 파스칼 매뉴얼에서 찾을 수 있다.

FreePascal:	클래스, 인터페이스, 예외가 부족한 본래 컴파일러 언어 (Object Pascal 모드와 반대).
Delphi:	Delphi 버전 7까지 호환 가능 (Delphi.Net은 제외).
Turbo Pascal:	Turbo Pascal의 범위까지 호환 가능 (16-비트 코드로 제한됨).
Object Pascal:	기본 값은 Delphi 모드에 가깝지만 Delphi 모드보다 더 엄격하다. Ansi 문자열은 기본 값이 아니다; 프로시저 변수와 이벤트 핸들러를 참조 시 @ 주소 연산을 사용할 필요가 있다; 이름 할당 제한 (클래스는 클래스의 프로퍼티와 동일한 이름을 가진 로컬 변수 또는 파라미터를 가질 수 없다).
Mac Pascal:	여러 Macintosh-Pascal 파생어와 호환 가능.

프로그래밍 방식에 대한 옵션

Syntax options 섹션에서는 오브젝트 파스칼 언어 규칙에서 몇 가지 예외가 허용된다:

C Style operators	파스칼 코드에 일부 공통 C 연산자를 (예: + = ) 허용한다.
Include Assertion Code	코드에 단언문(Assert statement)을 허용한다.
Allow LABEL and GOTO	은 어셈블러 블록에 라벨(label)이 사용될 때 필요하다.
C++ styled INLINE	inline 프로시저를 허용한다.
C Style Macros	매크로를 허용한다. 이를 비롯해 이전 옵션은 메소드가 텍스트 section을 교체하도록 지원한다
Constructor name	'init' (소멸자(destructor)는 'done'이어야 한다)은 자체 설명적이어야 한다.
Static Keyword in Objects	정적 메소드의 선언을 허용한다 (Self 변수를 필요로 하지 않음).
Strings	짧은 문자열이 기본 값 (Turbo Pascal과 호환 가능), Use Ansi Strings를활성화시켜 변경 가능하다.

어셈블러 스타일

경험을 바탕으로 프리 파스칼 어셈블러는 AT&T 어셈블러 프로그램식을 쓴다 (Default). Assembler style 섹션은 컴파일러가 어셈블러 명령어를 처리하는 방식을 변경할 수 있도록 해준다. Intel 섹션을 선택하면 처리 이전에 Intel 명령어를 내부에서 AT&T 포맷으로 강제로 해석한다.

그림 3.26: 프로젝트 옵션 대화창의 컴파일 옵션에서 선택한 코드 생성 페이지

Compiler Options의 Code generation 페이지는 컴파일러 검사, 목표 플랫폼, 최적화에 대한 옵션을 설정하도록 해준다. Checks 체크박스 옵션 중 하나를 활성화시키면 컴파일러는 해당 검사를 실행하기 위해 적절한 명령어를 추가하게 된다.

Stack은 스택 오버플로우(stack overflow)를 검사한다.

오버플로어가 발견되면 프로그램은 런타임 오류 202를 종료한다.

I/O 는 모든 입력과 출력 호출을 검사한다. 어떠한 오류든 런타임 오류를 발생시킨다.

Overflow는 정수 오버플로우(integer overflow)가 발생하면 런타임 라이브러리가 메시지를 전달하도록 (Overflow at xxx) 야기하여 런타임 오류 215로 프로그램을 종료한다.

Range는 Self 포인터를 검사한다. NIL인 경우 런타임 오류 210가 트리거된다. Verify method calls는 메소드를 호출할 때 가상 메소드 테이블(VMT)이 유효한지 검사한다.

유닛 스타일

함수로의 Smart Linking을 위해서는 Smart Linkable을 활성화시켜야 한다. 이는 컴파일러의 속도를 늦추지만 연결된 실행 파일(linked executable)의 크기를 유의하게 축소시킨다. 힙(heap) 크기는 현대 운영체제에서 문제가 되지 않지만 어찌되었든 라자루스는 Heap Size를 설정하도록 해주어 1024.0보다 큰 정수 값은 적절한 기본 값임을 의미한다.

목표 플랫폼

다른 플랫폼을 위한 애플리케이션을 생성할 경우 (크로스 컴파일) 목표 운영체제와 CPU를 Target OS 와 Target CPU family 에 입력할 수 있다. 크로스 컴파일 시에는 특히 사용할 컴퓨터에서 라이브러리와 기타 툴을 컴파일에 이용할 수 있는지에 특별한 주의를 기울여야 한다. 애플리케이션을 x86-호환 가능한 프로세서에서 (크로스 컴파일 시 이는 필수) 실행할 경우 Target processor에서 지원하는 프로세스 명령어를 선택할 수 있다. 기본 (최소) 설정은 i386 명령어 셋이다. 하지만 MMX 또는 좀 더 최근에 나온 명령어도 사용할 수 있다. 추가 명령어를 사용한다는 것은 생성되는 애플리케이션의 실행 속도는 빠르나 이동성은 감소함을 (구식 컴퓨터에서는 실행 불가할 가능성이 있음) 의미한다.

최적화

Optimizations Level 0은 어떠한 최적화도 이루어지지 않았음을 의미한다. Optimizations Level 1 (기본 설정)은 머신 코드의 국소적(peephole) 최적화를 의미한다. Level 2는 알려진 추가 하위 표현식(sub-expressions)을 제거한다 (최적화를 재로딩). Level 3은 더 많은 불확실한 최적화를 포함한다. Keep certain variables in registers는 레지스터 호출이 자주 사용하는 로컬 변수 또는 파라미터를 교체하고 빠른 실행을 가능하게 한다.

Uncertain Optimizations는 알려진 하위 표현식을 강제로 제거한다. 포인터를 이용해 변수로 호출할 경우 (직접 또는 간접) Uncertain Optimizations를 활성화하면 오류가 발생할 것이다. 이 최적화를 사용 시 오류가 생성되지 않도록 철저히 검사해야 한다.

Linking 페이지

그림 3.27: 컴파일러 옵션의 Linking 페이지

Linking 페이지는 프로젝트를 연결하기 위한 모든 설정을 포함한다. Debugging 섹션은 디버거가 라자루스와 작업하기 위해 어떠한 추가 정보를 생성할 필요가 있는지 정의한다. 디버그 정보를 포함시키면 실행 파일이 더 커진다.

옵션	효과
-g	GNU 디버거에 관한 정보를 추가한다.
-gl	행 번호 정보를 포함한다.
-gw	디버그 정보를 DWARF 포맷으로 생성한다 (http://dwarfstd.org).
-gh	heaptrc 유닛은 메모리 누수를 검사하는 툴이다. 해당 옵션을 활성화 시 컴파일된 프로그램이 끝나면 리포트를 생성하는 heaptrc 유닛을 포함한다.
-gv	valgrind는 (Linux/Darwin) 오류 잡기(trapping)와 성능 분석을 위한 툴이다. (www.valgrind.org) 해당 프로그램에 필요한 코드는 스위치 -gv로 생성된다.
-pg	컴파일된 프로그램으로 시작한 이후 출력 파일이 생성되어 GNU-프로파일러로 검사할 수 있다.
-Xs	모든 디버그 정보가 삭제된다.
-Xg	디버그 정보가 구분된 파일로 내보내진다.
표 3.5: 디버그 정보를 생성하기 위한 옵션

링크 스타일

Link Style 섹션은 Link Smart (-XX) 라는 하나의 옵션을 제공한다. 해당 옵션을 활성화하면 실제로 사용되는 소스 코드의 해당 부분만 연결되도록 야기한다.

실행 파일은 매우 작지만 컴파일에 오랜 시간이 소요되며 프로그램 디버깅이 더 힘들어진다.

목표 OS 특정적 옵션

현재엔 Target OS Specific Options 에 하나의 설정만 이용 가능하며 윈도우에만 연관된다. 해당 옵션을 활성화 시 애플리케이션 GUI만 만든다. 비활성화 시 추가로 빈 콘솔 창(DOS 상자)을 제공한다. 이는 시각적으로 방해가 될 수도 있는 반면 개발 도중에 오류 콘솔 출력과 디버그를 볼 수 있는 유용한 창이 될 수도 있다.

옵션

자체 확인상자에 모든 컴파일 스위치를 열거하기란 불가능하다. Options는 구체적인 설정 페이지가 없는 중요한 컴파일러 스위치로의 접근을 제공한다. 예를 들어, 파라미터가 특정 라이브러리를 결합하도록 -k 파라미터를 전달하기 위해 사용자가 Pass Options To The Linker 옵션에서 열거할 수 있다. 다중 스위치는 공백으로 구분되어야 한다.

Verbosity 페이지

Verbosity는 컴파일 시 Messages 창에 어떠한 메시지를 표시할 것인지 제어한다. 메시지가 너무 많으면 출력을 해석하는 복잡성이 증가하고 메시지가 너무 적으면 오류의 검색을 방해하기도 한다. 이 페이지에서 옵션을 신중하게 활성화/비활성화해야 만족스러운 매체를 발견할 수 있을 것이다. 스위치 -va (Show everything)는 응급 상황, 즉 불가해한 오류가 나타날 때 구현되는 반면 보통은 메시지가 수가 너무 많아 사용자를 압도할지도 모른다.

Stop after number of erros (-Se)는 stop을 컴파일하기 전에 오류의 수를 나타낸다. 기본 값은 단일 오류로 되어 있는데, 결국 애플리케이션이 성공적으로 컴파일되기 전에 그 오류를 해결해야 하기 때문에 이 설정이 보통 최선의 선택이다.

Message 페이지는 사용자가 직면할 가능성이 있는 모든 컴파일 메시지의 디스플레이를 (또는 숨김) 설정하도록 해준다. 모든 가능한 메시지 타입이 열거되어 있으며, 기본 값으로 (by default) 모두 활성화되어 있다. 필요하지 않은 메시지는 끌 수 있다 (예: (H) Parameter "$1" not used). parentheses에서 문자는 메시지의 타입을 보여준다: (H)는 힌트; (N)는 노트; (W)는 경고.

Other 페이지는 더 많은 파라미터를 컴파일러로 전달할 수 있도록 해주며, 다른 페이지에서는 설정할 수 없는 내용이다. 컴파일러 구성 파일도 명시 가능하다. 대부분 라자루스 사용자들은 기본 컴파일러 구성파일인 fpc.cfg에 의존한다. 검사를 목적으로 다른 구성 파일로 작업하길 원한다면 Use additional Compiler Config File은 제2의 구성 파일을 명시하도록 해준다.

Custom options 필드는 컴파일러 옵션을 설정하도록 해준다. 다른 페이지에서 설정할 수 없는 스위치용으로 제공된다. IDE는 검색 경로를 변경하는 사용자(custom) 옵션은 전혀 고려하지 않는다. 프리 파스칼 매뉴얼은 다수의 가능한 컴파일러 스위치를 열거한다.

Inherited 페이지는 패키지에서 상속되는 모든 컴파일러 설정을 보여준다. (패키지는 모든 컴포넌트를 제공한다.) 사용자는 여기서 프로젝트가 예상대로 기능하지 않을 때 검사할 수 있다. 특정 검색 경로 또는 설정은 어디서 시작되는가? 패키지가 특정 설정을 상속하는가? 왜 패키지 Y에서 유닛 X를 발견할 수 없는가? 최악의 경우 사용자는 최소한 패키지를 문제의 원인으로 보고 제외시켜야 할지도 모른다. 엔트리를 클릭하면 아래 필드에 해당하는 상세 내용을 보여준다.

그림 3.28: 컴파일러 옵션의 Inherited 페이지

Compilation 페이지는 프로젝트를 컴파일하는 동안 추가 명령의 실행 여부 또는 실행될 시간을 명시하도록 해준다. 프로젝트에 대한 Make 파일이 있는 경우 프로젝트는 후에 명령 행으로부터 컴파일할 수 있다. Create Makefile 옵션을 활성화할 경우 IDE가 Make 파일과 Makefile.fpc를 생성하게 된다.

Execute before 섹션은 컴파일러로의 호출 전에 실행되는 명령을 보관한다.

Call on: 섹션은 다음과 같은 옵션을 가진다:

• Compile 일반 컴파일로 실행한다 [F9].
• Build 전부 새로 생성될 때만 실행한다.
• Run 빠른 컴파일로 실행한다.

프로젝트가 시작되면 IDE는 새로운 컴파일이 필요한지 검사한다. 필요하지 않은 경우, IDE는 컴파일 단계를 건너뛴다. 해당 설정을 활성화하면 컴파일을 건너뛸 때조차 명령이 항상 실행된다.

그림 3.29: 컴파일러 옵션의 Compilation 페이지

IDE는 명령의 출력을 분석 및 필터링하고 오류가 발생하면 중단시킨다. 어떤 메시지를 기다릴 것인지 설정할 수 있다.

컴파일러로의 경로는 Compiler 섹션에서 설정할 수 있다. 기본 값은 매크로 $ (CompPath)로 되어 있으며, 이는 Environment 설정에서 발견되는 컴파일러 파일명으로 대체된다. Execute after 섹션은 Execute before 섹션의 설정을 반영한다.

그림 3.30: 현재 컴파일러 설정의 개요

그림 3.31: 컴파일러 설정의 검사 결과를 보여주는 창

Project Options 대화창의 하단 테두리에는 Compiler Options 대화창의 모든 페이지에서 접근할 수 있는 여러 개의 버튼이 있다.

Help 버튼은 컴파일러 설정에 관한 정보가 있는 라자루스 위키로부터 페이지를 불러온다.

Show options은 현재 명령 행 파라미터를 보여주는 대화창을 열고, Test는 공통된 구성 오류를 찾기 위해 여러 번의 검사를 실행한다. Unit not found 오류를 받는다면 여기서 원인을 찾을 가능성이 높다.

(호출된 생략부호) [...] 버튼은 XML 파일로부터 (복원) 또는 XML 파일로 현재 컴파일러 설정을 저장하는 대화창을 연다. [OK] 버튼은 모든 변경사항에 적용되고 대화창을 닫는다. [Cancel]은 모든 변경사항을 취소하고 대화창을 닫는다.

Project ⇒ Add editor file to Project 는 현재 에디터 파일이 아직 프로젝트 파일이 아닐 경우 이 파일을 현재 프로젝트에 추가시킨다. 파일을 프로젝트로부터 제거해야 하는 경우 Project ⇒ Remove from Project 옵션을 사용한다. 모든 프로젝트 파일의 리스트가 표시되고, 사용자는 제거할 파일을 선택할 수 있다.

View Source는 에디터에 프로젝트의 메인 프로그램 파일(*.lpr)을 연다. 이 파일은 다음과 같은 모양을 할 것이다:

program Project1;
{$mode objfpc}{$H+}

  uses
  {$IFDEF UNIX}{$IFDEF UseCThreads}
  cthreads,
  {$ENDIF}{$ENDIF}
  Interfaces, // this includes the LCL widgetset
  Forms, Unit1
  { you can add units after this };

  {$R *.res}

begin
  RequireDerivedFormResource := True;
  Application.Initialize;
  Application.CreateForm(TForm1, Form1);
  Application.Run;
end.

일반적으로 사용자는 .lpr 파일에서 어떠한 코드도 변경할 필요가 없다.

실행 메뉴

프로그램을 생성하고 디버깅하는 데 영향을 미치는 중요한 옵션들은 모두 Run 메뉴에 위치한다.

Build는 현재 프로젝트 내에서 마지막 빌드 이후 변경된 모든 파일을 대상으로 새로(fresh) 컴파일을 시작한다. Build all 도 Build와 동일한 작동을 하지만 변경되지 않은 파일까지 재컴파일한다. Quick compile은 현재 유닛만 컴파일하며, 어셈블러 결과를 생성하지 않으며, 링커로 어떠한 호출도 하지 않는다. 실수로 빌드를 시작한 경우 (또는 빌드에 문제가 발생한 것으로 보이는 경우) 컴파일러 프로세스 실행을 중단하기 위해 Abort Build를 선택할 수 있다.

Run 메뉴 옵션은 (또는 [F9]을 누름) 애플리케이션을 컴파일하고 라자루스가 결과적 실행 파일을 실행하도록 만드는 일반적인 방법이다. 물론 빌드가 성공하지 않으면 실행 가능(runnable) 프로그램도 생성되지 않는다.

컴파일에 잇따라 링커가 자동으로 호출되며, 이후에는 연결된 애플리케이션이 호출된다. 사용자의 애플리케이션이 IDE 컴포넌트 중 하나와 문제없이 작동이 불가한 경우 (때로는 디버거와 발생하기도 한다) 라자루스를 닫고 애플리케이션을 따로 실행하는 것이 최선이다.

Pause는 실행 중인 애플리케이션의 실행을 방해하는데, 아마도 사용자가 생성된 출력을 검사하도록 허용하기 위한 목적일 것이다. 실행을 재개하려면 [F9]을 다시 누른다. Stop은 실행을 중단시키고 라자루스 IDE로 돌아갈 것이다.

Run 파라미터

사용자는 Run parameters 메뉴를 이용해 명령 행 파라미터를 애플리케이션으로 전달하고자 계획할 것이다. 대화창은 2개의 페이지로 구성된다: Local 과 Environment.

Local 페이지

프로젝트 실행 파일과 디버깅할 실행 파일이 동일하지 않을 경우 사용자는 다른 실행 파일을 Host application 필드에 명시한다. Command line parameters (without application name) 필드에 어떠한 시작 명령 행 파라미터든 입력한다.

프로젝트가 단말기(terminal) 내 스크립트의 도움으로 시작되거나 특수 디버거 또는 프로파일러의 도움으로 시작될 경우, 사용자는 Use launching application 확인상자를 활성화시켜야 한다. 아래 필드에 시작 프로그램(launching program)의 경로를 입력하라.

X 에서 이용할 수 있는 다중 Linux 데스크탑은 (Gnome, KDE, xfce) Use Display를 통해 접근할 수 있다. 예를 들어, 명령 행 변수를 1로 설정하면 (기본 값 0이 아닌) 두 번째 데스크탑에 애플리케이션을 표시한다.

다른 컴퓨터에 표시하기 위한 값은 192.168.1.17:0 또는 hydra: 0,1이 될 수 있다. 해당 설정은 윈도우에서는 무시된다. 검사된 (디버깅된) 프로젝트의 작업 디렉터리는 보통 프로젝트 디렉터리이다. 즉, 모든 상대 파일명은 작업 디렉터리의 일부로 확장됨을 의미한다. 해당 디렉터리는 Working directory를 다른 위치로 설정하여 변경할 수 있다.

Environment 페이지

일반적으로 검사된 프로그램은 IDE 자체와 동일한 환경 변수로 시작된다. System variables는 현재 설정이 무엇인지 보여준다. User Overrides는 테스트한 프로그램의 실행 중인 환경에 대해서만 구체적 환경 변수를 다른 값으로 설정하도록 해준다.

구성 변수(configuration variable)의 명령 행 파라미터에 실수가 있어선 안 된다. 사용자의 프로그램은 GerEnvironmentVariable, GetEnvironmentVariableCount 또는 Application.GetEnvironmentList 와 같은 함수로 그러한 변수들을 호출할 수 있다.

그림 3.32: Run ⇒ Run 파라미터 대화창의 Environment 페이지

그림 3.33: Package ⇒ Open loaded package 메뉴 뒤의 대화창

패키지

새 컴포넌트는 package를 이용해 IDE에 설치된다.

패키지를 사용하는 데 있어 가장 중요한 명령은 모두 Package 메뉴에 위치한다.

Open loaded package는 모든 로딩된 (설치된) 패키지를 대화창에 열거하며 사용자는 이 중 하나를 선택할 수 있다. 선택한 내용을 더블 클릭하면 (또는 Open을 클릭하면) 선택한 패키지가 패키지 에디터에서 Package <packagename> 이란 이름으로 열린다. 패키지 파일은 XML 포맷으로 보관된다 (따라서 라자루스 IDE 외부에서 쉽게 파일로 작업이 가능하다). 이는 패키지와 라자루스 구성 파일이 어떻게 보관되는지에 관한 정보를 포함한다.

그림 3.34: Package ⇒ Open loaded package... 를 통해 접근 가능한 패키지 에디터에 열린 printer4lazarus package

패키지 에디터

패키지 에디터(Package Editor)에는 광범위한 기능과 적절한 함수를 제공하도록 변경되는 툴버튼이 있다. 패키지 에디터는 패키지에 대한 내용을 변경하는 데 사용되는 툴이다. 변경 내용은 Save 버튼을 이용해 저장된다. 새로운 패키지를 설치해야 하는 경우 Install을 클릭하면 라자루스가 알아서 필요한 단계들을 (컴파일 포함) 마련해준다. 패키지를 IDE에 설치하기 위해 그 의존성과 함께 컴파일되며, 설치를 기다리는 패키지 리스트에 추가된다 (앞서 선택한 엔트리도 있을 것이다). 대화창에서는 어떠한 패키지가 IDE에 추가 및 제거될 것인지를 보여주며, 변경 내용을 승인할 경우 IDE가 재컴파일된다 (시간이 어느 정도 소요될 것이다).

새 패키지가 IDE에 설치될 패키지가 아닌 경우 Compile을 클릭하면 실시간으로 애플리케이션에서 패키지와 그 의존성을 이용할 수 있도록 만든다. 일부 패키지는 외부 라이브러리에 따라 좌우된다. 예를 들어, 데이터베이스 패키지는 데이터베이스 클라이언트 라이브러리를 필요로 한다. 사용자는 라이브러리 없이 데이터베이스 애플리케이션을 컴파일할 수 있지만 추후 누락된 라이브러리로 인해 라자루스를 재시작할 수 없음을 깨달을 것이다. 따라서 컴파일을 시작하기 전에 어떠한 의존성이 있는지 주의를 기울여야 한다.

새로운 요소를 추가하기 위해서는 (유닛, 파일, 의존성, 컴포넌트) Add를 클릭한다. 나타나는 Add to package 대화창은 전체적인 옵션을 제공한다. 일반 패키지 설정은 Options 버튼으로 찾을 수 있다. Help 버튼은 라자루스 위키 페이지를 가져온다: ( http://wiki.lazarus.freepascal.org/IDE_Window:_Package_Editor )는 패키지 에디터에 관한 정보를 포함한다. Remove는 승인 후 선택된 요소를 (파일 또는 의존성) 패키지로부터 제거한다. Compiler Options 버튼을 통해 패키지 컴파일러 설정으로 접근하는 방법이 있으며, More 버튼을 누르면 더 많은 기능으로 접근할 수 있다 (누락된 파일 표시하기 또는 업무 리스트(ToDo list) 가져오기 등).

그림 3.35: 패키지 에디터의 컨텍스트 메뉴

패키지 에디터의 컨텍스트 메뉴는 다양한 툴버튼에서 이용할 수 있는 기능 대부분으로 접근하는 대안적 방법을 제공한다. 사용자는 패키지의 컴포넌트 파일의 타입을 정렬, 이동, 재명명, 변경할 수 있다. 사용자는 패키지는 인스톨 한 후 IDE로 통합되도록 재컴파일을 원한다고 승인할 수 있다.

Uninstall 은 IDE에 설치될 패키지 리스트에서 패키지와 모든 의존성을 제거한다. 승인 대화창이 나타난 후 IDE가 다시 빌드된다. 정적 패키지를 제거하려면 IDE를 다시 빌드하고 재시작할 필요가 있다. 현재 모든 IDE 패키지는 정적이다.

Save는 .lpk 파일에 대한 변경사항을 모두 저장한다. Save as는 .lpk 파일에 대한 새 파일명을 선택하는 새 대화창을 연다. 패키지의 이름은 변경되었을지 몰라도 그 안의 파일은 이동되거나 재명명되지 않는다. .lpk 파일을 새 디렉터리에 저장할 경우 컴파일 설정에서 경로를 검사할 필요가 있다.

Revert는 제시한 변경사항을 모두 중단하고 디스크로부터 .lpk 파일을 재로딩한다.

Publish Package는 Publish Package 대화창을 열어 패키지와 그 파일을 다른 디렉터리로 복사한다. 이는 컴파일된 파일이나 버전 파일 없이 패키지를 생성하여 ZIP 파일로 압축하는 데 유용하다.

Compile 은 패키지와 필요한 의존성을 컴파일한다. 보통 컴파일러는 모든 유닛을 검사하고 재컴파일이 필요 없다면 피한다. 하지만 Recompile clean 메뉴는 패키지의 모든 유닛을 강제로 컴파일한다. 필요한 패키지를 컴파일해야 하는 경우 이것이 먼저 실행된다. 컨텍스트에서 'Clean'이라 함은 모든 컴파일된 파일이 (주로 .ppu 파일) 먼저 삭제됨을 의미한다. Tools ⇒ Configure "Build Lazarus" 대화창의 Clean all은 인스톨된 패키지에 항상 영향을 미치지는 않기 때문에 해당 옵션은 패키지 내 파일 중 하나에 문제가 생길 때 라자루스의 재빌드에 유용하다.

위와 같은 일이 발생 시 Recompile clean을 먼저 사용하여 패키지를 재빌드할 것을 권한다.

Rebuild all required는 Recompile clean과 동일한 실행을 하지만 각 요구되는 패키지에도 적용된다. 하지만 FCL이나 LCL와 같이 일부 기본 패키지들은 자동으로 컴파일되지 않도록 설정되어 있기 때문에 해당 호출에 의해 재빌드되지 않는다.

Great makefile은 Makefile.fpc 패키지에 대해 make 파일을 생성하는데, 사용자는 이를 이용해 IDE 외부에서 패키지를 컴파일할 수 있다. make 파일 스크립트는 꽤 단순하여 모든 패키지를 (라자루스 패키지를 포함) 명시된 경로에서 찾을 수 있다고 가정한다. 따라서 make 파일을 다른 컴퓨터로 복사할 경우 실행하기 전에 먼저 조정해야 할 것이다.

Add는 새 요소를 (유닛, 파일 또는 의존성...) 패키지로 추가하는 Add to package 대화창을 (아래 참고) 연다. Remove는 선택된 요소를 승인 후에 패키지로부터 제거한다. General options는 Package Options 대화창을 열어 작동 설정, 버전 정보, 기타 일반 패키지 설정을 편집한다.

Compiler options은 선택된 패키지에 해당하는 Compiler options를 연다. View Package Source는 패키지의 메인 소스 파일을 연다. IDE는 재컴파일 시마다 이 파일을 자동으로 생성하므로 수동으로 편집해선 안 되는데, 만일 수동으로 편집 시 변경 내용은 사라질 것이다.

View ToDo list는 업무 리스트를 표시한다 (Project ⇒ ToDo list 참고).

Add to package 대화창

패키지 에디터의 Add 버튼은 새로운 요소들을 패키지로 추가하는 4페이지로 구성된 새 대화창을 연다 (대화창 모양은 현재 라자루스 팀이 변경 중).

New File 페이지:

여기서 사용자는 파일 타입을 선택할 수 있으며 Create new file 버튼을 누르면 그 타입의 새 파일이 생성되어 패키지에 추가된다.

그림 3.36: 패키지 대화창에서 Add의 New File 페이지

New Component 페이지:

해당 페이지는 새 컴포넌트에 적절한 세부 내용을 입력하는 필드가 있는 컴포넌트를 위한 새 유닛을 생성한다. Ancestor Type은 새 컴포넌트의 조상 클래스를 명시한다. 예를 들어, TButton에서 새로운 버튼 컴포넌트를 파생할 것이다. 당연히 새 클래스 이름은 조상 클래스와 달라야 한다. 새 버튼의 이름은 TImprovedButton이 될 수 있다.

Palette Page 콤보 상자는 패키지가 IDE에 설치될 때 새 컴포넌트가 컴포넌트 팔레트에서 위치할 장소를 선택하도록 해준다. 기존 탭이나 (예: Additional) 새로운 탭에 새 이름을 입력할 수 있다. 유닛에도 파일명이 필요한데, 파일명은 Unit File Name 필드에 입력된다 (예: mycomponentunit.pas).

Unit Name은 (예: MyComponentUnit) 다른 패키지와 유닛이 추후에 해당 유닛으로 호출할 때 사용하게 될 이름이다.

기본 라자루스 컴포넌트 아이콘 대신 이 컴포넌트를 식별하기 위해 컴포넌트로 (해당할 경우) 연결된 아이콘이 컴포넌트 팔레트 상에 표시될 것이다.

그림 3.37: Add to package 대화창의 New component 페이지

New Requirement 페이지

New Requirement 페이지를 이용해 패키지로 새 의존성을 추가할 수 있다. Package name은 IDE에 알려진 패키지라면 무엇이든 될 수 있다.

사용자가 원하는 패키지가 콤보 상자 리스트에 없는 경우 패키지를 한 번 열어 IDE에 그 존재를 알린 후 이 대화창으로 리턴한다.

모든 패키지는 버전화(versioned) 되어 있다. Minimum Version과 Maximum Version을 이용해 사용자는 필요한 패키지의 버전 번호에 선택적 범위를 제공할 수 있다.

예를 들어, 패키지가 최근 FCL에 도입된 기능에 의존하는 경우 사용자는 그 기능을 처음 도입한 FCL 버전을 최소 버전으로 설정할 것이다.

그림 3.38: Add to Package 대화창의 New Requirement 페이지

Add Files 페이지

파일 시스템 내 어떠한 파일이든 Add Files 페이지로부터 패키지로 추가할 수 있다. 기존 파일의 수가 얼마든 패키지로 추가할 수 있으며 그 파일 타입을 예상할 수 있다. Browse 버튼은 하나의 파일을 위치시키는 대화창을 여는 반면 Add directory는 디렉터리의 내용을 패키지로 추가하도록 설계되었다. 디렉터리가 패키지에 추가할 파일의 다수를 포함하는 경우 이 방법이 파일을 하나씩 선택하여 추가하는 것보다 빠르다.

그림 3.39: Add files of directory 대화창

Add directory 버튼을 클릭하면 Add files of directory 대화창이 열리는데, 만일 프로젝트 디렉터리에 위치하지 않은 파일을 찾는 경우 [...] 생략부호 버튼으로 (또는 완전한 경로를 손으로 입력하여) 디렉터리를 훑어볼 수 있다. 하위디렉터리 내 파일을 패키지로 추가하길 원하는 경우 Include subdirectories 확인상자를 활성화하라. 디렉터리의 선택된 파일만 추가해야 하는 경우 관련 filter를 활성화하라. 필터 필드를 비워 놓을 시 모든 파일이 (숨김 파일도 포함) 포함될 것이다.

보통 필터는 단순한 프로그램식을 사용하지만 Regular expressions 라는 이름의 확인상자를 활성화하여 전체 정규 표현식을 활성화시킬 수 있다. Only text files의 추가를 가능하게 하면 그림과 같은 바이너리 파일은 남겨질 것이다.

파일의 카테고리를 제외시킴으로써 필터링을 구현할 수도 있다. Exclude filter는 어떠한 파일을 패키지에 추가하면 안 되는지 결정한다. 필드를 비워둔다면 어떠한 파일도 제외되지 않는다. 여기서 Regular expression를 강제로 사용하도록 설정할 수도 있다.

OK를 클릭한 후 없어야 할 파일이 열거되어 있다면 선택하여 Delete 버튼을 누르면 리스트에서 제거된다.

Switch Paths 버튼은 절대 또는 상대 파일 경로를 보여주며 토글한다. 파일 리스트가 완료되면 Add files to package 버튼으로 열거된 파일들을 패키지로 추가한다.

그림 3.40: 디렉터리가 열린 후 Add to package 대화창의 Add Files 페이지

패키지 옵션 대화창

패키지 에디터의 Options 툴버튼을 누르면 5 페이지로 된 Package Options 대화창이 열린다.

그림 3.41: 패키지 옵션 대화창의 Usage 페이지

패키지 옵션의 Usage 페이지

Usage 는 다양한 경로를 설정하도록 해준다. Add paths to dependent packages/projects 에 설정된 경로는 이 패키지 자체에 포함되지는 않지만 해당 패키지를 포함하는 프로젝트와 패키지의 경로에 추가된다. 이를 '상속 경로(inherited paths)'라 부른다. 예를 들어, 패키지 A는 패키지 B를 필요로 하고, 패키지 B는 패키지 C를 사용한다고 가정하자. C의 모든 사용 설정은 B와 A의 설정에 추가된다. 유닛 경로는 매크로를 포함할 수 있으며 세미콜론으로 구분되고, 해당 패키지를 포함하는 모든 프로젝트와 패키지의 유닛 경로에 추가된다. Unit 경로에 true라면 Include 경로에도 true이지만 유일한 차이는 어떠한 include 파일에 대해서든 유효한 경로여야 한다는 점이다. 마찬가지로 Object 경로는 오브젝트 파일에 유효해야 한다. 라이브러리 경로도 마찬가지지만 경로가 라이브러리에 유효해야 한다는 것이 차이점이겠다. 의존 패키지와 프로젝트에 대한 새로운 설정은 사용자 정의로 만들어질 뿐 아니라 (Custom 필드) 링커에서 참조될 수 있다 (Linker 필드). Linker와 Custom 옵션은 모두 매크로를 포함하고 공백으로 구분되며 (세미콜론이 아닌) 해당 패키지를 포함하는 모든 패키지와 프로젝트의 링커 설정에 추가된다. 캐리지 리턴(Carriage return)은 공백으로 변환되고, 다수의 공백은 하나의 공백으로 취급되지만 인용부호(quote) 사이에 위치한 경우는 제외된다.

그림 3.42: 패키지 옵션 대화창의 Description 페이지

패키지 옵션의 Description 페이지

패키지는 Description 페이지에서 상세하게 문서화할 수 있다.

Description/Abstract 필드는 패키지가 무엇을 하는지에 대한 간략한 요약을 가능하다면 많은 사용자들이 이해하는 언어로 포함하도록 되어 있다.

개발자 이름이 (보통 사용자 본인의 이름) Author 필드에 입력된다.

패키지가 게시, 배포 또는 판매용으로 설계된 경우 라이센스 조건이 License 필드에 열거될 것이다.

다양한 Version 섹션은 사용자가 원하는 것은 무엇이든 의미할 수 있지만 다음 패턴이 일반적이다:

Major: 패키지에 기존에 지원되지 않던 플랫폼으로 확장되었다거나 하는 주요 내용 변경이 일어난 경우 증가한다.

Minor: 패키지에 메소드의 파라미터 리스트가 변경되거나 새로운 기능이 생기는 등 약간의 내용 변경이 일어난 경우 증가한다.

Release: 패키지가 발매될 때 증가한다.

Build-number: 패키지가 재컴파일 될 때마다 증가한다.

패키지 옵션의 IDE Integration 페이지

IDE Integration 페이지는 패키지의 유형과 이것이 어떻게 업데이트되는지에 관한 정보를 포함한다.

PackageType은 패키지가 IDE에서 어떻게 사용되는지를 보여준다.

Designtime only: 패키지는 IDE용 플러그인으로, 일반 애플리케이션에는 절대 포함되지 않고, 설계 시에만 연관된다. 설계 시간 패키지는 IDE 인터페이스 함수를 포함하는 IDEinf 패키지를 필요로 한다. IDE는 설계 시간 패키지가 프로젝트에 포함되어 있을 때 경고를 보낸다.

Runtime only: 패키지는 어떠한 IDE 기능도 없으므로 IDE에 설치되어선 안 된다. 예를 들어, 그러한 패키지는 특수 파일 관리를 제공할 수 있다.

Designtime and Runtime: 패키지는 일반 애플리케이션 뿐 아니라 IDE에 대한 기능도 제공한다.

Update/Rebuild 섹션은 패키지 업데이트의 빈도를 조절한다:

Automatically rebuild as needed: 해당 패키지를 포함하는 패키지 또는 프로젝트가 재생성될 때마다 (직접 또는 간접적으로) IDE는 패키지 파일이 변경되었는지 검사한다. 변경되었다면 패키지는 재컴파일될 것이다.

Auto rebuild when rebuilding all: 이는 이전 옵션과 동일한 상황을 포함하지만 이번 경우 사용자가 재컴파일을 트리거한다는 점이 다르다.

Manual compilation: 패키지가 절대 간접적으로 재생성되지 않는다. 패키지를 재컴파일하기 위해서는 패키지 에디터를 열고 Compile 버튼을 클릭하여 컴파일해야 한다.

주목: 특별한 방법으로만 컴파일 할 수 있는 FCL 이나 LCL과 같은 내장 패키지가 몇 가지 있다 (예: Make 또는 Lazbuild). 라자루스 최근 버전들은 LCL을 다른 패키지처럼 취급할 수 있을 것이다.

FPDoc 도움말 파일에 (패키지를 문서화하는) 대한 경로는 FPDoc files path 필드를 이용해 설정할 수 있다.

그림 3.43: 패키지 옵션 대화창의 IDE integration 페이지

패키지 옵션의 Provides 페이지

Provides 페이지는 특정 패키지가 IDE에 알려진 다른 패키지의 기능을 제공하는지 검사하도록 해준다 (예: 다양한 대화창 컴포넌트). 이는 LCL의 대안으로 작업해야 하는 경우 패키지와 LCL의 공통점에 대한 개요가 필요할 때 유용하다.

패키지 옵션의 i18n 페이지

i18n 페이지는 패키지에 대해 여러 언어를 활성화하도록 해준다 (i18n은 '국제화'의 축약어이다). 여기서 라자루스는 GNU gettext 라이브러리를 이용한다. 패키지 GUI에 표시된 모든 문자열은 리소스 문자열로 선언되며, 컴파일되면 .po 파일을 생성한다 (특수 포맷 텍스트 파일).

이후에 poedit과 같은 툴을 이용해 다른 언어로 번역된다.

Tools ⇒ Make Resource String... 을 통해 리소스 문자열을 생성하기 위한 도움말을 찾을 수 있다. 그리고 나면 사용자는 Enable i18n 확인상자를 활성화하여 라자루스가 .po 파일을 저장할 경로를 설정해야 한다 (해당 디렉터리는 라자루스가 생성하지 않으므로 사용자가 직접 생성해야 할 것이다). .po 파일을 패키지 디렉터리의 'languages'라는 이름으로 된 하위디렉터리에 보관하는 것이 증명된 방법이지만 어떠한 디렉터리든 사용될 수 있다.

그리고 나서 패키지를 컴파일하면 첫 .po 파일을 생성할 것이다. 개발자는 원본 .po 파일을 자신이 지원하고자 하는 언어 수대로 해석해야 한다. 각 언어는 구분된 .po 파일을 요한다.

그림 3.44: 패키지 옵션 대화창의 i18n 페이지

Package ⇒ Open package of current unit

현재 디렉터리가 패키지에 속한 경우 Open package of the current unit 메뉴로 패키지 에디터에서 열 수 있다.

Package→Open recent packages를 이용하면 마지막으로 열린 패키지 5개의 리스트가 표시된다.

그림 3.45: Package ⇒ Package Graph를 통해 접근하는 Package Graph 대화창

Package ⇒ Package Graph

패키지 그래프는 IDE에 최근 로딩된 패키지와 그 상호의존성(interdependency)을 표시한다. 상단 좌측 창은 모든 패키지를 열거하고 노드는 그들이 필요로 하는 패키지이다. 상단 우측 창은 선택한 패키지를 필요로 하는 패키지를 보여준다. 패키지 세부내용은 아래 메모에 표시된다. 패키지를 선택하여 더블 클릭하면 패키지 에디터에서 열린다. 패키지는 아래 상태 중 하나에 해당한다:

Installed: 패키지가 IDE에 설치 및 컴파일되어 패키지의 클래스와 컴포넌트를 컴포넌트 팔레트에서 이용할 수 있다.

Autocreated: 패키지가 IDE의 일부이므로 제거할 수 없다.

Install on next start: IDE가 재시작하면 IDE에 패키지가 설치 및 컴파일된다.

Package ⇒ Install/Uninstall packages

사용자는 Install/Uninstall packages 대화창을 이용해 IDE에 패키지를 설치한다. Install 리스트는 모든 라자루스 패키지를 포함해 이전에 설치된 다른 패키지들도 포함한다. 패키지가 IDE에 알려지지 않은 경우 Package ⇒ Open package file 을 이용해 먼저 열어야 한다.

그림 3.46: 설치된 패키지와 이용 가능한 패키지의 개요, Package ⇒ Install/Uninstall packages... 를 통해 접근

Install은 개발자가 설치를 위해 제공하거나 이미 설치된 패키지를 열거한다. 여기서 제거할 패키지를 선택할 수 있다. Do not install은 설치에 이용 가능한 패키지를 열거하지만 설치해야 할 패키지는 선택을 해제한다. 패키지를 선택하면 Package Info 필드에 그에 관한 정보가 (예: 작성자 이름) 표시된다.

해당 정보는 패키지 옵션 대화창의 Description 페이지를 이용해 패키지에 기록되어야 한다. 이것이 완료되지 않으면 해당 필드는 비어 있을 것인데, 이는 라자루스 오류가 아니라 작성자(author) 과실의 흔적이다. 하지만 오픈 소스 개발자들은 처음엔 종종 기능적 패키지의 전달에 더 중점을 두고 작업을 문서화하는 업무를 간과하곤 한다.

Install selection 버튼은 설치를 위해 선택된 패키지를 표시하고 Uninstall selection 버튼은 제거를 위해 선택된 패키지를 표시할 것이다. 이러한 방식으로 IDE가 재빌드되기 전에 여러 개의 패키지를 표시해둘 수 있다.

라자루스는 현재 정적 패키지만 작업하기 때문에 IDE는 각 패키지 변경 이후 변경 내용의 효과가 나타나기 전에 재빌드되어야 한다.

설치 또는 제거 시 문제가 발생할 경우 한 번에 하나의 패키지를 선택하여 IDE를 재빌드한다. 일부 패키지들은 다른 패키지에 의존한다는 점을 명심하자! Cancel 버튼은 모든 변경사항을 거부하고 대화창을 닫는다. Save and rebuild IDE 버튼은 변경사항을 수락하고, 변경사항을 적용하도록 승인하면 이를 포함시키기 위해 IDE가 재빌드된다. 가끔은 오류 메시지가 개입하기도 하는데 주로 의존성 실패 때문이다. 아니면 선택된 패키지에서 개발자의 FPC보다 더 높은 버전을 필요로 할 가능성도 있다.

그림 3.47: 패키지 설치 도중에 발생하는 오류 메시지

그림 3.46과 비슷한 오류 메시지를 본다면 Remove from install list를 선택하라. IDE가 성공적으로 재컴파일하고 나면 모든 의존성이 충족되었는지 다시 확인하라. 프로그래머가 라자루스 디렉터리에 대한 파일-쓰기 권한이 없을 시에도 또 다른 오류 메시지가 발생한다. 이러한 경우 실행 파일을 쓰는 데 실패할 것이다. 이는 주로 라자루스를 관리자 권한으로 설치하고 패키지를 일반 사용자가 설치했을 때 발생한다. 예를 들어, 리눅스에서 라자루스가 패키지 관리자에 의해 (.rpm 또는 .deb 파일) 설치될 때 이러한 오류가 발생한다. 권한 문제를 해결해야만 오류 문제를 해결할 수 있다. Save and exit dialog는 모든 변경사항을 저장하는데, Save and rebuild IDE 버튼으로 직접 되는 것이 아니라 다음에 재빌드될 때 IDE로 컴파일될 것이다. Export list 버튼으로 XML 파일에 변경 내용을 저장할 수도 있다 (또는 Import list 버튼을 이용해 이전에 저장된 파일을 읽어올 수도 있다).

툴 메뉴

Tools 메뉴는 통합 툴, Delphi 변환 툴, IDE를 빌드하기 위한 명령, 외부 툴을 IDE로 추가하는 기능을 포함한다.

그림 3.48: 툴 메뉴

라자루스 IDE는 광범위한 함수를 제공하지만 사용자는 IDE에 추가 프로그램을 포함시켜 라자루스 환경 내부에서 더 쉽게 추가 기능을 이용할 수 있다. 사용자는 Tools ⇒ Configure external tools를 이용해 외부 툴에 대한 파라미터를 설치할 수 있다. 이러한 설정들은 전역적이며 모든 프로젝트에서 이용 가능하다. External tools 대화창에서 Add 버튼을 누르면 새 툴을 추가할 수 있는 Edit Tool 대화창이 열린다. Edit은 Add와 동일한 대화창을 열지만 최근 선택한 툴 설정을 편집할 수 있다. Remove는 실행을 승인 시 최근 선택한 툴을 삭제한다. Up과 Down을 이용해 툴 리스트에서 현재 툴을 새로운 위치로 이동할 수 있다. OK를 클릭하면 변경내용을 저장하고 대화창이 닫힌다.

Edit Tool 대화창은 IDE에 새 툴을 꽤 쉽게 포함할 수 있도록 해준다. 툴 메뉴에 추가된 툴의 이름은 사용자가 Title 필드에 입력한 이름이다. Program Filename은 툴의 완전한 경로를 포함해야 한다. Parameter 필드는 사용자가 툴로 명령 행 파라미터를 전달하는 곳으로, 예를 들자면:

-l test.pas 와 같다. Working Directory는 툴이 시작되는 디렉터리이다. 모든 상대 경로는 이 디렉터리와 관련된다. 툴이 출력 메시지를 생성하면 IDE는 컴파일러에 관한 해당 메시지들을 검색하고 (또는) 메시지를 생성한다. 사용자는 그에 적절한 확인상자를 활성화시켜야 할 것이다. Program Filename, Parameters, Working Directory 필드에서 매크로를 사용할 수 있다. 커서가 해당 필드 중 하나에 위치하면 스크롤 리스트에서 매크로를 선택한 후 커서 위치에서 Add를 클릭해 매크로를 삽입한다.

Tools 메뉴에서 툴을 호출할 수도 있기 때문에 선택적 툴이긴 하지만 외부 툴을 키보드 단축키에 할당할 수도 있다.

그림 3.49: Edit Tool 대화창을 여는 External tools 대화창의 Add 버튼

Tools ⇒ Make Resource String…을 통해 리소스 문자열 생성하기

사용자는 애플리케이션을 재컴파일 할 필요 없이 새 언어를 추가하는 장점이 있는 resource strings를 이용해 애플리케이션의 인터페이스를 여러 개의 언어로 제공할 수 있다. 이러한 방식으로 애플리케이션을 국제화시키는 것은 리소스 문자열의 이름을 한 interface 부 어디서든 표시되는 문자열을 모두 선언함을 의미한다.

Make Resource String 대화창은 국제화를 위해 문자열 상수와 문자열 리터럴(literal)을 리소스 문자열로 변환하도록 돕는다.

첫째, 리소스 문자열 섹션을 이용할 수 있어야 한다. 사용자는 목표 유닛의 interface 부에 문자열을 선언하기 전에 resourcestring 키워드를 입력하여 간단히 생성할 수 있다. (다음 컴파일 전에 최소 하나의 리소스 문자열이 추가되어야 하며, 그렇지 않을 시 오류가 발생할 것이다) 커서가 문자열 상수에 위치하도록 하고 Tools→Make Resource String을 선택하라. Make Resource String 대화창을 열고, 확장자와 (기본 rs) 제시한 이름이 결합되어 새로운 식별자가 자동으로 생성된다. 사용자는 Identifier prefix 필드에서 확장자를 변경할 수 있다. 잇따른 Make Resource String의 호출은 최근 생성된 이름의 확장자를 변경할 뿐만 아니라 사용자의 기본(custom) 확장자를 이용할 것이다. 문자열 상수에 제시되는 이름은 그 고유의 이름이고, 문자열 리터럴에 제시되는 이름은 문자열을 기반으로 한다.

예를 들어, (resourcestring 섹션이 이미 있다고 가정), 아래를 입력하고:

Button1.Caption := 'Click here';

커서를 'Click here'의 어딘가 위치시킨 후 Make Resource String을 호출할 경우, 기본 값을 수락하고 OK 버튼을 누르면 다음이 생성된다:

resourcestring
 rsClickHere = 'Click here';
...
Button1.Click := rsClickHere;

새로운 식별자는 이전 문자열 리터럴 또는 문자열 상수 이름을 대체하고, 그 문자열 값은 resourcestring 섹션에서 선언된다.

IDE는 각 유닛에 대해 확장자를 등록하여 현재 유닛에 대해 올바른 확장자를 제시할 수 있도록 한다. Identifier length는 자동으로 생성되는 식별자의 최대 길이이다.

자동으로 생성되는 식별자 대신 사용자가 리소스 문자열에 이름을 붙이고 싶다면 Custom identifier 필드에 원하는 이름을 입력하면 된다. Resourcestring section 콤보 상자는 현재 유닛을 비롯해 현재 유닛의 uses 절 내 유닛의 interface 부에서 선언된 모든 resourcestring 섹션들을 포함한다.

식별자 내용이 담긴 문자열이 발견되면 String with same value 콤보 상자는 동일한 내용의 resourcestring 식별자를 모두 새로운 resourcestring으로 포함시킨다. 이들 중 하나를 사용하고 싶다면 선택 가능하다.

resourcestring 섹션에는 새 리소스 문자열의 위치를 조절하는 3 가지 옵션이 있다:

• Append to section 새로운 식별자가 섹션의 끝에 추가된다.
• Insert alphabetically 식별자가 알파벳순으로 삽입된다.
• Insert context sensitive 현재 커서 위치의 위, 아래에 위치한 소스 코드에서 resourcestring 식별자를 검색한다. 발견하면 그 위치에 새로운 식별자가 추가되고, 아니면 섹션의 끝에 추가된다.

Source preview는 문자열 상수가 어떻게 교체되는지를 보여주고, 점선으로 된 선(dashed line) 아래에서는 resourcestring 선언이 어떻게 표시되는지 살펴볼 수 있다. String constant in source 리스트는 현재 모든 문자열 상수를 표시하므로 사용자는 더 많은 문자열 상수를 리소스 문자열로 변환할 것인지 결정할 수 있다.

그림 3.50: Tools ⇒ Make Resource String... 대화창

텍스트 파일 비교하기

Tools ⇒ Diff 메뉴는 두 개의 텍스트 파일을 비교하여 차이점을 열거한 diff를 생성하도록 해준다. Diff 대화창의 Text 1과 Text2는 비교해야 할 두 개의 파일이다. 텍스트가 선택되면 이 선택 부분만 비교된다. 비교는 행별로 이루어지므로 (단어 또는 섹션 기반이 아니라) 바이너리 파일과는 작업이 불가하며 텍스트 파일만 가능하다 (예: Pascal 소스). diff 는 두 파일의 차이점 집합이다. Diff와 결과 파일을 이용해 변경된 파일을 재구성하는 것이 가능하다.

diff의 개념은 파일 전송을 위한 대역폭이 제한되어 있을 때 생겼으며 diff는 보통 전체 (변경된) 파일보다 크기가 훨씬 작다.

두 당사자가 결과 파일을 갖고 있는 경우, 다른 당사자가 변경된 파일을 받을 수 있도록 허용하기 위해 diff만 교환해도 충분하다. ADSL 통신 시대에서는 diff의 중요성이 퇴색해가고 있지만 여전히 그 가치는 존재한다. 예를 들어, 많은 메일링 리스트는 (라자루스 리스트도 속함) 첨부파일의 크기를 제한한다. 전송되는 파일이 이 크기를 초과할 경우 항상 diff에 의지할 수 있다.

비교를 제어하는 설정도 여러 가지가 있다.

Case Insensitive 를 활성화했을때 대.소문자의 차이를 모두 무시한다.

Ignore spaces at start of line 을 활성화 시 두 행을 비교할 때 들여 쓴 공백을 (탭 포함) 무시한다.

Ignore difference in line ends 는 Unix linke end #10를 Windows line end #13#10로 취급하고, 후자를 전자로 취급한다. 해당 설정은 비교할 파일들이 다른 컴퓨터로부터 시작되었을 때 유용하다.

Ignore spaces 는 모든 공백을 무시한다. A B와 AB는 같아진다.

Ignore spaces at end of line 은 두 개의 행을 비교할 때 문장 끝 공백(terminating space)을 무시한다.

Ignore amount of space charts 는 다수의 공백을 하나의 공백으로 취급한다.

원하는 비교가 모두 완료되면 Close로 Diff 대화창을 닫는다. Open Diff in editor 는 대화창을 닫고 diff를 새 에디터 페이지에 표시한다. diff 파일을 저장하려면 Save 버튼을 클릭한다. 고유의 파일 확장이 있는 diff는 추후 그런 것을 인지할 수 있도록 저장할 것을 권한다. 그러한 파일 확장에는 기본 값(default)이 없다.

그림 3.51: Tools ⇒ Diff를 통해 접근 가능한 diff 생성을 위한 대화창

Tools ⇒ JEDI Code Format

JEDI Code Format 메뉴 옵션은 jcfidelazarus 패키지가 설치되어 있을 때에만 나타나는데 최근 라자루스 버전에는 기본적으로 설치가 되어 있다. JEI Code Format 프로젝트의 함수는 지속적으로 라자루스 IDE로 통합되어왔다. JEDI Code Format 메뉴는 사용자가 About을 선택 시 JEDI 포맷 프로젝트에 관한 정보를 포함한다. 실제 포맷팅 설정은 에디터 Options 메뉴에서 찾을 수 있으며 (에디터를 오른쪽 마우스로 클릭하고 마지막 컨텍스트 메뉴 항목인 Options를 선택), 독자가 이 글을 읽을 때쯤이며 Tools 메뉴에서 이용할 수 있을 것이다. 소스 코드의 포맷팅에 있어 최고의 스타일에 관해 모두들 각자 의견이 있을 것이다. 또는 JEDI 포맷터의 작성자와 일치할 수도 있다. 본 서적은 좀 더 작고 쉽게 처리할 수 있는 포맷을 사용한다.

Tools ⇒ Convert encoding of projects/packages

Convert encoding of projects/packages는 프로젝트 또는 패키지 내 텍스트의 문자열 인코딩을 변환한다. 라자루스 0.9.26 버전부터는 모든 플랫폼에 대해 유니코드 (UTF8) 문자열을 사용하고 있다. 해당 메뉴 옵션을 이용해 오래된 프로젝트의 인코딩을 쉽게 변환할 수 있고, 말이 안 되거나 ???? 문자로 된 문자열의 표시를 피할 수 있다. 독일 사용자들은 주로 '움라우트(umlaut)'가 올바르게 표시되지 않을 때 잘못된 인코딩을 인지하는데, über가 ?ber로 표시되기도 한다 (혹은 더 이상하게).

메뉴 옵션을 클릭하면 Convert encoding 대화창이 열리는데, Convert project or package 콤보 상자에서는 변환할 프로젝트 또는 패키지를 선택할 수 있다. 해당 콤보 상자는 IDE에서 최근 로딩된 모든 프로젝트와 패키지를 열거하므로 (LCL과 FCL은 제외) 그 인코딩을 변환하기 전에 IDE에서 프로젝트를 열 필요가 있다. New encoding은 UTF8를 기본 값으로 하지만 다른 코드 페이지를 선택할 수도 있다. 사용자는 모든 프로젝트 파일을 변환할 필요는 없으므로 File filter 섹션은 변환 프로세스를 파일의 작은 그룹으로 제한할 수 있도록 제공된다. 확인상자 옵션들은 파일의 최근 인코딩을 바탕으로 변환하도록 제한한다. Filter 콤보 상자는 파일을 와일드카드(wildcard)와 정규 표현식 중 하나를 이용해 파일 확장을 기반으로 파일을 변환하도록 제한한다. 프로젝트나 패키지가 선택되고 Update preview 버튼을 클릭하면 변환의 효과를 미리 보여준다. 모든 파일이 목표 인코딩에 있는 경우 리스트는 빈 채로 남는다. 모든 파일이 목표 인코딩에 있는 것이 아니라면 인코딩이 필요한 모든 파일들이 표시된다. 실제 변환은 Convert 버튼으로 실행된다. 변환이 완료되면 Close 버튼을 눌러 대화창을 닫는다.

그림 3.52: Tools ⇒ Convert encoding of projects/packages를 통해 접근 가능한 인코딩 변환 대화창

Build Lazarus와 Convert build Lazarus 옵션들은 본 장의 마지막에 구분된 절에서 상세히 다루겠다.

환경 메뉴

Project 메뉴는 구체적인 프로젝트 설정에 대한 전반적인 제어를 제공하지만 Environment 메뉴는 라자루스 자체의 모양과 행위를 제어하고, 여기서 이루어지는 모든 설정은 모든 프로젝트에 영향을 미친다.

그림 3.53 환경 메뉴에서 제공하는 옵션

Files 페이지

Files 페이지는 중요한 파일과 경로 설정을 포함한다. Max recent files 는 File ⇒ Open recent 리스트에 표시되는 최대 파일 수를 설정한다 (기본 값: 10).

Max recent project files 는 Project ⇒ Open recent project 리스트에 표시되는 최대 파일 수를 설정한다 (기본 값: 5). 라자루스에서 마지막으로 작업하던 프로젝트를 라자루스의 시작과 함께 자동으로 열고 싶다면 Open last project at start를 활성화시킨다 (기본 값으로 활성화되어 있음). Show compile dialog를 활성화하면 컴파일을 시작할 때 라자루스가 프로세스의 세부 내용을 보고하는 진행 대화창을 표시하도록 할 수 있다. 해당 대화창을 표시하도록 요청했다면 Auto close compile dialog가 (대화창 스스로 옵션을 반복) 활성화되지 않은 이상 대화창은 수동으로 꺼야 한다.

그림 3.54: Environment ⇒ Options... 를 통해 접근 가능한 IDE 옵션 대화창의 Files 페이지

Lazarus directory는 모든 라자루스 소스 코드를 위한 루트 디렉터리를 명시한다. 이는 LCL 소스를 찾을 수 있는 ide, converter, components, lcl 등 많은 하위디렉터리를 포함한다.

Compiler path는 컴파일러의 전체 경로를 포함한다. 일반 경로는 Linux에선 /usr/bin/ppc386, OS X에서는 /usr/bin/ppcppc, Windows에선 c:\Lazarus\fpc\2.4.3\bin\i386-win32\fpc.exe이다. 분명한 점은 실제 파일 경로가 특정 컴파일러 설치에 따라 좌우된다는 점이다. FPC source directory 는 프리 파스칼 소스를 포함한다. 여기에는 compiler, packages, rtl, fcl 과 같은 하위 디렉터리가 있다. Linux, BSD 또는 OS X에서 값은 보통 /usr/share/fpsrc 이다.

주목: FPC source 디렉터리를 FPC unit 디렉터리, 즉 ../units/i386-win32와 혼동하지 않도록 한다. 이는 컴파일된 .ppu 파일만 포함하며 소스 디렉터리와 다르게 구조화된다.

Make path 는 make 툴의 경로를 포함한다. 경로가 비어 있는 경우 운영체제 프리셋(preset)이 사용되고, 올바른 값인지 확인해야 한다. make 툴은 모든 Linux와 OS X 체제에서 기본 값으로 설치되는데, 많은 Linux 및 Mac 제품들이 해당 툴을 이용해 광범위한 소스를 컴파일하기 때문이다. BSD에서는 gmake 를 이용할 수 있다. make에 관한 상세 정보는 http://www.gnu.org/software/make에서 찾을 수 있다.

아직까지 현재 프로젝트에 구분된 디렉터리를 설정하지 않았다면 Directory for building test projects에서 저장 및 컴파일될 것이다.

Desktop 페이지

IDE의 인터페이스에 대한 설정은 Desktop 페이지에서 변경할 수 있다. Language는 모든 IDE 메뉴 문구(phrase)뿐 아니라 모든 다른 대화창을 비롯해 컴포넌트의 텍스트까지 변경한다 (예: TBitBtn의 Caption 프로퍼티).

Language 설정은 항시 영어의 서브셋(subset)인 파스칼 프로그래밍 언어에는 영향을 미치지 않는다.

언어에 Automatic (or English) 으로 설정할 경우 사용자 운영체제의 언어 설정이 사용됨을 의미한다. 라자루스에서 지원하지 않는 언어일 경우 영어가 사용된다. 변경된 Language 설정의 효과를 나타나게 하려면 IDE를 재시작해야 한다. Auto save 기능은 쓰기 시점에서 구현되지 않는다.

그림 3.55: Environment ⇒ Options... 에서 접근 가능한 IDE 옵션 대화창의 Desktop 페이지

데스크탑 설정은 파일에 보관하여 읽어올 수 있다. 파일 확장자로는 .lds(Lazarus Desktop Settings; 라자루스 데스크탑 설정)을 권한다. TBitBtn과 같은 일부 컴포넌트들은 Glyph 프로퍼티를 가져 컴포넌트에 작은 아이콘을 표시하도록 해준다. 사용자는 Show Glyphs for 라디오버튼을 이용해 언제 이러한 글리프(glyph)를 표시할 것인지 설정한다. 이러한 버튼과 메뉴에 구분된 설정을 허용한다. 디스플레이 옵션에는 Default, Never, Always가 있다. Default는 글리프를 윈도우 상에선 절대 표시하지 않지만 다른 모든 운영체제에는 표시하도록 한다. Always는 호환성에 가장 좋은 설정으로 특히 구식 라자루스 버전에서 애플리케이션이 개발되었을 때 그러한데, Always로 설정하면 글리프가 표시되지 않는 뜻밖의 사고를 피할 수 있기 때문이다. 이 설정은 애플리케이션을 실행하면 글리프가 즉시 눈에 띄는 정도이고, 개발 중에는 항상 표시됨을 명심하라. sbgAlways, sbgNever, sbgSystm 값 중 하나를 취할 수 있는 Application.ShowButtonGlyphs 프로퍼티를 이용해 데스크탑 설정을 오버라이드할 수도 있다.

메인 메뉴 위에서 마우스를 움직이면 Hints for component palette (주로 컴포넌트의 이름을 표시)와 Hints for main speed buttons (속도버튼 함수의 이름 또는 그에 관한 전체 설명을 제공 가능) 설정에 따라 힌트를 볼 수 있다.

일반적으로 Messages 창에 있는 메시지를 한 번 클릭하면 소스 내 해당 위치로 데려갈 것이다. 메시지 활성화에 더블 클릭을 선호한다면 Jump from message to source line on double click 옵션을 활성화해야 한다.

창이 많이 열린 경우 Messages 창은 숨겨질 것이다. 컴파일 중에 오류가 발생하면 정확한 오류를 추적하는 Messages 창을 검색하기가 힘들다. Focus messages after compilation 설정을 활성화시키면 컴파일이 완료 시 Messages 창이 다른 라자루스 창들보다 앞에 위치한다. IDE는 보통 디스크 상의 에디터 파일에서 내용 변경을 확인할 때 파일의 타임 스탬프(time stamp)만 읽는다. 라자루스가 파일을 재로딩하고 그 내용을 비교하도록 하려면 Check changes on disk with loading 옵션을 활성화시킬 수 있다.

Window 페이지

Window 페이지는 IDE 창 설정을 변경할 수 있는 옵션을 여러 개 제공한다.

기본 값으로는 모든 라자루스 창이 운영체제의 윈도우 리스트(window list)에 따로 표시된다 (Windows의 Taskbar). Show single button in TaskBar 를 활성화시키면 리스트를 단일 라자루스 항목(또는 아이콘)으로 줄인다.

프로젝트가 컴파일되고 IDE 내부에서 실행되면 (Run→Run) 열려 있는 IDE 창들이 거슬릴 때가 있다. Hide IDE windows on run 를 활성화하면 전체 IDE를 숨기고, 실행 중인 애플리케이션이 종료되면 복구된다.

라자루스 최신 버전들의 경우 Messages 창이 메시지 타입을 아이콘으로 표시한다. 이러한 아이콘은 Hide message icons를 활성화시켜 제거할 수 있다. 보통 IDE는 운영체제 작업 표시줄(taskbar)로 Lazarus IDE vX.Y.Z – project 1을 사용한다. 라자루스 최신 버전들은 제목 표시줄에 프로젝트 이름을 먼저 표시하도록 해주는데, 대부분의 작업 표시줄은 너무 짧아서 Lazarus... 라는 글자만 표시되기 때문이다. IDE title starts with project name 확인상자는 IDE의 다중 인스턴스가 동시에 여러 다른 프로젝트에서 작업하도록 시작 시 유용한데, 어떤 작업 표시줄 아이콘이 어떤 프로젝트를 참조하는지 식별하기가 쉽기 때문이다.

Show project directory in IDE title 확인상자 또한 위와 같이 IDE 프로젝트가 어떠한 것인지 한 눈에 확인하도록 돕기 때문에 유용하다. IDE 창의 크기와 위치에 대한 환경설정(preferences)은 Window Positions 섹션에서 설정한다. 리스트에 열거된 창들 중 하나를 클릭하면 현재 설정이 표시된다. Left와 Top은 창의 상단 좌측 테두리를 의미하고, Width와 Height는 크기를 나타낸다. 이러한 픽셀 값을 변경할 때는 화면 해상도를 명심해야 한다. 각 창마다 사용자 설정을 부여할 수도 있고, 아니면 Use windowmanager 라디오버튼을 이용해 라자루스 프리셋(preset)을 이용하는 수도 있다.

그림 3.56: IDE Options 대화창의 Window 페이지

폼 에디터 페이지

Form Editor 페이지는 사용자가 IDE를 이용해 개발하는 프로그램 창에 대한 설정을 제공한다. Grid 섹션은 폼 디자이너의 이용과 관련된 아래의 옵션들을 제공한다:

Show Grid 는 각 폼에서 격자(grid)를 표시하여 컴포넌트를 드롭(drop) 시 위치시키는 것을 도와준다. 격자는 컨트롤이 허용되는 모든 클라이언트 영역(client area)에서 표시된다.

Show border spacing 은 모든 컨트롤 주위에 직사각형을 표시한다 (IDE 속도가 약간 느려진다).

Snap to grid 는 사용자가 컨트롤의 크기를 변경하거나 이동시킬 때 가장 가까운 격자선(grid line)으로 이동시킨다.

Grid size X 는 격자 선의 수평 간격을 픽셀로 표시한 것이다 (Grid size Y는 수직 간격이다). Colors 섹션은 다양한 폼 디자이너 항목의 색상을 Colors 리스트에 명시하도록 해준다.

Grabber color 는 크기 컨트롤을 선택하면 그를 변경하는 데 사용되는 8개의 작은 상자들의 색이다.

Marker color 는 다중 선택에 포함되는 모든 컨트롤의 테두리에 표시되는 4개의 작은 상자들의 색이다.

그림 3.57: IDE Options 대화창의 Form Editor 페이지

Colors 리스트의 Rubberband 항목은 ‘rubberband’ 선택 툴을 의미하며, 폼을 왼쪽 마우스로 클릭하여 마우스를 드래그(drag)할 때 Designer에 나타난다. 마우스 버튼을 클릭하면 고무밴드(rubber band) 내 모든 요소들이 선택된다. [Shift] 키를 누른 채 클릭하면 선택된 내용에 컨트롤을 추가하거나 삭제한다. 이는 Rubberband Selection 이다.

Rubberband Creation 도 비슷한 고무밴드인데, 컴포넌트 팔레트에서 컨트롤을 선택하여ㅡ폼에서 한 번 클릭하여 드롭하는 편보다ㅡ왼쪽 마우스를 누른 채로 폼에서 마우스를 드래그하면 표시된다. 이러한 생성 고무밴드는 선택 고무밴드와 다른 색으로 정할 수 있다. Miscellaneous 섹션은 폼 디자이너에 영향을 미치는 여러 개의 설정을 포함한다.

Select grandchildren:

고무밴드가 있는 컴포넌트를 선택하면 기본 값으로 사용자는 고무밴드가 그려진 컨트롤의 자식들(children)만 선택할 수 있다. 해당 옵션을 사용하면 자식 컨트롤 고유의 자식 컨트롤들도 함께 선택될 것이다 (예: 여러 개의 TButtons를 포함하는 TPanels 두 개를 고무밴드로 구현할 경우).

Show component captions:

런타임 시 보이지 않는 컴포넌트들은 (예: 대화창 컴포넌트) 폼에 작은 아이콘으로 표시된다. 해당 옵션을 선택하면 아이콘 아래 컴포넌트 이름을 추가한다 (예: 설계 시에만 표시되는 아이콘과 같이).

Show editor hints:

폼 디자이너에서 컴포넌트 위로 마우스를 왔다 갔다 하면 컴포넌트 Name과 위치를 표시한 힌트 메시지가 표시된다. 런타임 시 표시되는 컴포넌트는 크기 (포커스를 맞출 수 있는 컴포넌트), TabStop, TabOrder에 관한 정보가 포함된 더 긴 힌트를 가진다.

Open designer on open unit:

폼 디자이너는 유닛 파일이 열리면 자동으로 열린다. 해당 옵션은 초보자들에게 특히 유용하므로 기본 값으로 활성화된다.

Right Click selects:

컴포넌트를 오른쪽 마우스로 클릭하면 컨텍스트 메뉴를 표시 및 선택한다.

Reduce designer painting:

이는 IDE가 폼을 다시 칠하기 (repaint) 위한 가장 빠른 알고리즘을 사용한다 (redrawing 대신 InvaliateRect). 하지만 이 방법이 모든 위젯 셋의 모든 위젯과 작동하는 것은 아니다. Designer에서 아티팩트(artefact)가 보인다면 해당 옵션을 비활성화해야 한다.

Ask name on create:

해당 옵션을 활성화하면 폼에 새 컴포넌트를 드롭할 때마다 IDE는 사용자에게 어떻게 명명할 것인지를 물으면서 컴포넌트의 클래스를 기반으로 기본 이름을 제시한다. 이는 초보자에게 유용한 옵션인데, 이러한 질문은 어떠한 이름이 적절할 것인지 사용자가 생각하도록 만들기 때문이다. 이름을 잘 지을수록 특히 다른 사람들을 위해 코드의 가독성과 일관성을 향상시킨다. 단, 숙련된 프로그래머들에겐 이 기능이 거슬릴지도 모르겠다.

Switch to Object Inspector Favorites tab:

해당 옵션은 이전 옵션과 함께 작동하며 Ask name on create 옵션이 활성화 시에만 이용 가능하다. Switch to Object Inspector Favorites tab 옵션을 이용 시, Favorites 페이지에 포커스를 설정한 채로 사용자가 새로 드롭된 컴포넌트의 이름을 입력하면 (또는 수락 시) IDE는 오브젝트 인스펙터를 활성화시키게 된다.

Check packages on form create:

해당 옵션을 활성화하면 라자루스는 사용자가 설치 중인 컴포넌트에 필요한 패키지들이 모두 설치되었는지 확인한다. Guide lines 는 현재 선택이 어떠한 컨트롤에 조정되어 있는지 표시한다 (Show Guide Lines 를 활성화 시).

Snap to Guide Lines:

폼 디자이너 내에서 컴포넌트를 움직이면 (또는 크기를 변경하면) 가장 가까운 격자선에 정확히 맞물려 이동한다. 좌측과 우측 격자선의 색상은 Guide lines Left, Top의 Colors 섹션에서 설정되고, 우측과 하단에 조정된 격자도 마찬가지다.

오브젝트 인스펙터 페이지

해당 페이지는 오브젝트 인스펙터(Object Inspector)의 모양과 행위를 설정하도록 해준다. Colors 는 오브젝트 인스펙터의 다양하게 열거된 부분들을 원하는 대로 그릴 수 있도록 해준다. 각 항목을 따로 설정하고 싶지 않다면 모든 색상으로 한 번에 설정하는 Use default Lazarus settings 버튼을 클릭하거나 Delphi 기본 값을 선택하면 Speed settings 버튼이 생긴다. 두 가지 설정 간 가장 큰 차이는 Lazarus 기본 값에서 제공되는 추가 색상을 들 수 있다.

Miscellaneous 섹션은 각 프로퍼티 행(property row)의 기본 높이를 설정하는 Item height 한 가지 옵션만 제공한다. 위젯 셋을 제한 시 에디트(edit)와 콤보 상자의 크기를 변경할 수 없다 (예: Win32 위젯 셋은 콤보상자 높이의 변경을 허용하지 않는다).

Options 섹션은 여러 개의 오브젝트 인스펙터 행위를 제어한다:

Show hints는 마우스를 프로퍼티 위에서 왔다 갔다 할 때 힌트를 보여주는 기능을 한다.

Auto show 를 선택하면 오브젝트 인스펙터가 시작 시 항상 표시되며 이전 세션이 끝나기 전에 닫히더라도 마찬가지다 (보통 윈도우 창은 저장되고 다음 시작 시 이전 상태 그대로 복구된다).

Bold non default values 는 기본 값과 다른 값을 가진 프로퍼티를 모두 볼드체로 표시하여 쉽게 구별하도록 해준다.

Draw grid lines 는 프로퍼티들을 (그리고 이벤트들을) 점선으로 각각 구분한다.

Show gutter 는 프로퍼티 (또는 이벤트) 이름의 좌측에 수직 구분선을 그린다 (해당 옵션의 설정과 상관없이 거터(gutter) 공간이 항상 그려진다).

Show status bar 는 오브젝트 인스펙터의 베이스(base)에 상태 표시줄(status bar)을 표시한다.

Show information box 는 선택된 프로퍼티에 관한 정보가 포함된 (때로는 상세한 정보) 프로퍼티 리스트 아래에 (위의 페이지에 표시되는 내용과 상관없이 표시) 정보 패널을 포함시킴으로써 Object Inspector taller를 만든다. 해당 정보는 fpdoc 으로 쓰인 XML 도움말 파일에서 불러오며, 라자루스 프로젝트에 지식이 많은 지원자들이 기여하면서 더 광범위해지고 있다.

그림 3.58: IDE Options 대화창의 Naming 페이지

참고: 각 프로젝트는 어떠한 확장자를 가진 파스칼 소스 코드 파일이든 정의할 수 있다. 이는 Default pascal extension 을 기반으로 IDE가 덮어쓴다.

컴파일 전에 IDE는 모호한 파일명이 있는지 검사한다 (예: 유닛 경로에 유닛이 두 번 표시).

하지만 컴파일러는 일치하는 첫 번째 유닛을 취하는데, 그 결과가 개발자가 필요로 하는 결과가 아닌 경우가 있어 원인을 찾기 힘든 이상 오류 메시지가 발생하기도 한다. Ambiguous file action 을 이용해 그러한 상황에 대해 구체적인ㅡ그리고 더 유용한ㅡ액션을 설정할 수 있다.

Save as 섹션은 크로스 플랫폼 개발자들에게 중요하다. 대·소문자에 민감한 파일 시스템(예: Windows)용으로만 프로그래밍하고 다른 체제들과는 코드를 공유하지 않을 경우 No automatic renaming 옵션은 매우 만족스러운 기능을 할 것이다. 그렇지 않다면, 소스 파일명을 대.소문자에 민감한 플랫폼에 맞게 쓰여야 하며, 사용자는 컴파일러가 대.소문자가 동일하게 저장된 파일을 어떻게 검색하는지 이해해야만 한다. 컴파일러는 먼저 uses 섹션에서 쓰인 유닛 이름을 검색한 다음 모두 소문자에서 이름을 검색하고, 이후에 대문자에서 이름을 검색한다.

모든 유닛 이름은 대.소문자가 올바르게 적히도록 (Windows 사용자에겐 쉽지 않다) 확실히 하거나, IDE가 모든 유닛을 소문자 이름을 자동으로 저장하도록 명령하거나, 아니면 IDE가 저장 시마다 사용자에게 결정을 묻도록 명령할 수 있다.

에디터(Editor)는 소스 코드에 쓰일 때 유닛 이름을 표시한다. IDE는 이름이 uses 절에 처음 쓰이는 방식을 항상 표시한다. 라자루스 0.9.28 버전부터 새로운 섹션이 추가되어 유닛을 재명명 시 유닛 참조로 무엇을 해야 하는지 명시할 수 있도록 해준다. 참조는 항상(Always), 절대 하지 않음(Never) 또는 사용자에게 묻기(Ask)로 업데이트할 수 있다. 일반 설정은 라자루스로 하여금 새로운 파일이 생성될 때마다 라자루스에 Ask for a file name (파일명 묻기) 를 명령하도록 해준다.

FPDoc Editor 페이지

해당 페이지에서는 FPDoc 도움말 파일의 위치에 대한 경로를 설정할 수 있다. XML 포맷으로 이용 가능한 이러한 파일들은 LCL과 RTL을 문서화하고, 지속적으로 수정, 확장, 향상된다.

그림 3.59: IDE Options 대화창의 FPDoc 에디터 페이지

Editor 페이지

해당 페이지에서는 라자루스 소스 코드 에디터의 모양과 분위기(look and feel)를 제어하는데, 때로는 에디터의 트위킹 기능(tweaking aspect)에 대한 옵션들이 혼란스러운 배열로 제공되기도 한다.

General 페이지

General 페이지는 에디터의 행위를 제어한다. Undo/Redo 설정은 (잘못된) 실행을 되돌린다. Undo after save를 선택하면 실행 취소 리스트가 파일 저장 이후에도 계속하여 사용자는 파일로 저장한 후 변경내용을 되돌릴 수 있다. Group Undo는 동일한 유형으로 연속된 변경내용을 모아 작은 변경내용을 매번 되돌릴 필요 없이 한 번의 실행 취소로 모두 되돌린다. Group undo 또한 반복 액션을 다룬다. Undo Limit에서 실행취소 액션의 최대 수를 설정할 수 있다.

그림 3.60: 에디터 옵션의 General 페이지

Scrolling 설정에서 Scroll past the end of files는 EOF 문자를 스크롤해 넘기도록 해준다. Half page scroll 을 선택하면 스크롤이 반 페이지씩 위 아래로 실행되며 (한 번에 반 페이지씩) 마우스 휠을 사용하거나 [PgUp] 또는 [PgDn[ 키를 이용할 수 있다.

Scroll by one less 는 한 페이지보다 한 행 적게 스크롤한다.

Show scroll hint

Show scroll hint를 활성화하고 에디터 페이지에서 마우스 휠을 사용하면 작은 힌트창이 상단 우측에 나타나면서 행 번호를 표시한다. 스크롤한 후부터 1.5초가 지나면 힌트창은 자동으로 사라진다.

Indent and Tabs 에 대한 설정은 들여쓰기와 탭의 처리를 제어한다. Auto indent를 이용하면 새로 삽입된 행의 커서가 바로 위에 있는 행과 동일하게 들여 쓴다. 이는 서로 속한 부분들을 시각적으로 동일한 수준으로 묶음으로써 소스 코드의 가독성을 향상시킨다.

Tab intents blocks 를 이용하면 코드의 블록을 선택하고 [Tab] 키를 눌러 모두 들여쓰기 한다. [Shift]+[Tab] 키는 블록의 들여쓰기를 없앤다.

Block indent는 블록을 몇 자 들여 쓸 것인지 설정한다 (Edit ⇒ Indent selection 참고). 기본 값은 2칸이다. Autoindent 콤보상자는 (일부 라자루스 버전에선 Block indent로 잘못 표기되어있음) 새로운 행 앞에 공백을 채우는 방법 3가지를 제공한다: Spaces 는 공백 문자를 이용해 채운다.

Space/tab as prev line 은 위의 행과 동일하게 탭과 공백을 혼합하여 사용한다.

Position only 는 커서를 올바르게 위치시킬 뿐이다. 사용자가 무언가 입력할 때 들여 쓴 자리는 공백으로 채운다.

Smart tabs 는 행의 시작을 넘어 타이핑할 때 [Tab] 키의 사용에 영향을 미치는데, 위의 행에서 다음 단어의 수준만큼 커서가 들여쓰기 되는 결과를 낳는다. 현재 행이 위의 행보다 긴 경우 이전 행들 중 더 긴 행을 검색한다. Tabs to spaces 는 사용자가 에디터에 입력하는 모든 탭이 적절한 수의 공백으로 변환될 것이다. 이는 현재 행에서의 타이핑에만 영향을 미친다. 파일 내 모든 탭을 공백으로 대체하고 싶다면 [Ctrl]+[A]로 전체 텍스트를 선택 후 Edit->Tabs to spaces in selection을 선책하면 대화창이 시작된다.

Tab widths 는 탭이 나타내는 공백 수를 정의한다.

커서 동작은 Cursor 섹션에서 제어된다.

Keep cursor X position 은 소스 코드에서 커서를 이동시킬 때 수평적 위치를 유지한다. 따라서 스크롤 할 때 커서가 변경되지 않음을 의미한다-즉, 커서가 10번째 문자에 위치한다면 10번재 문자에 남는다.

기능을 비활성화하면 커서가 행의 시작 또는 끝으로 건너뛴다.

Persistent cursor 는 스크롤 시에도 커서가 표시된다.

Always visible cursor 는 에디터가 포커스를 잃었을 때 커서가 계속 깜빡이도록 한다. 해당 옵션은 메시지 포커싱이 적절하게 이루어지지 않는 일부 시스템에 필수적이다.

Caret past the end of line 은 커서가 행의 마지막 문자를 넘어가도록 해준다.

비활성화하면 커서가 다음 행으로 넘어갈 것이다.

Cursor skip selection 을 이용하면 커서는 [←] 키를 누르면 선택된 텍스트의 시작으로 건너뛰고, [→] 키를 누르면 선택된 텍스트의 끝으로 건너뛴다. Home key jumps to nearest start를 활성화하고 [Home] 키를 누르면 행 시작으로 데려가고 End key jumps to nearest end를 활성화 후 [End] 키를 누르면 행 끝으로 건너뛴다.\

그림 3.61: IDE Options 대화창의 Editor 섹션 내 Misc 페이지

Misc 페이지

공통적 에디터 설정들은 구분된 Misc 페이지에서 그룹화된다.

Show special characters 는 공백을 점(.)으로 표시하고 유효하지 않은 문자는 물음표 기호(?)로 표시한다.

Trim trailing spaces 는 행의 끝에 공백을 제거한다 (편집된 행만 적용). Find text at cursor를 선택하면 검색 함수를 호출할 때 커서 위치에 있는 단어가 검색 필드에 입력되어 직접 입력하지 않아도 된다.

Copy word on name 을 활성화하면 Edit ⇒ Copy ([Ctrl]+[C])를 호출할 때 어떠한 텍스트도 선택되지 않은 경우 커서에 위치한 단어가 클립보드에 위치된다. Edit→Cut ([Ctrl]+[X])도 마찬가지다.

Copy/Paste with fold into 를 선택하면 IDE 내에서 복사된 텍스트가 복사 시 접혔는지(folded)를 IDE가 기억하여 (해당 시) Edit ⇒ Paste ([Ctrl]+[V])에 폴드(fold)를 다시 복원시키도록 명령한다.

Trim spaces style:

해당 콤보상자는 공백을 얼마나 공격적으로 제거할 것인지 설정하도록 해준다. SynEdit (IDE 에디터가 기반으로 하는 컴포넌트)는 행의 끝에 'uncommitted' 공백을 입력하여 계속해서 타이핑할 수 있도록 허용한다. SynEdit가 만일 그러한 공백이 더 이상 필요 없다고 판단하면 공백제거(trim)할 것이다. 이러한 경우 사용자가 행의 끝에 입력하는 공백은 파일에서 저장되지 않을 것이다.

• Leave Line: 기본 값으로, SynEdit는 현재 행의 끝에 모든 공백을 유지할 것이다. 탈자 기호(^)가 다른 행으로 이동하면 행의 끝에 있는 공백이 제거된다.
• Line Edited: Leave Line 과 동일하지만 추가로 행이 편집 시 SynEdit는 탈자 기호(^)의 우측으로 공백을 제거한다. 행의 끝에 공백을 입력하면 탈자 기호(^)의 좌측이 되어 영향을 받지 않는다.
• Caret or Edit: 가장 공격적인 방법으로, Line Edited 와 동일하지만, 수평으로 이동 시 탈자 기호(^)의 우측 공백을 제거한다; 따라서 행의 끝에서의 커서 왼쪽 이동은 [BkSp] 키의 역할을 한다.
• Position Only: 행의 끝을 지나선 어떠한 공백이나 탭도 삽입되지 않는다. 탈자 기호(^)만 이동한다 (그리고 EOL을 강제로 넘긴다). 텍스트를 타이핑하면 간격은 항상 공백으로 채워지며, 탭은 손실됨을 의미한다 (공백으로 변환). 따라서 자동 들여쓰기된 “copy tab”는 해당 모드에선 작동하지 않으며, EOL을 지났기 때문에 smart un-indent도 해당 모드에서 작동하지 않는다.

Source notebook tab position: 해당 콤보상자는 에디터에서 하나 이상의 파일을 편집 시 탭이 어디에 위치하는지 설정하도록 허용하고 탭이 있는 노트북 모양을 하여 각 페이지 또는 파일을 선택하도록 해준다. 이러한 탭은 에디터 노트북의 상단 (기본 값), 하단, 좌측 또는 우측에 위치할 수 있다.

Display 페이지

Display 페이지는 에디터의 외관을 제어한다.

Visible right margin 은 에디터의 우측 테두리에 수직선을 위치시켜 우측 여백(margin)을 표시한다. 이는 개발자들이 과도하게 긴 행을 사용하지 않도록 (소스 코드를 읽기가 힘들기 때문에) 돕는다.

Right margin 콤보상자는 기본 값에서 (우측으로 80자) 우측 여행의 위치를 변경하도록 해준다.

에디터의 좌측면은 회색 테두리, 거터(gutter)이다. 행 번호라든지 추가 정보도 표시할 수 있는데 이를 표시하지 않으려면 Visible gutter를 비활성화한다. 행 번호를 표시하려면 Show line number를 활성화시켜야 한다.

모든 행에 번호를 매길 필요가 없다면 번호매김을 각 n번째 행으로 설정할 수도 있다. 테두리를 따로 설정하는 것은 거터(gutter)가 표시될 때만 효과적이다.

그림 3.62: IDE Options 대화창 Editor 섹션의 Display 페이지

다음 섹션에서는 에디터에서 사용하는 폰트 설정을 변경할 수 있다. 컴퓨터에 설치된 폰트는 어떤 것이든 선택이 가능하지만 운영체제와 위젯 셋에 따라 이용 가능한 폰트에는 차이가 있다. 때때로 소스 코드 에디터 디스플레이를 사용하려면 적절한 폰트를 먼저 설치해야 하는 경우도 있다.

운영체제의 표준이 아닌 위젯 셋을 사용할 때는 조심해야 한다. 예를 들어, Linux KDE 인터페이스는 Qt를 기반으로 하지만 라자루스는 기본적 Gtk2 위젯 셋으로 컴파일된다. 이런 경우 운영체제 폰트 설정이 소스 코드 에디터에 어떠한 영향도 미치지 않을 것이다.

어떠한 경우든 가독성이 좋은 폰트를 선호한다: 예를 들어, 숫자 0과 문자 O가 명확히 구분되어야 한다. Default editor font가 콤포상자에 표시된다. 그 옆에 [...] 버튼을 누르면 다른 폰트를 선택할 수 있는 대화창이 열린다. 아래 창은 변경된 내용의 미리보기를 표시한다. 폰트의 크기는 구분된 Editor font height 필드에서 설정된다 (음수 값은 값 내 행 띄우기(line spacing)를 포함하고 양수는 포함하지 않는다). Extra line spacing은 주위 행들 간에 추가로 공백을 (픽셀) 더하도록 해준다. Extra char spacing 필드의 문자에 대해서도 동일하다.

Disable anti aliasing을 이용해 폰트 디스플레이의 명확성을 향상시킨다.

그림 3.63: IDE Options 대화창의 Display 섹션 내 Colors 하위페이지

Colors 페이지

Colors 페이지에서는 에디터의 색상 하이라이트를 설정한다. 페이지 하단에서 가장 좌측에 있는 툴버튼은 (작은 abc 아이콘) 현재 언어에 대한 프로그램식 하이라이트를 토글로 켜고 끈다.

그 옆의 콤보상자는 (기본 값: ObjectPascal) 사용자가 사용 중인 각 프로그래밍 언어에 색상 배합을 선택하도록 해주고, 각각은 사전에 정의된 문법 하이라이트를 가진다. 이용 가능한 '언어'는 다음과 같다:

Object Pascal (기본 값), HTML document, C++, XML document, Lazarus Form definition, Perl, Java, UNIX Sheel Script, Python, PHP, SQL, Javascript, Diff file, MS-DOS batch language, INI file.

근접한 콤보상자는 여러 색상 배합을 제공한다: Default, Delphi, Pascal Classic, Twilight, Ocean.

언어를 먼저 선택하고 색상 배합, 다음으로 단일 요소들을 선택할 것을 권한다.

파일 확장자 콤보상자는 문법 하이라이트를 적용할 파일의 범위를 설정하도록 해준다.

바로 옆의 내보내기(export) 툴버튼은 (플로피디스크 아이콘) 수정한 색상 배합 설정을 XML 파일로 저장하도록 허용하여 사용자 색상 배합을 다른 사용자들과 공유하도록 해준다. 가장 우측의 툴버튼 Set all elements to default는 선택된 하이라이트와 색상 배합에 따라 모든 요소들을 리셋한다.

Element Attributes 섹션에는 서로 상극되는 버튼 두 개가 있다: Use (and edit) global scheme setting 또는 Use local scheme setting. 미리보기 창에는 현재 언어에 대한 모든 요소들의 현재 하이라이트 설정을 표시한다. 요소들 중 하나를 클릭하면 아래 필드에 설정이 표시된다. 아니면 미리보기 창에서 텍스트의 요소를 클릭하는 방법도 있다.

변경 내용이 만족스럽지 않다면 마지막으로 남은 Set element to default 툴버튼이 선택된 하이라이트와 색상 배합에 따라 기본 값을 복구시킬 것이다.

Markup and Matches 페이지

Markup and Matches 페이지는 이전에 Automatic features에서 포함되었던 (pre version 0.9.29) 설정들을 제공한다.

그림 3.64: IDE Options 대화창의 Editor 섹션 내 Markup and Matches 페이지

Markup and Matches 페이지는 하이라이트 또는 자동 완성과 같이 바탕화면에서 자동으로 실행되는 기능들을 제어한다.

커서가 에디터 내 어떤 단어에서 일시정지(pause)되면 이 단어와 단어의 다른 모든 인스턴스들이 하이라이트로 표시된다. 이는 소스 내에 특정 변수가 어디서 나타나는지 자동 개요를 제공한다. 하이라이트가 트랙 바(track bar)로 표시되기 전에 지연 시간을 0부터 (좌측) 4까지 (우측) 설정할 수 있다.

트랙 바 눈금(Trackbar graduation)은 어떠한 시간 단위도 가지지 않지만 트랙 바 가장 우측 끝 위에 붙은 라벨은 포인터 끝이 변경될 때 시간 설정을 동적으로 보고한다.

엄청 큰 파일에서 현재 단어를 검색하면 엄청난 시간이 소요되어 추가 편집을 할 수 없다. 따라서 사용자는 Disable Timer for Markup Current Word 확인상자를 이용해 타이머를 비활성화시킬 수 있다. 특정 유휴 시간(idle)이 지나면 하이라이트가 발생한다.

Ignore Keywords를 활성화하면 하이라이트로부터 키워드를 제외시킨다. 무엇이 키워드인지는 선택된 문법 하이라이터에 따라 좌우된다 (기본 값: Object Pascal).

Trim spaces 옵션은 하이라이트 도중에 불필요한 공백을 제거하는 기능을 한다. Match word boundaries for words up to this length를 이용하면 본래 단어 자체가 더 길지 않다는 점을 감안해 하이라이트가 문자의 설정 수보다 적은 단어로 제한된다. Bracket highlight는 중첩된 함수 또는 프로시저가 서로 내부에서 시작해 끝나는 것을 추적하도록 돕는 유용한 기능이다. 커서 좌측, 커서 우측, 양쪽 괄호 "( )"를 하이라이트하거나 또는 전혀 하이라이트하지 않도록 설정할 수 있다.

몇 가지 설정 외에도 색상 표시가 된 링크는 Colors 페이지에 해당 항목으로 접근을 가능하게 하여 항목의 모양을 변경할 수 있다.

Highlight control statements as keywords는 이름대로 제어문을 키워드로 하이라이트 표시한다.

그림 3.65: IDE Options 대화창의 Editor 섹션 내 Key Mapping 페이지

Key Mappings 페이지

Key Mappings 페이지는 라자루스의 키 매핑 설정을 위한 전반적인 옵션을 제공한다. 다른 IDE 버전을 사용한 경험이 있어 키보드 매핑에 익숙하다면 라자루스의 매핑 사용을 원할지도 모른다. 아니면 운영체제나 다른 중요한 프로그램들이 이미 원하는 하나 또는 그 이상의 키 조합을 차지하고 있어 매핑을 변경해야 할 수도 있다. 키 매빙을 변경할 수 없을 시 라자루스 IDE 함수 대신 운영체제 함수를 호출하는 결과가 발생할지도 모른다. 라자루스는 예외가 허용되는 모든 운영체제로서가 아니라 크로스 플랫폼 개발 환경으로서 개발되었을 뿐이다.

많은 라자루스 IDE 명령은 특정 명령 그룹 내 창에 열거되어 있다. 그룹 앞에서 "▶" 셰브런 (일부 운영체제에선 +) 아이콘을 클릭하면 노드를 펼쳐 그룹 내 모든 명령이 표시된다.

상단의 (filter) 필드에선 특정 명령 이름을 증분적으로 검색한다 - 사용자가 입력하는 각 문자는 동적으로 감소한다.

다른 매핑 검색 방법을 선호할 경우 Find key combination 버튼을 이용할 수 있다. 버튼을 클릭 시 나타나는 대화창에서 키 조합을 수동으로 타이핑하거나 Grab key 버튼을 이용할 수 있다.

Grab key 버튼을 이용해 대화창이 열리면 사용자는 원하는 키 조합을 누른다. 키는 표시되고 OK로 승인하고 나면 해당 키에 매핑된 명령만 표시된다 (명령이 이미 할당된 경우). 라자루스에는 Choose scheme 버튼으로 로딩 시 이용할 수 있는 몇 가지 기본 키 매핑이 있다.

그림 3.66: 키 매핑 조합을 선택하는 대화창, Key Mapping 페이지에서 호출

Check consistency 는 한 번 이상 사용된 키를 검색하여 적절한 메시지를 제시한다. 중복된 단축키로 명령들 중 하나를 클릭하면 단축키 설정을 변경하는 대화창이 열린다.

Mouse 페이지

라자루스는 에디터에서 마우스의 행위를 원하는 대로 설정하게 해주는 수많은 옵션을 제공한다. 기본 설정은 Mouse 페이지에서 찾을 수 있으며 (그림 3.67) 상세한 설정은 두 번째 페이지 Advanced에서 제공된다. 가끔씩 편집을 위해 사용자가 클릭한 소스 코드 위치를 마우스 커서가 덮고 있음을 발견할 것이다. 클릭 후 마우스를 치워버리거나 Hide mouse on typing 설정을 활성화시키는 방법이 있다. 해당 옵션을 선택하면 사용자가 타이핑할 때 마우스 커서가 표시되지 않는다 (키보드 비활동이 끝나면 다시 나타나긴 하지만).

Gutter 섹션에는 두 가지 옵션이 있다. Standard 를 선택하면 마우스가 거터를 클릭할 때 해당 액션이 실행된다. Extended 를 선택하면 마우스를 클릭한 후 해제시킬 때 액션이 실행된다. 이러한 방식을 이용해 액션이 실행되기 전에 마킹(marking)을 완료할 수 있다.

Text 섹션은 소스 코드에 영향을 미치는 설정들을 포함한다. Alt-key sets column mode는 [Alt] 마우스 조합을 이용해 세로 구역(column block)을 선택하도록 해주는데, 이는 마우스만 이용해 드래그하여 수평적 세로 구역을 선택하는 방식과 동일하다.

에디터에서 오른쪽 마우스를 클릭하면 보통 컨텍스트 메뉴가 열린다. 이 때 커서를 오른쪽 마우스 클릭 위치로 이동시키길 원하는 경우 Right mouse button moves cursor 를 활성화해야 한다.

Drag Selection 은 왼쪽 마우스 버튼을 이용해 현재 선택 내용을 소스 코드 내 다른 위치로 이동시킬 수 있게 해준다. 추가적으로 [Ctrl] 버튼을 누른 채 실행하면 내용이 복사된다.

보통 더블 클릭은 단어를 선택하고, 세 번 클릭하면 행을 선택한다. 더블 클릭으로 행을 선택하고 싶다면 Double Click selects line을 선택하라.

그림 3.67: IDE Options 대화창의 Display 섹션 내 Mouse 페이지

트리플 버튼(triple-button) 마우스를 사용하려면 마우스 중간 클릭 액션을 다음 옵션 중 하나로 선택할 수 있다:

• Paste selection: 복사가 활성화된 경우 클릭 위치로 복사된다.
• Jumps to implementation: 소스 코드 내에 현재 메소드 식별자가 구현된 위치로 점프된다 (다른 유닛에 위치한 경우라도).
• Nothing: 어떠한 액션도 실행되지 않는다.

[Ctrl]과 왼쪽 마우스 클릭 조합에 대해 다음 액션을 설정할 수 있다:

• Jumps to implementation:
  소스 코드 내에 현재 메소드 식별자가 구현된 위치로 점프된다 (다른 유닛에 위치한 경우라도).
• Jumps to implementation/other block end:
  커서가 식별자에 위치하지 않고 괄호, 시작 혹은 끝에 위치한 경우 해당 괄호나 단어로 점프된다.
• Nothing: 어떠한 액션도 실행되지 않는다.

모든 페이지 하단에 위치한 OK를 클릭하면 해당 페이지와 Advanced 페이지에서 변경한 내용이 저장된다.

Advanced 페이지

Advanced 페이지는 (그림 3.68 참고) 구체적인 마우스 행위에 대해 많은 설정을 제공한다.

해당 페이지는 클릭을 방해하는 Window Manager (또는 운영체제)를 피할 수 있는 방법을 제공하는데, 이 옵션이 아니면 라자루스에서 따로 이용할 수 없다.

Advanced 페이지를 호출하는 것은 가능하지만 많은 사용자들은 필요성을 못 느낄 것이다. 라자루스는 여러 개의 운영체제에서 실행되어야 하기 때문에 일반 설정만으로 충분하지 않다 (또는 모든 운영체제에 공통되는 기반으로만 제한되어야 할 것이다).

관심 영역을 선택하여 (일러스트레이션에서와 같이 Text를 예로 들면) 중간 트리뷰(Options 네비게이션 트리뷰의 우측)에서 설정을 시작하면 가능한 마우스 액션들이 더 큰 창에 열거된다.

위의 Change, Add, Delete 버튼은 원하는 내용을 변경, 추가, 삭제할 수 있도록 해준다. 트리뷰(treeview)는 '일반' 텍스트를 클릭 시 Selection 텍스트를 클릭할 때와 다른 액션을 트리거할 수 있음을 보여준다. 마우스의 한 번, 두 번, 세 번, 네 번 클릭이 다르듯 (이론상으로는) 왼쪽, 중간, 오른쪽 마우스 버튼에 대해 다른 액션이 있어야 하지만 모든 플랫폼이 모든 조합의 사용을 허용하는 것은 아니다. 예를 들어, 윈도우는 마우스 세 번과 네 번 클릭은 왼쪽 마우스 버튼에 대해서만 설정을 허용한다.

액션은 올바르게 실행될 것을 확신할 때만 설정되어야 한다. 어차피 사용자가 2회 클릭 후 1회 클릭을 원하는지, 아니면 3회를 한 번에 클릭하길 원하는지 컴퓨터는 알지 못하는 것이 사실이다.

또한 마우스 클릭은 [Shift], [Ctrl], [Alt] 버튼으로 조합할 수도 있다. 중복되거나 모호한 클릭에 대해 우선순위를 설정하는 것도 가능하다.

우선순위가 가장 높은 구성이 (최하 번호) 선호되는 구성이다.

아래 표는 동일한 버튼에 추가된 액션을 표시한다. 이는 충돌이 발생하면 충돌을 빠르게 발견하도록 돕는다. 설정은 파일로 저장하고 파일에서 로딩시킬 수 있다.

그림 3.68: IDE Options 대화창의 Editor 섹션 내 Mouse 설정을 위한 Advanced 페이지

Completion and Hints 페이지

[이전에 Automatic features 에 (현재 존재하지 않음) 위치하던 설정이 Markup and Matches 페이지로 이동하지 않고 Completion and Hints 페이지로 옮겨갔다].

Markup and Matches 페이지에서와 같이 Completion and Hints 페이지는 힌트나 자동 완성과 같이 배경에서 자동으로 실행되는 함수들을 제어한다.

Auto remove empty methods는 유닛을 저장 시 실행된다.

옵션이 활성화되고 메인 클래스가 (보통은 폼, 예: TForm1) 할당된 코드가 없는 published 메소드를 포함하는 경우 (비어 있는 being... end construct), 이러한 메소드들은 제거된다.

Add close statement for Pascal blocks 옵션을 선택하면, 사용자가 begin을 타이핑한 후 [Enter] 키를 누르면 IDE는 자동으로 end를 추가한다.

Show declaration hints를 활성화하면 유용한 정보 '툴팁' 힌트가 표시된다.

Declaration hints는 커서가 식별자 위에서 멈출 경우 식별자의 선언에 관한 정보를 제공한다 (힌트가 나타나기 전에 지연은 상태 표시줄 아래에서 설정된다).

예를 들어, Show declaration hints를 선택하면 커서는 TForm에서 멈춰 힌트가 표시되고:

type TForm	 TForm: class
 C:\lazarus\lcl\forms.pp (691,3)

타입, 선언문, 식별자가 선언된 유닛, 해당 유닛 파일 내 선언의 위치와 행 번호가 제공된다.

Show value hints while debugging 은 IDE가 툴팁 내 커서에서 표현식의 분석을 시도하도록 야기한다. 이는 정수형(integer)과 부울형(boolean)과 같은 단순한 변수에 가장 잘 실행된다. 가끔씩 파일명이나 경로가 너무 길어 IDE에서 표시되는 컨트롤 내에 들어맞지 않는다.

툴팁에 컷오프(cut-off) 섹션을 표시하려면 (다른 컴포넌트를 덮어씀), Show long line hints 콤보상자에 Never 가 아닌 다른 값을 설정한다.

디스플레이 옵션에는 Extend right only, Extend some left, Extend far left 가 있다. 그러한 긴 힌트가 나타나기 이전의 지연시간은 콤보상자 위의 상태 표시줄에서 설정된다.

그림 3.69: IDE Options 대화창의 Editor 섹션 내 Completion and Hints 페이지

그림 3.70: IDE Options 대화창의 Editor 섹션 내 Code folding 페이지

Code folding 페이지

Code folding은 소스 코드 중 일부를 숨김 및 숨김해제하는 기능으로, 현재 포커스와 관련이 없는 코드의 일부를 일시적으로 제거함으로써 코드의 개요를 향상시킬 수 있다.

Code folding 페이지는 상단에 Code folding 확인상자를 이용해 코드 접기(folding)를 활성화 또는 비활성화하도록 허용한다. 코드 접기 기능은 에디터에서 거터 좌측 여백에 회색의 작은 [-] 또는 [+] 를 이용해 표시된다. 숨김 가능한 섹션의 시작 부분에 마이너스 부호가 표시되면 에디터에서 코드를 숨길 수 있다.

회색 행은 [-] 아이콘을 클릭하면 드롭되어 얼마나 많은 행을 숨길 수 있는지 표시한다. 플러스 부호는 해당 섹션을 숨김 해제하기 위해 클릭할 수 있음을 의미한다. 코드 접기 페이지에서 해당 섹션에 대한 확인상자를 활성화시킴으로써 어떠한 코드 섹션에 코드 접기를 허용할 것인지 선택한다.

예를 들어, Uses 확인상자를 활성화하면 코드 내 모든 uses 문 앞에 [-] 아이콘을 위치시켜 각 uses 섹션을 한 번의 클릭으로 접을 수 (또는 접기 해제) 있다. {%Region} 지시어는 임의로 접을 영역을 정의할 수 있도록 해준다 (Pascal 프로그램식의 포함 여부와 상관없이).

유닛 내에 숨김 섹션이 너무 많이 모아놓은 것을 발견할 경우 유닛을 둘 또는 이상 유닛으로 분리하는 것을 고려하길 권한다.

Divider drawing 페이지

에디터에는 프로그래머가 블록이 시작되고 끝나는 위치를 한 번에 보도록 돕기 위해 코드의 블록들 간 수평적 분할자(horizontal divider)를 그릴 수 있는 기능이 있다.

Divider drawing 페이지에서는 에디터에 해당 기능을 어떻게 작동시킬 것인지 명령한다. 각 언어와 블록 타입에 무엇이 '블록'을 구성할 것인지에 관한 세부 내용도 정의할 수 있다.

분할선(divider line)도 상세하게 구성 가능하다.

예를 들어, 'blocks' 리스트에 Procedure/Function 을 클릭하면 리스트 우측에 Draw divider level, Line color, Nested line color 라는 세 가지 제어 설정이 나타난다.

Draw divider level 을 1로 설정함으로써 모든 최상위 수준의 프로시저 또는 함수 뒤에 분할자를 위치시킬 수 있다. 아니면 중첩 함수를 원하는 수준까지 (2 또는 이상) 포함시킬 수 있다.

아래 logical break 뒤에 분할자를 위치시킬 수 있다:

Unit Sections	예: implementation, interface, initialization 부분.
Uses Clause	다중행이 되면 유용.
Var/Type	최상위 수준에서 어떠한 var, type 또는 const 블록이든 해당 (프로시저 내가 아닌).
Var/Type (local):	프로시저 내에 어떠한 var, type 또는 const 블록이든 해당. 중첩 수준은 얼마나 깊이 프로시저가 중첩되었는지 나타냄 (var 블록은 스스로 중첩할 수 없으므로).
Class/Struct:	클래스, 레코드 또는 오브젝트 선언. 중첩 수준은 클래스 내 정의된 레코드에 해당.
Class/Struct(local)	프로시저에 제한된 타입 선언 내에 사용 시 위와 동일.
Procedure/Function	Use right margin colour에 대한 기본 설정을 수락할 경우, 그려진 투명선은 코드 접기 선에 (사용 시) 일치됨.
Begin/End	case와 repeat을 포함하지만 try…except는 포함하지 않음. 중첩은 포함하는 프로시저까지 센다.
Try/Except	다른 end; 문으로부터의 try-finally 또는 try-except 블록의 final end; 를 식별.

참고: 완성되지 않은 블록은 (end가 없는 begin) 하이라이터를 속이고 단일행 블록이 무시될 수 있다.

그림 3.71: IDE Options 대화창의 Editor 섹션 내 Pages and Windows 페이지

Pages and Windows 페이지

Pages and Windows는 Options 대화창에서 비교적 새로 생긴 페이지로, 에디터에서 하나 이상의 개방파일이 있을 때 IDE가 어떻게 작동하는지를 조절하는 여러 설정을 포함한다.

Notebook Tabs 섹션

Show close button in notebook 옵션을 활성화 시 각 탭에 닫기 버튼[X]이 생긴다 (해당 옵션은 Windows에선 작동하지 않음).

에디터에 하나의 파일만 열려 있을 때 Hide tab in single page window를 활성화하면 어떠한 탭도 표시되지 않는다. 파일명과 수정된 상태(“*”)가 창 제목에 표시된다.

Ctrl-middle-click on tab closes all others 는 탭에 중간 마우스 버튼을 클릭하면 클릭된 페이지만 제외하고 노트북의 모든 페이지가 닫힌다. Show tab numbers in notebook 옵션을 활성화하면 파일이 열린 순서를 나타내는 숫자가 각 탭에 표시된다.

Use tab history when closing 은 이전 파일을 닫은 후 남은 개방파일 중 포커스를 맞출 파일에 영향을 미친다. 옵션을 활성화하면 가장 최근에 활성화된 페이지에 포커스를 둔다. 옵션을 비활성화하면 숫자가 가장 높은 페이지에 포커스를 맞춘다.

Find editor for jump targets 섹션

라자루스에서는 동일한 파일에 대해 여러 개의 에디터 창을 열 수 있다. 단, 페이지 업이나 다운, 단순한 검색 및 바꾸기, 다음 일치 단어 등은 현재 창이 유일하게 열린 에디터 창인 것처럼 작동한다.

파일에 대해 하나 이상의 에디터 창이 열려 있고 그 중 하나의 창이 포커스되어 있는데 (예: 검색 대화창을 열 경우) 사용자가 파일 내에서 검색 대화창이 찾은 결과의 새 위치로 점프하고자 하는 경우 어떠한 에디터 창으로 점프할 것인가?

Find editor for jump targets 섹션은 어떠한 중복파일 에디터 창을 점프 목표로 할 것인지 설정하도록 해준다.

설정들은 find-in-file 찾기 결과를 클릭할 때, 컴파일러 메시지를 클릭할 때, 북마크 또는 히스토리 지점으로 점프할 때, 선언으로 점프할 때 (다른 파일이 하나 이상의 에디터를 가진 경우 다른 파일 내에서) 액션에 영향을 미친다.

어떤 경우에선 동일한 파일 내의 Codetools 점프에도 (선언으로 점프 또는 interface 와 implementation 사이로 점프) 영향을 미친다.

예를 들어, 인터페이스 부의 선언부로 점프하고 싶은데 선언부가 이미 동일한 파일의 다른 에디터 창에 표시된 경우, 다른 에디터 창으로 전환하길 원할 수도 있다. 기본 값으로 라자루스는 현재 에디터를 사용할 것이다.

아니면 다른 파일로 점프하길 원한다면 그 파일에 대해 가장 최근 사용된 에디터를 사용할 것이다.

Order to use for editors matching the same criteria

파일 창 우선순위를 분석한 후에 하나 이상의 에디터 창을 사용해 사용자가 점프를 요청한 코드를 표시할 수 있다면 라자루스는 여기서 선택된 라디오버튼에 따라 에디터를 선택할 것이다.

• Most recent focused editor for this file (기본 설정).
  라자루스는 각 에디터가 언제 마지막으로 포커스되었는지를 기억한다. 이는 가장 최근에 포커스된 에디터로 다시 포커스를 맞출 것이다. 현재 에디터가 요청된 파일을 표시하고 점프 기준에 일치할 경우 최근 활성화된 에디터가 그 대상이 될 것이다.
• Editor (for file) in most recent focused window.
  해당 설정으로 라자루스는 각 에디터를 유지하는 창을 살펴본다. 이는 가장 최근에 포커스된 창을 재포커스한다 (현재 활성창도 포함).

위의 액션들 중 목표 에디터를 어떻게 찾을 것인지 변경할 수 있다:

• 에디터들 중 하나의 표시 화면 영역 내에서 코드 위치로 점프하되 가장 최근에 사용한 에디터에는 표시하지 않을 경우.
  위의 기본 설정은 마지막으로 포커스된 에디터로 데려가 목표 지점까지 스크롤해야 할 것이다. 대신 라자루스가 이미 올바른 위치에 있는 에디터를 사용하길 원할지도 모른다.
• 에디터를 중요한 위치로 (예: 사용자가 계속 참조할 필요가 있는 복잡한 데이터 구조) 스크롤하고 라자루스가 위치에서 벗어나지 않도록 원할 경우, 즉 라자루스가 점프 목표로 항상 다른 창을 이용하여 사용자가 준비한 창을 방해하지 않았으면 하는 경우. 이러한 경우 사용자는 페이지에서 스크롤되지 않도록 페이지를 “잠근” 후 라자루스가 다른 에디터를 사용하도록 강요할 수 있다.

많은 사례에서 위의 설정들은 동일한 결과를 야기한다. 하지만 현재 활성창이 파일 A에 대한 에디터를 가지지만 현재 파일 B를 표시하는 경우를 고려해보자.

파일 A는 다른 창에서도 표시되고 그 창에서 A에 대한 에디터는 현재 창보다 좀 더 최근에 사용된 적이 있다.

그렇다면 사용자는 파일 A에 대해 find-in-files 찾기 결과를 선택할 것이다.

Last editor focus를 이용하면 다른 창에서 에디터를 선택하고, Last window focus를 이용하면 현재 창에서 에디터를 선택할 것이다.

Priority list of criteria to choose an editor

라자루스가 사용자가 요청한 코드로 점프하기 위해 에디터를 찾아야 하는 경우 해당 우선 리스트(priority list)를 살펴보고 점프 기준에 일치하는 첫 에디터를 사용할 것이다. 기준이 하나 이상의 에디터에 일치할 경우 Order for editors matching the same criteria가 적용된다.

• Locked, if text in view: 어떠한 잠긴 에디터든지 표시 화면 영역에 요청된 목표를 이미 갖고 있는지 확인할 것이다.
• Unlocked, if text in centred view: Locked, if text in view 와 비슷하다. 'centred view'는 점프가 에디터를 스크롤하지 않는 텍스트 영역을 의미한다. 창 크기에 따라 화면상 첫 번째 또는 마지막 몇 개의 행으로 점프할 경우 에디터가 스크롤될 것이다. 하지만 최근에는 점프를 몇 회 할 경우 에디터의 위치 이동을 강요하나 스크롤은 계속될 것이다. 해당 옵션이 다른 옵션들과 구분되는 점은 잠긴 에디터가 항상 그 현재 위치에 있을 것이라고 가정하기 때문이다. 잠금 해제된 에디터도 동일한 위치에 있을지도 모른다. 따라서 해당 옵션을 선택하면 종종 창 또는 에디터를 예기치 못하게 변경할 가능성도 있다.
• Unlocked: 잠금 해제된 에디터. 다른 많은 기준들 역시 (locked only와 같이 명시적인 기준 제외) 스스로 잠김 해제된 에디터를 확인할 것이다. 해당 옵션을 해제하더라도 보통은 차이가 없다.
• New tab in existing window: 잠금 해제된 에디터를 찾을 수 없는 경우 기존 창에 새 탭을 연다. 해당 파일에 대해 잠긴 에디터가 모든 창에 위치할 경우 어떠한 탭도 열리지 않을 것이며 다음 기준을 평가할 것이다.
• New tab in new window: 잠금 해제된 에디터를 찾을 수 없는 경우 해당 에디터 또한 열수 있는 다른 창이 있다 하더라도 새로운 창에 새로운 탭을 연다. 이는 항상 작동할 것이므로 추가 기준은 절대 고려되지 않는다.
• Ignore locks, longest unused editor: 잠기지 않은 탭을 찾을 수 없는 경우 잠금은 무시될 것이다. 오랜 시간 사용하지 않은 (포커스되지 않은) 에디터가 사용될 것이다. 이는 항상 효과가 있을 것이므로 추가 기준은 절대 고려되지 않는다. ‘가장 길게 포커스를 벗어난 시간’은 항상 에디터의 포커스 순서에 따라 평가된다 (창에 포커스가 아니라).
• Ignore Locks, if editor is current. 잠금 해제된 탭을 찾을 수 없는 경우 현재 활성 창은 요청 파일의 에디터가 되고, 현재 활성 창의 잠금은 무시되어 사용된다. 현재 활성 에디터가 다른 파일을 표시하는 경우 다음 기준이 사용될 것이다.
• Ignore locks, if editor in current window: 잠금 해제된 탭을 찾을 수 없고 요청 파일의 에디터가 현재 활성창에 있는 경우, 에디터가 사용되고 그 잠금은 무시될 것이다. 현재 활성창에 파일의 에디터가 없는 경우 다음 기준이 사용될 것이다.
• New tab, existing or new window: 기본 폴백(default fallback) 행위로 비활성화시킬 수 없다 (확인상자가 영구적으로 체크되어 있음). 어떠한 에디터도 찾을 수 없는 경우, 새 에디터 페이지가 가능하다면 기존 창에, 아니면 새 창에 열린다.

About Page-Locking

페이지 잠금 기능은 각 에디터의 컨텍스트 메뉴에서 접근한다 (Lock Page 메뉴항목). 해당 메뉴 항목을 활성화시키기 위해 클릭하면 그 에디터 창을 잠그고, 상태 표시줄에 Locked라는 메시지가 위치한다.

이는 라자루스에 사용자가 이 에디터를 현재 위치에서 freeze시키고 싶음을 알리고, 페이지를 잠금 해제할 때까지 스크롤이 (마우스나 키보드 이동 키 모두) 비활성화된다.

페이지가 잠기고 사용자가 코드 내 어떤 위치로 (북마크, 선언, find-in-file 찾기 결과) 점프를 시도할 경우 라자루스는 다른 에디터를 사용해 (동일한 파일의) 목표 위치를 표시할 것이다. 증분 검색과 단순한 검색 & 바꾸기는 점프로 간주하지 않으므로 에디터를 재배치(relocate)시킨다.

JCF Format 설정 페이지

해당 페이지는 라자루스의 가장 최신 버전에서만 이용 가능하다.

0.9.28 버전까지는 가장 최신 버전과 달리 JCF Format 패키지가 기본 값으로 설치되어 있지 않다 (수동으로 설치는 가능).

라자루스로 통합시키는 작업은 현재 진행 중이며, 해당 포맷팅 툴을 위한 설정의 세부 내용은 여기서 다루지 않겠다.

Code Tools 페이지

라자루스 IDE는 파스칼 소스 코드를 (Object Pascal, Delphi 또는 Kylix 중 하나) 분석하기 위해 그 목적에 맞게 쓴 (purpose-written) Codetools라 불리는 라이브러리를 이용한다. Pascal 소스를 찾으려면 $IFDEF 검색 시 검색 경로와 컴파일러 플래그(compiler flag)가 필요하다.

해당 값은 소위 Define Templates라 불리는 규칙에 의해 정의된다.

코드툴은 모든 디렉터리에 일련의 값을 관리하고, 그 디렉터리 내 모든 유닛은 동일한 값을 (Paths and Flags) 공유한다.

따라서 패키지나 프로젝트가 동일한 설정을 공유하길 원한다면 사용자가 동일한 디렉터리에 두 개의 패키지 또는 프로젝트를 위치시키기만 하면 된다.

그렇지 않으면 디렉터리 기반의 시스템이 동시에 무한한 수의 다른 소스를 사용하도록 허용한다 (예: Free Pascal과 Dephi 소스 코드, 또는 다른 두 개의 Free Pascal 버전용 코드).

IDE는 재시작할 필요가 없으며 어떤 것도 재컴파일할 필요가 없다.

물론 컴파일러는 하나의 소스 타입만 처리할 수 있겠다.

General 페이지

Additional Source search path for all projects는 게으른 프로그래머들에게 패키지를 구성할 수 있는 기회를 제공하고, 패키지 또는 프로젝트를 공유하고 싶지 않은 프로그래머들에게는 해당 페이지에서 전역적 검색 경로를 입력할 기회를 제공한다.

Jumping (e.g. Method Jumping) 섹션

Adjust top line due to comment in front: 메소드 선언부에서 그 구현부로 점프하면 IDE는 에디터에 표시된 첫 행이 프로시저의 첫 행이 되도록 소스 코드를 위치시키고자 시도한다. 보통은 프로시저의 앞에 위치한 주석문은 프로시저에 속한다. 해당 설정을 활성화하면 점프 다음에 에디터가 주석문도 표시하도록 스크롤을 보장한다.

Center Cursor Line: 프로시저 본체(procedure body)에서 선언부로 (클래스 또는 인터페이스 내) 점프하면 IDE는 커서를 목표 행 중앙에 위치시킬 것이다.

Cursor beyond EOL: IDE가 새 위치로 점프하면 어떠한 위치로든 점프를 허용하여 행의 끝 밖까지도 점프한다.

Skip forward class declarations: 활성화되면 점프는 어떠한 forward 선언이든 모두 무시한다.

최근 라자루스는 example code를 기반으로 indentation을 설정하는 새로운 방식을 제공하고 있다. 제공되는 예시대로 포맷팅을 수락할 수도 있고, 아니면 자신만의 다른 포맷팅된 예제를 써서 사용자가 작동하고자 하는 들여쓰기(indenting) 방식을 발견하도록 IDE가 파싱(parsing)하게끔 만들 수도 있다.

해당 패턴은 자동 들여쓰기에 복사될 것이다. 사용자는 자신만의 포맷팅된 예제를 어디서 찾을 것인지 Example file에 입력한다.

그림 3.72: IDE Options 대화창의 CodeTools 섹션 내 General 페이지

Class Completion 페이지

Codetools가 새 소스 코드를 어떻게 생성하는지에 대한 설정은 Class Completion과 Code Creation 페이지에서 찾을 수 있다.

Class part insert policy: 클래스 선언부에 새 변수와 메소드를 Alphabetically(알파벳 순) 또는 Last(선언부 끝) 로 삽입할 수 있다.

Method insert policy: 메소드 본체(method body)가 구현부 어디에 삽입되는지를 나타내며, Alphabetically, Last (다른 메소드 구현부의 끝), 또는 Class order (interface 섹션 내 메소드 선언의 순서에 따라) 중 선택할 수 있다. Codetools가 클래스 완성 중 메소드와 프로퍼티를 따로 그룹화하길 원한다면 Mix methods and properties 설정을 비활성화시켜야 한다. 순서가 중요하지 않다면 해당 옵션을 활성화해도 좋다.

Header comment for class는 헤더 주석을 클래스 선언 앞에 추가한다. 예를 들어, TForm1의 정의에서 {TForm1} 주석문이 추가된다. Implementation comment for class는 동일한 주석문을 implementation 섹션의 첫 번째 메소드 앞에 선언부에서와 동일한 주석문을 추가한다.

Property completion 섹션은 아래 옵션들을 제공한다:

Complete properties: 해당 설정을 활성화하면 불완전한 프로퍼티 선언이 완료된다.

Set property Variable, Variable prefix, Stored postfix, Write prefix, Read prefix 필드들은 사용자가 원할 때 변경되는 프로퍼티를 완성하기 위한 기본 값이다.

Code Creation 페이지

Procedure insert policy는 새 프로시저 본체를 어디로 삽입할 것인지 IDE로 명령한다:

Last (예: 소스 끝), In front of methods 또는 Behind methods.

새 프로시저 본체를 삽입할 때 interface 섹션에서 프로시저 순서를 따르길 원한다면 Keep order of procedures 옵션을 활성화시켜야 한다. Codetools는 종종 이미 엔트리를 포함하는 uses 절에 종속 유닛을 삽입하도록 요한다. New units are added to uses sections 설정은 새 유닛을 추가할 위치를 IDE에 명령한다:

First, In front of related, Behind related, Last 또는 Alphabetically.

그림 3.73: IDE Options 대화창의 CodeTools 섹션 내 Class Completion 페이지

그림 3.74: IDE Options 대화창의 CodeTools 섹션 내 Code Completion 페이지

Words 페이지

Words 페이지는 새 키워드와 새 식별자를 어떻게 쓸 것인지 설정하도록 해준다 (UPPCASE[대문자], lowercase[소문자] 또는 첫 문자만 대문자화하는 Mixed case).

자동 재포맷팅을 원하지 않는다면 None 라디오버튼을 선택한다.

그림 3.75: IDE Options 대화창의 CodeTools 섹션 내 Words 페이지

Line splitting 페이지

이론상으로 유닛의 완전한 소스 코드는 단일 행에 쓸 수 있지만 이것은 분명히 잘 구조화된 코드는 아니다. 사용자는 보통 행별 최대 80자로 제한을 두곤 하는데 이러한 규칙은 GUI와 큰 (또는 다중) 화면이 출현하기 전에 비롯되었다. 텍스트 모드는 화면에서 80자로 된 행을 최대 25줄 허용했다.

라자루스 에디터는 80자 제한을 수직선으로 표기한다. 복합 표현식을 쓸 때는 (예: 다중 텍스트를 이용 시) 완전한 표현식이 한 행으로 충분하지 않은 경우가 있다. 줄바꿈(Wrapping)을 이용할 때는 가독성을 위태롭게 해선 안 된다. 따라서 Codetools는 줄바꿈을 실행하기 전에 줄바꿈 및 최대 행 길이 변경을 위한 많은 옵션들을 제공한다.

Line Splitting 페이지에는 OK 버튼으로 저장되기 전에 변경 내용의 효과를 표시하는 Preview 영역이 있다.

Space 페이지

사용자는 새 요소들 주변에 공백을 신중하게 삽입함으로써 사용자 코드의 가독성을 향상시킬 수 있다. Space 페이지는 사용자가 타이핑하는 동안 공백 문자의 자동 삽입을 설정하는 많은 옵션을 제공한다.

Preview 창은 많은 옵션을 적용했을 때와 해제했을 때 효과를 표시한다. 이와 같은 자동 기능들이 거슬린다면 단순히 모든 옵션들을 비활성화하여 기능을 모두 한 번에 끄면 된다. 이러한 옵션들을 JCF Format 설정과 결합할 경우 주의를 기울여야 하는데, 두 설정이 충돌 시 어떤 결과가 발생할 것인지 확실치 않기 때문이다.

Identifier completion 페이지

다양한 에디터 자동 기능들은 Identifier completion 페이지에서 활성화 및 비활성화할 수 있다. Pascal 문은 주로 세미콜론으로 끝나는데, Add semicolon을 활성화하면 사용자를 위해 세미콜론을 삽입할 것이다.

Identifier completion 페이지에서 사용자는 CodeTools가 세미콜론을 추가해야 하는지 여부를 결정할 수 있다.

값과 프로퍼티를 할당하기 위한 := 연산자도 마찬가지로, 활성화한다면 Add assignment operator := 는 그것(할당 연산자)을 삽입할 것이다.

식별자 완성은 Automatically invoke after point를 활성화했을 때에만 작동한다. 점을 삽입하고 나면 (예: Form1.) Form1 에 이용 가능한 모든 프로퍼티와 메소드가 포함된 선택 리스트가 나타난다.

더 많은 문자를 타이핑하면 리스트는 짧아진다.

올바르지 않은 엔트리를 선택할 경우 단순히 점이 포함된 삽입된 텍스트를 삭제하고, 다시 식별자 완성을 호출할 새 점을 입력하라.

식별자에 여러 섹션이 있는 경우 (에: Form1.Button1.Color) 각 점을 타이핑한 후에 완성 함수를 호출한다. Add parameters brackets 옵션은 파라미터 뒤에도 괄호를 자동으로 추가할 것이다.

그림 3.76: IDE Options 대화창의 Code Explorer 섹션 내 Update 페이지

Code Explorer 페이지

라자루스 0.9.28 버전부터 Code Explorer 에 관한 설정들은 IDE Options 대화창에 통합되었다.

Update 페이지

Preferred Exhibition Mode 섹션에서는 코드 익스플로러 리스트를 Category(카테고리) 별로 그룹화할 것인지 아니면 Source(소스) 코드에서 항목의 순서대로 표시할 것인지를 결정한다. Category를 선택하면 카테고리 설정(preference)을 다음 페이지에서 설정할 수 있다. 자동 재스캐닝의 트리거는 Refresh automatically 옵션에서 설정된다: Never, only manually (예: Refresh 버튼을 클릭 시에만), When switching file in source editor, 또는 On idle.

Categories 페이지

Categories 페이지는 이용 가능한 카테고리를 보여준다 (Category가 자신의 Preferred Exhibition mode일 경우에만 적용). 코드 익스플로러에서 보고 싶은 모든 카테고리를 활성화하라. 카테고리별 정렬은 Type, Variable 등을 기준으로 정렬함을 의미한다. Code Observer 카테고리는 코드 단편(code fragment)을 읽기 힘들거나 드문 경우를 열거한다. 이에 관한 자세한 내용은 다음 페이지에서 다루겠다.

Code Observer 페이지

Code Observer 페이지는 사용자의 코드에 대한 IDE의 분석을 볼 수 있도록 해준다. 이를 활성화하면 준최적(suboptimal), 일반(unusual) 또는 까다로운 코딩 읽기를 살펴볼 것이다.

해당 페이지는 IDE에게 사용자가 원하는 관찰을 하도록 명령한다 (사용자의 코드가 그러한 관찰을 야기할 경우). 코드 익스플로러는 빠른 검색을 허용하는데, 그 중 일부 개선내용은 사용자 눈에 띌 것이다.

Show observations about 섹션은 사용자가 지적하고자 하는 읽기 힘든 섹션 또는 불량하게 코딩된 섹션들을 결정하도록 해준다. 사용자는 전체 카테고리를 (Complexity, Empty constructs, Style, Other) 선택할 수도 있고, 아니면 Unnamed constants 또는 Wrong indentation 과 같이 하나 또는 두 개의 항목들만 활성화시킬 수도 있다.

Long procedures 는 Line count of procedure treated as long 필드가 허용하는 것보다 많은 행을 포함하는 프로시저를 모두 열거한다. 기본 값은 50줄이다. 그러한 프로시저를 접할 경우 Edit→Extract procedure를 이용해 나눌 것을 권장한다.

Many parameters 옵션은 Parameter count treated as many 필드가 허용하는 것보다 많은 파라미터를 포함하는 프로시저를 모두 열거한다. 기본 값은 파라미터 6개다.

Many nested procedures 는 Nested procedures count treated as many 필드가 허용하는 것보다 중첩된 하위 프로시저를 더 많이 포함하는 프로시저를 모두 열거한다. 기본 값은 3개의 하위 프로시저이다.

Empty procedures 는 노드를 (주석문과 지시어는 무시된다) 전혀 포함하지 않는 프로시저를 모두 열거한다. 리눅스에서 해당 옵션을 활성화하면 다음과 같은 프로시저를 찾을 것이다:

begin
  {$IFDEF win32}write('Win32');{$ENDIF}
end;

Empty blocks 는 begin과 end; 사이, 그리고 repeat과 until 사이에 코드의 유무를 검색한다.

Empty class sections 는 코드를 포함하지 않는 private, public 또는 protected 등의 섹션을 찾는다.

Unnamed constants 는 이름이 할당되지 않은 어떠한 상수든 검색한다 (주로 숫자가 될 것임). 그 밑의 필드에선 검색 시 무시하고자 하는 이름 없는 (unnamed) 상수를 입력할 수 있다.

Unsorted visibility 는 정렬되지 않은 클래스 섹션을 열거하는데, private 섹션이 public 섹션 뒤에 위치한 경우를 예로 들 수 있겠다.

Unsorted members 는 알파벳순으로 정렬되지 않은 모든 변수, 메소드, 프로퍼티를 열거한다.

Wrong indentation 은 들여쓰기가 잘못된 모든 행을 리스트로 생성한다.

Published properties without default 는 다음과 같이 기본 값을 제외한 값을 가진 모든 프로퍼티를 열거한다:

Published
  Property Flag: Boolean read FFlag write SetFlag;

컴파일러 버전 2.2.4 이후부터 그러한 프로퍼티는 nodefault 로 정의된 것처럼 취급된다. Code Observer 페이지의 하단부분은 여러 개의 값을 포함하거나 (제거 가능) 자신의 값으로 추가된 두 개의 Ignore 필드를 가진다. Ignored 값이 주의해야 할 카테고리에 속한다 하더라도 코드 오브저버(Code Observer)에 의해 열거되지 않는다. 예를 들어, Ignore constants in next functions 는 자주 사용되는 SQL 문자열을 무시하는 데 유용하다. 만약 필드에 .ParamByName 을 입력한다면, 다음과 같은 모양을 한 행은 고려되지 않을 것이다.

SQLQuery1.Params.ParamByName('FieldName').AsString := ...

Debugger 페이지

디버거(Debugger) 설정은 본 장의 마지막 부분에서 상세히 다루겠다.

그림 3.77: IDE Options 대화창의 Help 섹션 내 Help Options 페이지

Help 페이지

Help 페이지는 이용할 수 있는 온라인 문서의 경로를 설정하도록 해주며 (예: FCL 또는 RTL용) 해당 정보는 [F1] 키를 눌러 접근할 수 있다.

Environment ⇒ Code Templates 메뉴 옵션

그림 3.78: Code Templates를 관리하는 대화창

Code Templates는 '보일러플레이트(boilerplate)' 소스 코드의 섹션들로서 (예: if ... then ... else), 수동으로 입력할 필요 없이 코드에 삽입될 수 있다. 이는 단축키 조합으로 쉽게 호출된다.

[Ctrl]+[J]를 누르면 원하는 항목을 눌러 적절한 코드를 삽입할 수 있는 선택 메뉴를 불러온다. 원하는 코드 템플릿(code template)을 식별하는 첫 문자들을 사용자가 알고 있다면 더 빨리 코드 템플릿을 호출할 수 있다 (선택 창을 호출할 필요 없이). 위의 예제는 ife 를 입력한 후 [Ctrl]+[J]를 눌러 직접 호출한 것이다. 코드 템플릿은 텍스트뿐만 아니라 매크로도 포함 가능하다. 사용자는 설계 시 패키지를 생성하고 IDEIntf 패키지로부터 macrointf.pas 파일을 사용함으로써 자신만의 매크로를 추가할 수도 있다.

Environment ⇒ Code Templates 를 통해 접근한 Code templates 대화창은 기존 템플릿을 Edit(편집) 또는 Delete(삭제) 하도록 해주고, 제공된 버튼을 이용해 새 템플릿의 Add(추가) 도 허용한다. 몇몇 템플릿은 라자루스에 딸려 온다. Templates 리스트 내 템플릿을 클릭하면 아래 필드에 템플릿 코드를 표시한다.

그림 3.79: Code Template에 매크로의 삽입을 도와주는 대화창

위는 매크로를 포함하는 새 코드 템플릿을 추가하는 방법을 보여주는 예제이다. 새 템플릿은 코드를 추가하도록 설계되었고, writeln ('ProcName')과 같이 현재 프로시저의 이름을 출력할 것이며, wp [Ctrl]+[J]를 타이핑하여 호출해야 한다. Add 버튼을 이용해 Add code template 대화창을 열면 두 가지 단순한 옵션을 제공한다.

Token 필드에 wp 를 입력하라 (같은 이름으로 된 템플릿이 이미 존재하는 경우 새 이름을 선택해야 한다). Comment는 사용자의 코드 템플릿을 문서화하는 역할을 하며 템플릿 작동에 영향을 미치지 않는다. 해당 예제에서는 WriteLn (‘ProcName’) 을 타이핑한 후 Add 버튼을 클릭한다. 이는 Add code template 대화창을 닫고 Templates 리스트에 빈 wp 템플릿을 추가한다. 그 아래 긴 필드에 WriteLn (,｜); 지시어를 입력하라. 세로줄 '｜'는 파이프 문자로, (대다수 키보드에서 Z 키 옆에 위치) 새 커서 위치를 나타낸다.

Enable Macros 확인상자를 표시한다.

이제 커서를 첫 번째 브래킷 바로 뒤에 위치시키고 Insert Macro 버튼을 클릭한다.

Select Code Macro 대화창이 나타나면 이용 가능한 매크로가 모두 왼쪽에 열거된다.

ProcedureName 이 보일 때까지 스크롤하여 클릭한다.

해당 함수에 대한 설명이 Description 필드에 나타난다. 이번 예제에서 Parameter 필드는 비어 있을 것이다. Insert Macro 버튼을 클릭하고 삽입된 매크로를 닫기 위해 ' '를 추가한다. Code Templates 대화창은 이제 그림 3.80과 비슷한 모양을 할 것이다.

그림 3.80: 새 wp 템플릿이 추가된 Code 템플릿 대화창

OK를 클릭하여 Code templates 대화창을 닫는다. 이제 새 템플릿을 테스트하라. 메소드 본체에 wp 를 입력하라. 예를 들면 다음과 같다:

procedure TForm1.FormDestroy(Sender: TObject);
begin
  wp|
end;

세로줄 ｜은 여기서 커서를 상징한다. 그리고 나면 [Ctrl]+[J]를 누른다. 템플릿을 올바르게 입력하면 코드가 다음으로 확장된다:

procedure TForm1.FormDestroy(Sender: TObject);
begin
  WriteLn('TForm1.FormDestroy', | );
end;

Environment ⇒ CodeTolls Defines Editor... 메뉴 옵션

그림 3.81: CodeTools Defines Editor 대화창

Environment ⇒ CodeTools Defines Editor... 메뉴는 Codetools 설정 보기를 연다. 표시된 값은 Codetools에만 유효하며 컴파일러에는 적용되지 않는다. 검색 경로는 Environment→Options 설정, 컴파일러 설정, 패키지 에디터, 프로젝트 인스펙터에 의해 설정된다.

IDE는 이러한 값에 대한 노드를 자동으로 생성한다. CodeTools Defines Editor 대화창은 사용자가 이러한 노드 각각에 대해 Define templates(템플릿 정의)를 검사하고 편집하도록 해준다. 모든 값과 변수는 매크로를 포함할 수 있다. 대화창은 미니 애플리케이션으로서 자체 메뉴를 포함한다 (Exit, Edit, Tools, Insert Template).

템플릿을 편집하고 나면 변경내용은 Exit ⇒ Save and Exit 로 저장되며, 변경내용을 취소하고 싶다면 Exit→Exit without Save를 선택한다.

어떤 옵션이든 에디터 대화창은 닫힌다.

상단 트리뷰는 (그 바로 아래 splitter handler를 이용해 확장 가능) 처음에 아래에 해당하는 노드를 표시한다:

Use defaults, Free Pascal Compiler, Free Pascal sources, Lazarus sources, Packages, Projects.

사용자는 노드를 확장하고 원하는 항목을 클릭함으로써 시작한다. 해당 값은 (Text 또는 File Path 로서) 읽기만 가능한 아래 필드에 표시된다.

Value as File Paths 에서 텍스트 값은 세미콜론에서 분리되며 각 경로는 구분된 행에 표시된다.

항목의 Action, Name, Description, Variable (해당 시) 는 대화창 중간에 Selected Node 섹션에 표시된다.

Free Pascal Compiler, Free Pascal sources, Lazarus sources 노드들은 자동으로 생성되며 이 대화창에서는 편집할 수 없다.

Edit 메뉴는 사용자가 노드를 Move, Insert, Delete, Convert 할 수 있도록 해준다.

Move node up: 선택된 노드를 가장 가까운 상위 형제(upper sibling) 앞으로 이동시킨다.

Move node down: 선택된 노드를 가장 가까운 하위 형제(lower sibling) 아래로 이동시킨다.

Move node one level up: 노드를 그 부모를 향해 한 수준(level) 이동시킨다.

Move node one level down: 노드를 이전 형제의 자식으로 만든다.

Insert node below: 새 노드를 생성하여 선택된 노드 아래에 삽입한다.

Insert node as child: 새 노드를 생성하여 선택된 노드의 자식으로서 삽입한다.

Delete node: 선택된 노드를 제거한다.

Convert mode: 노드의 타입을 변경한다.

노드를 편집할 때는 아래의 타입들을 삽입에 이용할 수 있다:

Define: 현재 디렉터리에 대한 플래그/값을 설정한다.

Define Recurse: Define과 동일하지만 하위디렉터리도 고려한다. Undefine 을 이용하면 선택된 변수를 현재 정의 라이브러리로부터 제거한다.

Undefine Recurse: Undefine과 동일하지만 하위디렉터리도 고려한다.

Undefine All: Define과 동일하지만 모두 제거한다. 고유의 환경을 생성하는 디렉터리에 유용하다 (예: FPC 소스).

Block 노드 타입은 그룹화된 노드에만 이용 가능하다.

Directory 노드 타입은 특정 디렉터리에만 유효한 노드를 생성한다.

자식 노드들은 Value에 명시된 디렉터리에 대해서만 분석된다.

If 를 이용하면 Value 내의 표현식이 실행되고 컴파일러의 결과가 1이면 자식 노드가 실행된다.

프로그램식은 컴파일러에서도 동일하다. 예를 들어, aVariable 변수가 정의되면 defined (aVariable) 은 1을 리턴하고, 정의되지 않았다면 0을 리턴한다.

IfDef 를 이용 시, 변수가 정의되었다면 자식 노드가 실행된다.

IfNDef 를 이용 시, 변수가 정의되었다면 자식 노드가 실행된다.

ElseIf: 이전의 모든 Ifs 가 false를 리턴한 경우 ElseIf-노드가 실행된다. ElseIf 는 Else 그리고 If 와 동일하다.

Else: 이전의 모든 Ifs 또는 ElseIfs 가 false를 리턴할 경우 이 노드가 실행된다.

빈 값("")이 할당된 변수는 여전히 할당되어 있으므로 IFDEF variable 은 여전히 True를 리턴한다. Delete 는 변수를 제거한다.

그림 3.82: CodeTools Directory Values 대화창

Tools 메뉴에는 Open Preview 라는 한 가지 옵션만 존재하는데 이는 추가 설정을 만들 수 있는 CodeTools Directory Values 대화창을 연다. OK 를 이용해 대화창을 닫고 사용자는 다시 Codetools Defines Editor 대화창으로 돌아간다.

Insert Template 메뉴는 사용자가 선택한 템플릿으로부터 새 노드를 생성하여 현재 노드 아래에 삽입한다.

사용자가 이용 가능한 몇 가지 템플릿이 있다:

Free Pascal Project Template, Free Pascal Compiler Templat, Free Pascal SVN Source Template, lazarus Directory Template, Delphi 5/6/7 Compiler Template, Delphi 5/6/7 Directory Template, Delphi 5/6/7 Project Template

Environment ⇒ Rescan FPC source directory 메뉴 옵션

Rescan FPC source directory를 클릭하면 FPC 소스 코드가 저장된 디렉터리에 대한 IDE의 지식을 새로고침(refresh)한다. 라자루스는 올바른 이벤트 핸들러를 생성할 때를 비롯해 클래스, 프로시저, 변수 선언을 검색할 때 이러한 파일들을 이용한다. Environment ⇒ Options 설정에서 디렉터리를 변경하면 자동으로 새로고침 되어 라자루스가 올바른 파일을 사용하도록 보장한다. 하지만 라자루스가 인식하지 못한 채 디렉터리가 변경되는 경우가 더러 있다. 이러한 경우 오류 메시지가 발생하는데, Search ⇒ Find Declaration at cursor 를 예로 들 수 있다. 이런 일이 발생하면 환경 옵션에서 FPC 소스 코드 파일 설정을 확인하거나 FPC 소스 코드 디렉터리를 새로고침 해야 한다.

Window 메뉴

Window 메뉴는 현재 열린 창을 모두 열거한다. 이 메뉴를 이용하면 창을 가장 편하게 전환할 수 있는데, IDE 창이 열거될 뿐만 아니라 현재 프로젝트에 부속된 창들도 모두 표시되기 때문이다. 프로젝트 창은 리스트 마지막에 표시된다. 프로젝트 창은 창의 Caption 프로퍼티에 설정된 이름으로 식별된다 (예: Form1 등등). 라자루스를 새로 시작하면 Window 메뉴에는 보통 다음 엔트리가 포함된다: Source Editor, Object Inspector, Messages, Form1. 사용자는 Project Inspector, Code Browser Components, 추가 폼, 다른 창과 같은 엔트리를 빠르게 추가할 수 있어 Window 메뉴가 꽤 길어진다. 열거된 창 중 하나라도 클릭하면 그 창에 포커스가 맞춰 맨 앞으로 가져온다. 라자루스 메뉴가 메인 창에 위치하는데 메뉴를 보려면 메인 창이 이미 앞에 위치해야 하므로, 여기서 메인 창 자체는 표시되지 않는다.

일부 위젯 셋의 경우 에디터에 열린 각 파스칼 코드 유닛이 열거된다 (폼과 함께).

Help 메뉴

Help 메뉴는 세 개의 항목을 포함한다. 최근 라자루스 개발 팀에서는 새로운 기능을 도입하고 버그를 근절하는 데 중점을 두어왔다. 따라서 현재 Help 옵션들은 라자루스만큼 정교한 종합 개발 툴에서 기대하는 높은 수준을 충족하지 못하고 있다. 1.0 이전 버전들의 개선사항 리스트에서 Help 는 거의 최상위에 위치한다.

그림 3.89: Help 메뉴얼

Online help는 웹페이지를 여는데, 이곳에는 라자루스와 프리 파스칼에 관해 전체적인 정보가 담긴 페이지의 인터넷 링크들이 포함되어 있다.

라자루스는 개방 소스 프로젝트로서 그 사용자들의 기여로 인해 존재한다. 여기서 말하는 기여란 사용자가 찾은 버그를 보고하는 것을 예로 들 수 있겠다. Reporting a bug 메뉴 옵션을 클릭하면 라자루스 위키 페이지가 표시된다. (http://wiki.lazarus.freepascal/org/How_do_I_create_a_bug_report).

이는 라자루스 개발자들에게 사용자가 찾은 버그를 어떻게 알릴 것인지를 설명한다. 물론 인터넷 연결이 되어 있을 때에만 적용된다. 프로젝트 언어는 영어로 되어 있으므로 위키 페이지도 영어로 되어 있지만 다른 언어들도 이용 가능하며, 일부 페이지는 적어도 아프리칸스어, 아랍어, 말레이시아어(Bahasa), 중국어 (간체와 번체), 체코어, 네덜란드어, 핀란드어, 프랑스어, 독일어, 헝가리어, 이탈리아어, 일본어, 한국어, 페르시아어, 폴란드어, 포르투갈어, 로마니아어, 러시아어, 슬로바키아어, 스페인어, 스웨덴어, 우크라이나어, 베트남어로 제공된다.

About Lazarus 는 버전 번호와 기여자 리스트를 포함해 라자루스에 관한 일반적인 정보를 포함한다. 버전 번호와 운영체제에 관한 상세한 정보는 버그 보고를 쉽게 배정할 수 있도록 한다.

사용자는 버전 정보 영역에서 오른쪽 마우스를 클릭하여 해당 정보를 클립보드에 복사한 후 버그를 보고 시 붙여넣기 할 수 있다.