Jump to content
과거의 기술자료(읽기 전용): https://tech.devgear.co.kr ×
과거의 기술자료(읽기 전용): https://tech.devgear.co.kr

이 사이트 검색

검색 태그: '윈도우 10'.

  • 태그로 검색

    태그 사이를 쉼표(,)로 구분하세요.
  • 작성자로 검색

콘텐츠 유형


게시판

  • 엠바카데로 (Embarcadero) 개발도구: 델파이 (Delphi), C++빌더 (C++Builder), RAD 스튜디오 (RAD Studio)
    • [기술 Q&A 게시판] 델파이, C++빌더, RAD 스튜디오
    • [설치/등록 Q&A 게시판] 델파이, C++빌더, RAD 스튜디오
    • [기술 기고 게시판] 델파이, C++빌더, RAD 스튜디오
    • [포트폴리오 게시판] 내가 참여한 프로젝트/프로그램 소개
    • [구인 게시판] 개발자 채용/프로젝트 의뢰
  • 엠바카데로 (Embarcadero) DBMS: 인터베이스 (InterBase)
    • [기술 Q&A 게시판] 인터베이스
    • [설치/등록 Q&A 게시판] 인터베이스
    • [기술 기고 게시판] 인터베이스
  • 비주얼 스튜디오 (Visual Studio) 관련 도구
    • [기술 Q&A 게시판] 비주얼 어시스트
    • [설치/등록 Q&A 게시판] 비주얼 어시스트
    • [기술 기고 게시판] 비주얼 어시스트
  • 구록 (Gurock) 테스트도구: 테스트레일 (TestRail)
    • [기술 Q&A 게시판] 테스트레일
    • [설치/등록 Q&A 게시판] 테스트레일
    • [기술 기고 게시판] 테스트레일
  • 아이데라 (Idera) 데이터 도구: 아쿠아 데이터 스튜디오 (Aqua Data Studio), ER/Studio 등
    • ER스튜디오 (ER/Studio)
    • 아쿠아 데이터 스튜디오 (Aqua Data Studio)
  • API레이어 (Apilayer) 개발 도구: API레이어 (Apilayer)
    • [Q&A 게시판] API레이어 (Apilayer)
  • 엠바카데로 (Embarcadero) 라이선스 서버: ELC (Enterprise License Center)
    • [게시판] ELC (Enterprise License Center) 라이선스 서버
  • 이 사이트 이용 관련
    • [게시판] 이 사이트 관련 이용 팁과 Q&A

Categories

  • 이달의 기술자료: 엠바카데로
  • 비디오 세미나
    • UX Summit
    • DelphiCon
    • CodeRage
    • 데브기어 세미나
    • Skill Sprint
  • 기술백서(PDF)

Categories

  • 시작하기
  • 설치/등록/라이선스
  • 튜토리얼
  • 도서

Categories

  • RAD 스튜디오 역사관
  • 11 알렉산드리아
  • 10.4 시드니
  • 10.3 리오
  • 10.2 도쿄
  • 10.1 베를린
  • 10.0 시애틀
  • XE8~XE
  • 2010~6.0

...에서 결과 찾기

검색어 일치 조건


최초 작성일

  • Start

    End


최종 변경일

  • Start

    End


개수로 필터링...

가입

  • Start

    End


Group


자주 쓰는 도구

  1. 마르코 칸투 (Marco Cantu)의 VCL Support for Per Monitor v2 and GetSystemMetrics Coming in 10.3 를 번역했습니다. (원문 작성 시기: 2018년 11월) RAD 스튜디오 10.3 버전부터, 마이크로소프트 윈도우 10에서 최근에 추가된 Per Monitor v2 (모니터 개별 V2) 모드 지원이 반영되었다. (VCL 애플리케이션도 일종의 윈도우 애플리케이션인데) 해상도가 다른 모니터 여러개를 윈도우 지원하기는 상당히 복잡하다. 지금까지는 GetSystemMetrics 와 같은 윈도우 API를 통해서 플랫폼 요소의 크기를 요청하면 주 모니터의 정보만 받을 수 있었다는 점 등 여러가지 이슈로 인해서 꽤 어려웠다. 예를 들어, 애플리케이션 안에 있는 스크롤 바의 크기를 해상도가 다른 보조 모니터에서 문제없이 표현하는 것 조차 쉽지 않았다. 마이크로소프트 윈도우 10 업데이트에서 새 API가 도입됨에 따라 이 작업은 이제 간편해졌다. 일명 윈도우 10 크리에이터 업데이트 (빌드 1703)부터 GetSystemMetricsForDPI가 새로 추가되었기 때문이다. 이 새 윈도우 API를 보다 폭넓게 활용할 수 있도록 우리는 VCL 라이브러리에 반영하기로 했는데 이 새 API를 호출하기만 해서는 쓸만하지 않았다. 그 이유는 윈도우 7 등 해당 윈도우 10 업데이트 이전의 버전과 호환성이 깨지기 때문이었다. 따라서 이 문제를 해결하기 위해 우리는 부가적인 작업을 해야만 했다. 첫째, 우리는 VCL.Classes 유닛에 GetSystemMetricsForWindow라는 새 전역 함수를 하나 추가했다. 이 함수는 해당 윈도우 API를 랩핑하고 있는데, 만약 윈도우가 최근 버전이라서 GetSystemMetricsForDPI를 사용 할 수 있으면 이것을 사용하고, 그렇지 않으면 윈도우의 전통적인 GetSystemMetrics를 사용한다. 이 함수에는 파라미터가 하나 추가되었는데 여기에는 해당 윈도우 API에 전달할 관심있는 창을 가리키는 (그리고 그 창이 표현되고 있는 모니터들에 대한 정보를 간접적으로 전달할 수 있는) 윈도우 핸들이 들어간다. 둘째, 기존의 VCL 코드 (VCL 라이브러리 내부에 구현된 코드, 델파이 사용자가 만든 커스텀 컴포넌트와 애플리케이션의 코드 )를 업데이트 하는 작업이 간편하도록, 우리는 TControl에 GetSystemMetrics라는 메소드를 새로 추가했다. 이 메소드는 GetSystemMetrics 윈도우 API 와 이름이 같고 파라미터 호환성도 지켜진다. 따라서 기존에 컴포넌트에서 사용된 해당 API 호출이 새 메소드로 재전달 될 수 있다. 즉, 컨트롤을 담고 있는 부모 창의 핸들을 파라미터에 담아서 GetSystemMetricsForWindow를 호출하게 된다. 이 방식 덕분에, 이와 관련된 코드 대부분은 전혀 수고하지 않아도 자동으로 “전환”된다. 마지막으로, 우리는 TControl에 새 읽기 전용 속성인 CurrentPPI를 추가했다. 이 속성은 해당 콘트롤이 표현되고 있는 모니터의 DPI를 반환한다. 예제로, 버튼의 OnClick 이벤트에 아래의 코드가 있는 간단한 VCL 애플리케이션을 하나 만들었다. procedure TfrmSystemMetrics.btnRefresh (Sender: Object); begin Lable2.Caption := ‘Current: ‘+ GetSystemMetrics (SM_CXVSCROLL).ToString; end; 위 코드는 델파이 초기 버전부터 해당 윈도우 API 함수를 불렀다. 이제는 이 GetSystemMetrics 호출이 해당 폼의 핸들을 전달할 수도록 보강되었다. 따라서 새 윈도우 API 함수를 호출하고, 해당 모니터 별로 고유한 결과를 받을 수 있다. 이 샘플 애플리케이션에서는 폼의 OnCreate 이벤트에서도 같을 호출을 하는데 그 결과 폼이 생성될 시점에 사용된 고해상도 주 모니터의 값 (34 픽셀)이 찍힌다. 그리고 나서 이 폼을 해상도가 더 낮은 (스크롤 바가 17 픽셀을 차지하는) 보조 모니터로 옮긴 후에 버튼을 클릭하면, 같은 호출이지만 결과가 다르다 (아래 결과 화면을 보자). 그림. 동일한 GetSystemMetrics를 호출하지만, 결과는 34와 17로 모니터의 DPI에 따라 다르다. 지금까지 설명한 핵심 구현과 별개로, 윈도우의 이러한 새 모델을 수용하기 위해, 우리는 VCL과 VCL 스타일을 상당히 업데이트했다. 그리고 마이크로소프트에서 새로 지원하는 DPI 모델을 수용할 수 있도록 컴포넌트 제작자들 역시 우리와 같은 작업을 진행 하기를 권한다. 우리는 대부분의 경우 코드를 그대로 두면 되었다. 하지만, 일부 메트릭스는 모니터 독립적이어서 변함없이 주 모니터에만 의존한다. 그런 경우에는 개발자가 Windows 유닛을 이용하여 해당 호출을 수정하는 방식 즉 Windows.GetSystemMetrics (SM_xxx)를 사용하여 해당 윈도우 API를 호출하도록 강제해야 한다. 만약 데이터 모듈이나 전역함수 등 TControl을 상속하지 않은 곳에서 이런 호출을 하고 있다면 코드 구조를 다시 고려해볼 필요가 있다. 끝으로, 델파이 애플리케이션의 경우 IDE에 프로젝트 옵션이 추가되었으므로, 매니페스트(manifest)에서 이 기능을 활성화할 수 있다. 그리고 이 Per Monitor v2 옵션은 새 VCL 프로젝트에서는 기본으로 지정된다. 마지막으로 알아두어야 할 한가지 제약 사항이 있다. Per Monitor V2 (와 윈도우의 기타 수많은 High DPI 지원)은 MDI 자식 창 모델을 전혀 지원하지 않는다. 마이크로소프트는 이미 MDI와 관련된 버그 리포트에 대해 전혀 대응하지 않고 있다. 따라서 MDI가 아닌 다른 다중-창 모델 (다중 유동형 창, 도킹 판넬, 탭으로 구성된 창, 등등)으로 전환할 것을 추천한다.
  2. 짐 맥키트(Jim McKeeth)가 작성한 High-DPI on Windows 10을 번역했습니다. 모니터와 관련하여 우리는 종종 해상도(예: 1920x1080)와 대각선 길이(예: 27" 또는 68.58cm)를 이야기한다. 이 정보와 피타고라스 정리를 활용하면, DPI를 파악할 수 있다. 아래의 DPI와 PPI에 대한 설명을 참고). 해상도를 높이지 않는다면, 화면이 커질수록 DPI는 낮아진다. DPI = (sqrt (sqr (폭) + sqr (높이)) / 대각선 처음에 윈도우는 모든 모니터의 DPI를 96로 간주했었다 (실제로는 72 PPI를 사용한다). 윈도우 XP에서는 GDI+가 추가되어서 해상도에 의지하지 않고도 텍스트를 확대/축소할 수 있게 되었다. 윈도우 비스타(Vista)에서는 High DPI 디스플레이 지원이 추가됨에 따라 더 많은 픽셀을 사용할 수 있게 되어서 텍스트는 더 선명하게 이미지는 더 자세하게 표현할 수 있어 졌다. 하지만, 앱이 High DPI를 지원한다고 알려주지 않는 경우에 윈도우는 앱을 여전히 96DPI로 취급했다. 윈도우 7에서는 모니터의 실제 픽셀 밀도을 파악하여 값을 얻을 수 있게 되었다. 윈도우 10에서는 모니터 별로 독립적으로 DPI에 맞게 확대/축소할 수 있게 되었다. (96 DPI 이상인) High DPI 모니터를 사용하는 경우, 윈도우에서 화면 배율을 지정하면, 확대된 화면에서 내용이 너무 작고 읽기 힘들어 지는 것이 아니라, 더 선명한 폰트와 더 자세한 이미지를 볼 수 있다. 그림. 윈도우 10 화면 설정에서 화면 배율 지정 윈도우 10의 이 변화가 개발자에게 의미하는 바는, 10.3 리오부터 윈도우 VCL로 High DPI 애플리케이션 개발할 수 있게 되었다는 점이다. High DPI 이미지 리스트 지원 Per Moniter V2 지원 새로운 스타일들 윈도우 API들 업데이트 마르코 칸투는 Per Monitor v2 지원에 대한 글을 통해서 개발자가 윈도우 10의 새 기능을 활용하여 모니터 별로 해당 DPI를 파악할 수 있는 앱을 개발할 수 있게 되었다는 점을 설명했다. 이 DPI Awareness 옵션은 Project > Optios > Application > Manifest에 있다. 새 VCL 프로젝트를 만들면 디펄트 설정인 Per Monitor v2가 반영된다. 기존의 프로젝트에서 High DPI를 지원하려면 이 옵션을 직접 Per Monitor v2로 바꾸면 된다. 그림. RAD 스튜디오 프로젝트 옵션 설정에서 DPI Awareness 지정 VCL프로젝트에서 Per Monitor v2 옵션을 지정하여 빌드한 VCL 앱은 자동으로 화면에 맞추어 크기를 변경한다. 하지만, 관련하여 VCL.Classes 유닛에 GetSystemMetricForWindow 함수가 새로 추가되었다. 이 함수는 윈도우의 새 API인 GetSystemMetricsForDPI를 활용한다 (참고로, 이 새 윈도우 API는 안에서 이전의 GetSystemMetrics를 활용한다). GetSystemMetricForWindow 함수를 이용하면 개발자는 앱이 표현되고 있는 현재의 모니터에서 파악된 내용을 기반으로, 앱의 각 창 별로 해당 매트릭, 해상도, DPI를 얻을 수 있다. TControl (과 그 하위 컨트롤)에는 GetSystemMetrics 메소드가 제공된다. 이 메소드를 호출하면 업데이트된 정보가 자동으로 제공되므로 기존 코드를 쉽게 마이그레이션 할 수 있다. TControl에는 이 메소드 이외에도 CurrentPPI 속성이 있다. 그림. TControl (과 그 하위 컨트롤)은 화면의 DPI에 맞추어 이미지를 선명하게 표현할 수 있다. 새 VCL High DPI 이미지 리스트는 마술같은 멋진 컴포넌트로써 TImageCollection과 TVirtualImageList로 구성된다. 이 컴포넌트 세트 사용에 대한 내용은 데이비드 밀링턴의 글에 잘 설명되어 있다. 이 컴포넌트 세트 덕분에 High DPI 화면에서 고해상도 그래픽를 자동으로 활용하는 앱을 정말 쉽게 만들 수 있다. 새 이미지 리스트는 윈도우의 기본 이미지 리스트 이상을 담고 있어서 여러분의 VCL 앱이 멋지게 표현될 수 있도록 한다. 그림. TImageCollection에는 이미지 별로 다양한 해상도의 이미지를 추가/편집/삭제할 수 있다 이 기능들을 (겟잇에서 제공하는) 10.3 리오에서 추가된 새 VCL 스타일과 함께 사용하자. 개발자는 VCL 앱이 윈도우 10에서 작동될 때 어떤 모니터에서도 멋진 모습이 되로록 하는데 필요한 모든 것을 다 가졌다. 10.3 리오에서는 이것 이외에도 많은 새 기능과 업데이트가 있다. DPI와 PPI에 대한 설명 DPI는 이미지를 구성하는 각 점들의 밀도를 측정한 것이다. 이 점들은 화면이나 지면에 표현될 때 사용되는 점이다. 하지만, 지금은 모니터 화면에서 이미지를 표현하는 개별 요소인 픽셀을 중심으로 이야기 해보자. 인치 당 점의 갯수인 DPI는 화면 상에서는 1인치 당 점인 픽셀의 갯수이다 (1인치가 2.54cm이므로 254DPI는 100DPCM이고, 100DPI는 39.37DPCM이지만, 지금은 DPI만 사용하기로 하자). 종이에 찍히는 잉크 점 하나와 화면에 펴현되는 픽셀 하나 사이에는 기술적인 차이점이 있다. 따라서 모니터에서는 Pixels Per Inch (PPI)가 정확한 용어이지만 DPI와 PPI가 같은 의미로 사용되는 경우가 흔하다. 대부분의 모니터에는 서브 픽셀(sub-pixel)이 있다. 서브 픽셀은 (빨강, 녹색, 청색와 아마 하얀색인) 각 개별 색상 요소이며, 모여서 하나의 색상 픽셀을 형성한다. 화면의 각 개별 색상 요소인 서브 픽셀의 밀도가 달라지게 되면, 화면의 색상 표현 역시 크게 달라진다.
×
×
  • Create New...

중요한 정보

이용약관 개인정보보호정책 이용규칙 이 사이트가 더 잘 작동하기 위해 방문자의 컴퓨터에 쿠키가 배치됩니다. 쿠키 설정 변경에서 원하는 설정을 할 수 있습니다. 변경하지 않으면 쿠키를 허용하는 것으로 이해합니다.