프레임을 쓰실때 생각할 것 세가지 1. frame_name.location = 'url.php'; 또는 frame_name.location.href = 'url.php'; 또는 frame_name.location.replace('url.php') 2. parent.frame_name.location = 'url.php'; 3. opener.parent.frame_name.location = 'url.php';
새창을 열게해준 창의 주소를 바꾸고 새창을 끈다. <script> opener.location.href = 'url.php'; self.close(); </script>
Purpose ------- Varchar2 type과 Char type의 차이를 이해한다.
Explanation -----------
CHAR와 VARCHAR2(VARCHAR)의 차이를 간단히 설명한다면 CHAR DATATYPE은 FIXED LENGTH CAHRACTER STRING을 저장합니다. 만약 TABLE이 CHAR COLUMN을 갖고 CREATE될때 COLUMN LEGTH는 BYTES로 1에서 255까지의 DATA를 저장할 수 있읍니다. COLUMN길이가 10 으로 정의 었을때 한번 INSERT 문장을 통해 5 BYTES를 입력하였다면 나머지 5 BYTES는 SPACE 처리되어 그 DATA의 SIZE는 10 BYTE가 됩니다.
SQLPLUS의 VSIZE함수를 통해 알아보면 다음과 같습니다.
SQL> SELECT VSIZE(column_name) FROM table_name;
column_name ------------ 10 10
반면에 VARCHAR2 DATATYPE은 VARIABLE-LENGTH CHARACTER STRINGS을 저장합 니다. 만약 TABLE이 VARCHAR2 COLUMN을 갖고 CREATE될때 COLUMN LENGTH 1에서 2000 BYTES까지의 DATA를 저장할수 있습니다. COLUMN길이가 10 으로 정의되었 을때 번 INSERT 문장을 통해 5 BYTES를 입력하였다면 나머지 5 BYTES는 NULL 처리되어 그 DATA의 SIZE는 5 BYTE가 됩니다.
SQLPLUS의 VSIZE함수를 통해 알아보면 다음과 같습니다.
SQL> SELECT VSIZE(column_name) FROM table_name;
column_name ------------ 5 5
위와 같은 특징을 갖고 있기 때문에 정확히 구분하여 사용해야만 SPACE를 절약할수 있고 ERROR를 방지할수 있습니다.
만약 사용자가 COMPARISON상에서 ANSI 호환성을 요구한다면 를 DATA TYPE를 CHAR로 선언해야 합니다. 즉 나머지공간(TRAILING BLANK)이 STRING COMPARISONS에서 중요한다면 CHAR로 해야합니다. 그런 특수한 경우 제외한 나머지 경우에는 VARCAHR2로 사용하는 것이 SPACE가 절약 될 것 입니다.
이번 방학에는 마음은 임베디드 혹은 C,C++ 쪽 high lang에서도 좀 low lang으로 개발을 하고 싶었으나... 여의치않게도 또 웹 프로그램을 개발하게 되었다... ㅋ 재밌기는 하지만... 개발해놓고 나면 왠지 거저먹는다는 기분이 좀 들어서 ㅋㅋ 넷빈즈로 개발하고 웹페이지를 톰켓 webapp에 복사하면 이상하게도 변경한 페이지가 보이지 않고 webapp에 복사한 파일을 수정했다가 새로고침하면 잘나오는 현상이 있어서 알아보니 톰켓에 환경설정하는 부분이 있었다...
GDI(Graphic User Interface)는 윈도우즈의 핵심 모듈 중의 하나로 주로 출력과 관련된 기능을 담당한다. 화면, 프린터 등의 출력 하드웨어와 응용 프로그램의 중간에 위치하여 장치 독립성을 확보하며 복수 개의 프로그램이 서로의 영역내에서 방해하지 않고 자유롭게 출력하도록 조율한다. 오랫동안 별탈없이 잘 써오긴 했지만 현대의 복잡한 프로그램들의 요구를 충족시키기에는 다소 부족한 점이 많다.
① 기본적인 그래픽 출력은 가능하지만 섬세한 그래픽 표현에는 다소 역부족이다. 예를 들어 점선 펜을 만들 수는 있지만 굵기가 2이상이면 무조건 실선이 되어 버리므로 굵은 점선을 그을 수 없고 NT 이하에서는 비트맵 브러시도 8*8이상의 크기를 지원하지 않아 큰 비트맵 브러시를 쓸 수 없다.
② 그래픽 속성을 바꿀 때마다 GDI 오브젝트를 일일이 생성, 선택한 후 사용해야 하므로 무척 번거롭다. 빨간색 테두리에 파란색 면을 가지는 타원을 하나 그리려면 Ellipse를 호출하기 전에 펜, 브러시 생성 및 선택을 먼저 해야 하고 그린 후에 선택 해제, 파괴까지 해야 한다. 정작 중요한 출력문보다 준비하고 정리하는 코드가 더 많아 무척 불편하다.
③ 실수로 GDI 오브젝트를 해제하지 않을 경우 리소스 누출에 의해 시스템의 안정성을 위협하기도 한다. 비트맵같은 큰 개체를 해제하지 않으면 특히 많은 리소스를 소모하여 더 이상 그리기를 할 수 없는 상태가 되기도 하는데 이는 시스템 다운에 버금갈 정도로 치명적이다.
GDI+는 전통적인 GDI 모듈의 업그레이드 버전이며 복잡한 그래픽을 출력할 수 있고 기존 기능을 최적화한 새로운 출력 모듈이다. GDI의 계승자이므로 장치 독립성을 제공한다는 기본 목적은 동일하며 GDI로 할 수 있는 대부분의 작업을 GDI+로도 할 수 있다. 윈도우즈 XP와 2003에 기본적으로 탑재되어 있으며 닷넷 플랫폼에도 포함되어 있고 64비트 윈도우즈에서도 계속 지원되므로 향후 GDI를 완전히 대체하게 될 것이다. 2000을 포함하여 2000이하의 버전에서는 별도의 모듈을 배포해야만 사용할 수 있지만 GdiPlus.dll 파일 하나만 복사하면 되므로 하위 호환성의 문제도 거의 없는 셈이다.
95/98 이후의 NT/2000에서 GDI도 투명 비트맵 출력, 좌표 변환, 반투명 출력 등 많은 기능 개선이 이루어졌지만 이런 기능은 사실 있어도 마음대로 사용할 수 없었다. 왜냐하면 추가된 함수를 하나라도 사용하게 되면 95/98에서 이 프로그램은 제대로 실행되지 않기 때문이다. 이렇게 만든 프로그램을 95/98 사용자가 쓸 수 있는 유일한 방법은 운영체제를 업그레이드하는 것 뿐이므로 시장을 포기하지 않는 한 이런 함수를 함부로 쓰지 못한다.
그러나 GDI+는 DLL을 같이 복사하면 하위 버전의 운영체제에서도 문제없이 잘 실행되므로 호환성을 걱정할 필요가 없다. 95/98 환경이라도 DLL 파일을 같이 배포하기만 하면 되므로 용량이 약간 늘어난다는 것 외에는 별다른 번거로움이 없는 것이다. DLL의 버전 충돌을 피하기 위해서 DLL을 재배포할 때는 가급적이면 시스템 디렉토리보다 응용 프로그램이 설치되는 디렉토리에 같이 복사하는 것이 안전하며 마이크로소프는 이런 배포 방식을 권장하고 있다.
GDI+를 사용하려면 먼저 플랫폼 SDK를 설치해야 한다. 이 SDK를 다운로드받아 설치하면 GDI+의 헤더 파일과 임포트 라이브러리 등은 물론이고 도움말까지 같이 설치된다. 설치 후 컴파일러의 디렉토리 옵션창에서 Include 경로와 Library 경로에 플랫폼 SDK의 경로를 추가하되 최신 SDK 정보를 가장 먼저 참조하도록 목록의 제일 위쪽으로 이동시켜야 한다.
GDI+는 DirectX의 기능 일부를 사용하므로 컴파일러가 최신 정보를 참조할 수 있도록 반드시 목록의 제일 위쪽에 두어야 한다. 그렇지 않으면 제대로 컴파일되지 않는다. 플랫폼 SDK만 설치하면 이후부터 비주얼 C++ 6.0에서도 GDI+를 프로그래밍할 수 있다. 이외에 릴리즈 후에 발견된 JPEG 출력 모듈의 보안 취약점 해결을 위한 패치 등을 다운로드 받아 설치하는 것이 좋다.
GDI+와 함께 설치되는 플랫폼 SDK 도움말에는 GDI+의 거의 모든 것들이 완벽하게 기록되어 있다. 친절한 자습서는 물론이고 컴파일해 볼만한 예제와 각 클래스의 멤버에 대한 정보, 함수에 대한 도움말, 고급 기법에 대한 문서 등이 수록되어 있으므로 이 도움말만 순서대로 읽어 봐도 GDI+는 쉽게 정복할 수 있다. 물론 영어로 되어 있다.
GDI+는 최신 라이브러리인만큼 객체 지향적인 C++언어로 작성되어 있다. 그래서 C컴파일러에서는 이 라이브러리를 사용할 수 없다는 문제점이 있기는 하지만 요즘의 컴파일러들은 대부분 C++언어를 잘 지원하므로 개발툴의 제약도 거의 없는 셈이다. GDI+는 GDI의 기능을 개선한 클래스 라이브러리이므로 일단 GDI에 대해서 잘 알고 있어야 하며 C++ 언어의 기본적인 사용 방법에 대해서도 충분히 숙지하고 있어야 한다.
GDI+는 기초적인 C++문법만을 요구하므로 C++에 대한 해박한 지식을 요구하는 정도는 아니다. 상속이나 가상 함수, 템플리트 같은 고급 기법까지는 모르더라도 객체안에 속성과 함수가 캡슐화되어 있다는 것과 객체가 생성 파괴될 때 자동으로 호출되는 함수가 있다는 것 정도만 알아도 GDI+를 배우고 사용할 수 있다. GDI+를 공부해 보면 왜 C++이 좋은가를 실감할 수 있을 것이다.
리눅스의 그래픽 시스템의 구조는 현재 크게 3가지로 나뉘고 있다. 전통적인 X 윈도우 구조, Framebuffer Device를 이용한 구조, DirectFB를 이용한 구조가 그것이다.
2. X 윈도우 구조
X 윈도우는 서버/클라이언트 모델을 가지고 있다. 응용 프로그램의 각종 그래픽 요청(각종 그리기 연산, 이벤트 전달 등등)을 X 서버에 전달하면 X 서버는 요청을 받아 들여서 그래픽 카드를 다루는 디바이스 드라이버를 이용하여 그래픽 연산 요청을 처리한다. 응용 프로그램 쪽의 그래픽 요청은 Xlib를 이용하여 이루어지게 되고 커널의 네트워크 계층을 지나서 서버에 전달되게 된다.
X 윈도우의 서버/클라이언트 모델은 응용 프로그램에 유연성을 제공하고 자원의 공유를 쉽게 할 수 있도록 하지만 각종 요청이 네트워크 계층을 지나야 하고 서버와 클라이언트에 중복된 정보를 유지해야 하는 등의 문제로 성능과 효율성 면에서는 문제점을 가지고 있다.
응용의 개발은 Xlib를 직접 사용하여 개발 될 수 있지만 대게는 GTK/QT와 같은 보다 상위의 그래픽 위젯을 제공하는 라이브러리를 이용하여 개발된다.
3. Framebuffer 구조
Framebuffer는 두 가지 의미로 사용되고 있다. 원래는 그래픽 카드의 비디오 메모리 중에서 실제 한 화면을 표시할 정보를 담고 있는 메모리 공간을 나타내는 말이었지만 커널에서 확보되는 비디오 메모리 내의 Framebuffer로 전달될 메모리 공간도 Framebuffer라고 말한다.
리눅스 Framebuffer Device는 커널 2.4.x 부터 Experimental로 포함된 그래픽 디바이스를 다루는 공통 API이다. 다시 말하면 여러 가지 그래픽 카드를 동일하게 다루기 위해서 정의된 인터페이스이다.
각 그래픽 카드를 Framebuffer Device를 통해서 활용하기 위해서는 Framebuffer device를 지원하는 디바이스 드라이버가 필요하다.
응용 프로그램에서는 Framebuffer 계층의 API를 통해서 직접 그래픽 관련 작업을 수행 할 수 있지만 X 윈도우의 경우와 마찬가지로 Framebuffer 위에 구현된 GTK나 QT등의 상위 그래픽 위젯을 포함하는 라이브러리를 활용하는 것이 보통이다.
3. DirectFB 구조
DirectFB는 Framebuffer Device 구조의 확장이라고 볼 수 있다. DirectFB를 지원하는 드바이스 드라이버를 가진 그래픽 카드의 경우에 DirectFB를 이용하여 가능한 그래픽 연산은 DirectFB를 통해서 처리하고 그렇지 않은 경우에는 기존의 Framebuffer Device를 이용하여 처리 한다.
DirectFB는 직접적으로 응용 프로그램에서 직접 그래픽 카드가 가지고 있는 가속 기능을 이용하고 Framebuffer Device 구조보다 쉽게 디바이스를 접근 할 수 있도록 윈도우 생성/관리 기능과 사운드, 키보드, 마우스 등의 입출력 장치를 다룰 수 있는 기능을 추가로 구현한 것이다. 윈도우의 DirectX의 하위 모듈인 DirectDraw를 리눅스에서 구현한 것이라고 불 수 있다.
게임 제작에서는 복사를 자주 하게됩니다. 왜냐하면, 단 1개의 표면으로 모니터에 그림을 나타내는 것이 아니라 우선 2차, 3차 표면에다가 그림이나 캐릭터를 준비해 두었다가 나중에 1차 화면으로 그림들을 보내어 우리가 눈으로 볼 수 있게 하는 방식을 쓰기 때문입니다. 따라서 이제는 표면 복사 개념을 가진 함수인 Blit와 Flip - 그리고 이와 같은 효과를 가지는 Lock 함수 - 을 공부해야 하며, 또 이 과정에서 사용되는 RECT와 DDBLTFX라는 구조체도 알아 두어야 합니다.
1. Flip에 대하여 쉬운 개념부터 먼저 정리한다. 결론적으로 Flip 함수는 오로지 2차 표면에 들어가 있는 그림 내용을 - 눈에 보이는 화면 즉, 모니터 화면으로 이해하여도 될 - 1차 표면으로 복사해 주는 함수로써 사용법은 다음과 같이 아주 간단하다.
예) lpPrimary-> Flip(NULL, DDFLIP_WAIT): 앞에는 1차 표면을 나타내는 lpPrimary 객체가 나와, 그림 자료를 - 2차 표면에서 - 1차 표면으로 복사해 준다는 말이 되는데, 첫번째 매개변수의 NULL이란 뜻은 그림 자료 '전체' 크기를 전달하겠다는 의미이다. 그런데, 매개변수 안에는 2차 표면에 대한 언급 내용을 전혀 찾아 볼 수 없다. 그 이유는 2차 표면의 크기는 1차 표면과 같기에 - 이들이 이처럼 내부적으로 연관 되어있으므로 - 2차 표면에 대한 언급이 없다.
2. Blit에 대하여 한편, 3차 표면의 그림들을 2차 표면으로 복사해 주는 함수는 Blit인데, Blit해 주는 함수 종류로는 Blt 함수와 Bltfast 함수가 있다. 이들의 복사 과정은 다소 다르며, 약간은 복잡하다고 할 수 있겠다.
◈ 참고 : Blt 함수와 Bltfast 함수는 표면 복사에 제한이 없다 Blt 함수와 Bltfast 함수는 일반적으로 3차 표면의 그림을 2차 표면으로 복사시키는데 사용된다. 그러나, 때로는 2차 표면에서 1차 표면으로 복사할 때도 사용되는 등 이들 함수는 사실상 표면 복사에 제한이 없다. 따라서 3차 표면에서 다른 3차 표면으로 그림 자료를 복사할 수도 있고, 또 3차에서 바로 1차 표면으로도, 심지어는 1차 표면에서 2차 표면으로 복사할 때도 사용된다.
이 Blt 함수와 Bltfast 함수는 3차 표면(lpThird)에 들어가 있는 그림 자료를 2차 표면(lpSecondary)으로 복사해 준다. 그러나 차이점은 - 매개변수들을 통해서도 알 수 있듯이 - Bltfast 함수는 그림 크기 조절이 되지 않는 반면, Blt 함수는 그림 크기 조절이 가능하며 또 다양한 효과도 함께 나타낼 수 있다는 점이다.
2) Bltfast 함수의 사용 예) lpSecondary-> Bltfast(100, 200, &lpThird, &Srect, DDBLTFAST_WAIT);
댓글을 달아 주세요