프레임은 아마도 델5부터 지원한거 같은데... 이것이 없을 때는 컴포지트라고 해서 컴포넌트를 그룹으로 묶는 별도 컴포넌트를 쓰기도 했는데...
예를들어보죠... 윈도우즈커맨더 아시죠? 같은 모양의 창이 두 개 있습니다. 메인 폼에 이 두개의 리스트박스를 놓는게 아니라, 별도의 프레임을 생성하고 그 프레임 안에 폴더정보, 파일목록 등등을 포함시킵니다. 그리고 마우스의 클릭이나 키보드, 콤보박스, 헤더컬럼 등의 각종 이벤트에 대한 핸들러를 작성합니다.
메인폼에서는 앞에서 만든 두 개의 프레임을 포함시키고, 공통적인 처리(현재 선택된 프레임, 현재 폴더, 드랙&드랍, 카피...)만 해주면 됩니다. 이것은 메인 유닛에 코드가 집중되는 것은 물론 코드를 반복하는 것까지 막아주죠...
이렇게 같은 모양이 반복되는 경우가 아니더라도 프레임은 매력적인 기능입니다.
그밖에 데이터모듈을 쓸 수도 있습니다. DM에 DelZIp이나 각종 컴포넌트를 놓고 그것을 제어하는 메소드를 만들어서 외부로 공개하고, 나머지 이벤트나 잡다한 보조함수는 내부에서만 쓰게 만들어도 많이 줄어들 겁니다.
폼에 관련된 메소드, 이벤트를 다른 유닛에 분리시키는 건 별로 바람직하지 않습니다. 관리도 그렇고... 강제로 나누고 메인유닛에서 불러다 쓸 수는 있겠지만... 아무튼 프레임(TFrame)이 가장 좋은 해결책으로 보입니다. 응용도 위에 말씀드린거 외에 상속 같은 형태도 가능하므로 도움말 한번 참고해 보십시오.
델4까지는 CCPack 같은걸 쓰면 거의 비슷한 효과를 볼 수 있습니다. 그런데 이건 가끔 AV를 많이 일으켜서...
윈도우 프로그램을 짤 때 대부분의 component가 모여있는 Main Form이 구현된 Unit에 다른 대부분의 코드가 집중되는 경향이 있는것 같던데요 예를들어 클래스는 Unit1.pas에서 선언을 하고 실제 구현은 Unit1.pas, Unit2.pas에 나눠서 하...
밥팅민수
•
2002.09.16 13:09
프레임은 아마도 델5부터 지원한거 같은데... 이것이 없을 때는 컴포지트라고 해서 컴포넌트를 그룹으로 ...
우소
•
2002.09.15 23:45
그냥 간단하게는
unit2에 함구로 구현하구요.
unit1에서 unit2를 참조하면 되지요.
즉 uses 에 unit2...
프레임은 아마도 델5부터 지원한거 같은데... 이것이 없을 때는 컴포지트라고 해서 컴포넌트를 그룹으로 묶는 별도 컴포넌트를 쓰기도 했는데...
예를들어보죠... 윈도우즈커맨더 아시죠? 같은 모양의 창이 두 개 있습니다. 메인 폼에 이 두개의 리스트박스를 놓는게 아니라, 별도의 프레임을 생성하고 그 프레임 안에 폴더정보, 파일목록 등등을 포함시킵니다. 그리고 마우스의 클릭이나 키보드, 콤보박스, 헤더컬럼 등의 각종 이벤트에 대한 핸들러를 작성합니다.
메인폼에서는 앞에서 만든 두 개의 프레임을 포함시키고, 공통적인 처리(현재 선택된 프레임, 현재 폴더, 드랙&드랍, 카피...)만 해주면 됩니다. 이것은 메인 유닛에 코드가 집중되는 것은 물론 코드를 반복하는 것까지 막아주죠...
이렇게 같은 모양이 반복되는 경우가 아니더라도 프레임은 매력적인 기능입니다.
그밖에 데이터모듈을 쓸 수도 있습니다. DM에 DelZIp이나 각종 컴포넌트를 놓고 그것을 제어하는 메소드를 만들어서 외부로 공개하고, 나머지 이벤트나 잡다한 보조함수는 내부에서만 쓰게 만들어도 많이 줄어들 겁니다.
폼에 관련된 메소드, 이벤트를 다른 유닛에 분리시키는 건 별로 바람직하지 않습니다. 관리도 그렇고... 강제로 나누고 메인유닛에서 불러다 쓸 수는 있겠지만... 아무튼 프레임(TFrame)이 가장 좋은 해결책으로 보입니다. 응용도 위에 말씀드린거 외에 상속 같은 형태도 가능하므로 도움말 한번 참고해 보십시오.
델4까지는 CCPack 같은걸 쓰면 거의 비슷한 효과를 볼 수 있습니다. 그런데 이건 가끔 AV를 많이 일으켜서...