Windows客户端开发简介(四)

在上一篇文章里,我简单扼要的给大家介绍了一下GDI的基础知识,包括DC,HDC,GDI对象等等,总的来说都是些偏理论的知识,属于概念的范畴。

今天这篇文章里,我就要正式开始有点实际的东西了,我会教大家一些GDI的基本功能代码编写,基本的技巧,当然还有如何避免基本的坑,哈哈,对的,基本的坑而不是高级的。

那么我要如何说起呢,首先我要告诉大家如何创建DC,如何使用DC,如何设置DC的属性(也就是GDI对象),如何在DC上绘制简单的文字,绘制图形,绘制图片也就是位图。我还会附带的说说GDI+,说说CImage这个绘图超级方便的类(我在我过去的项目中大量的使用了这个类),还要说说圆角窗口的实现,包括用蒙板色的办法和用层叠窗口的办法。当然这么多的内容在这样一篇文章里肯定是写不完的,所以我将在后面的文章里逐一介绍,有兴趣的朋友可以等我一篇一篇婉婉道来。

首先来谈谈DC的使用

获取DC的方式有好几种,一般而言有如下几种

CreateDC,查阅MSDN可知其参数如下:

HDC CreateDC(LPCTSTR lpszDriver, LPCTSTR lpszDevice, LPCTSTR lpszOutput,constDEVMODE* lpInitData)

这个函数的第一个参数lpszDriver,表示你要创建DC的设备,也就是表示你想进行抽象的设备,一般而言可以是显示器或者打印机,因为用于打印的情况比较少,我们这里只讨论“DISPLAY”这个参数的情况。

当第一个参数为“DISPLAY”时,lpszDevice决定了你要在哪一个显示设备上进行绘制,如果你要在主显示设备上进行绘制,可以这样调用CreateDC

CreateDC(TEXT("DISPLAY"),NULL,NULL,NULL)

这个函数的HDC类型返回值,就代表了这个显示设备,有了这个HDC,我们就可以在屏幕上进行绘制了。

下面再说另外一种获取DC的方式GetDC

GetDC是基于窗口的,它只有一个HWND类型参数,代表了你想进行绘制的窗口,因为它的用法比较简单,我这里不做多说

说到这里,是不是觉得这两个函数还挺简单,但是在使用CreateDC和GetDC创建的DC之后,GDI的对象和资源在使用完毕后都是需要释放的,这里有个常见的坑,我在网上很多的技术博客上看到不少作者都犯了这个错误。

释放DC有两种函数

DeleteDC,ReleaseDC

那么它二者有什么区别呢?

查阅MSDN对二者的Remark可知

An application must not delete a DC whose handle was obtained bycalling the GetDC function.
Instead, it mustcall the ReleaseDC function
to free the DC.

An applicationcannot use the ReleaseDC functionto release
a DC that was created by calling the CreateDC function;
instead, it must usethe DeleteDC function. ReleaseDC mustbe
called from the same thread that called GetDC.

换句话说:CreateDC与DeleteDC配对使用,而GetDC与ReleaseDC配对使用,二者不可替换,用错了释放方法,这是初学者,甚至很多有经验的老鸟都会犯的错误。而且在最后,还需要有一点要注意的,RelaseDC必须在与GetDC相同的线程中进行调用。

看到这里,大家可能觉得真的细节还是不少的,但这些正是区分一个Windows开发老手和菜鸟的标志,所以对于我们这些Windows开发人员而言,需要注意得到地方的确很多,我们必须一丝不苟的抠每一个API的参数,含义以及坑,这大概也是一种乐趣吧。

时间: 2024-08-11 03:59:53

Windows客户端开发简介(四)的相关文章

Windows客户端开发简介(一)

在这样一个移动当道的年代,我跟大家讨论Windows客户端开发,似乎有些倚老卖老的意思了.然而我却觉得无论什么时候,Windows客户端开发其实还是有着不少实用经典的技术的.对了,确切说我是要说说Windows C++客户端开发,什么WinForm,WPF,并不在讨论范围之内,我承认用.NET ,C#做Windows客户端对开发人员来说确实是件轻松愉快的事,但是因为这些技术由于种种原因(主要还是效率问题)在经典的Windows客户端程序采用的少之又少,所以我打算把他们略过. 我并不是什么微软技术

Windows客户端开发简介(二)

一个典型的Windows客户端程序要有哪几部分构成呢?下面我会以一个国内比较流行的互联网客户端程序的基本架构来跟大家逐步展开分析,由于涉及到知识产权的问题,请大家不要问我是什么产品,当然,如果你能猜到,那我就管不着了^_^. 某视频影音互联网PC客户端产品基本架构 如上只是个粗略的分层架构图,没有更细致的划分,但是有几个地方是需要特别关注的,比如最上层的那几个部分,音视频解码引擎,UI引擎,WebKit浏览器内核,内核通信模块,日志系统. 因为音视频解码引擎和内核通信模块只是对于视频客户端和P2

Windows客户端开发简介(三)

之前的一篇文章里,我简单概要的介绍了一下界面库的知识.既然是跟界面有关,那么必然少不了很多关于绘制的内容.对于Windows开发而言,界面绘制使用的一类API就是所谓的"GDI". GDI这个东西可有历史了,但是我们就不去追根朔源了.首先,我不能免俗的要先介绍一下它的全称:"Graphic Device Interface",即"图形设备接口",从这个名称我们可以大略吸收到的信息就是:GDI是个跟图形绘制有关的接口,对的,正是这样! 先让我们来看

windows客户端开发调试工具

本文介绍windows常用开发与调试工具. 1.windows常用开发与调试工具 1.1 Sysinternals 内核大神打造,含大量windows系统工具,windows开发必备神器,大神被MS招安. 下载地址:http://technet.microsoft.com/en-us/sysinternals Procmon.exe 监视程序运行过程中的动作,可用于性能监控. procexp.exe 相当于升级版的任务管理器,可以查看加载模块,模块查找,线程列表(含CPU百分比), 创建dump

windows客户端开发--也许是一条不归路

如今的Windows客户端开发,已经被同行嘲笑为鸡肋,甚至有些人认识做Windows客户端就是一个笑柄. 食之无味,弃之可惜. 不可否认,PC端没落的很快. 但是想说的是,任何一门技术都有存在的道理. 微软就是所有Windows客户端开发人员的大腿,虽然这个大腿让人捉摸不定,主方向总是变化. 换言之,Windows客户端开发难度不小.如果你能轻松的驾驭指针.内存.类等等,即使有一个Windows客户端彻底完蛋了,你也许只用一个星期或是一个月就掌握了另一种编程语言开发. 重要的是思想~ 我个人认为

windows客户端开发--使你的输入框具有拖拽上传的功能

今天谈一天windows客户端拖拽上传功能. 其实主要是拖拽功能,上传是自己实现的. DragAcceptFiles 函数 最重要的就是这个函数了,看看作用: Registers whether a window accepts dropped files 原型: VOID DragAcceptFiles( HWND hWnd, BOOL fAccept ); 参数: hWnd Type: HWND The identifier of the window that is registering

windows客户端开发--根据可下载url另存为文件(微信windows客户端这样做的)

可以我的blog的标题会让你误解,那么好,没图说了xx: 比如微信windows客户端发送了一张图片,我们可以预览这张图片,还可以保存到本地: 那么windows程序是如何下载这张图片的呢? 是这样,别人给你发了一张图片,这张图片的原图会存在微信的服务器上,这样这个文件就对应了一个可下载的url. 如果你拿到了这个url,用浏览器访问,你就可以通过下载这个原图了. 但是,在浏览器下载是我们客户端控制不了的,下载路径也要在浏览器中设置,也不能方便的重命名. 那么这时候问题来了: 我们怎么样从一个u

windows客户端开发--客户端国际化中特殊处理(日期等)

之前介绍了windows客户端使用xml进行国际化. 我们更多的时候关注的是显示,比如中文是关闭,英文系统显示为close. 但是在国际化过程中,还有一些其他地方不要处理的.不只是简单的翻译而已,有时候需要改变规则. 时间就是一个例子. 从学习英语我们就知道,老外时间.地址等表达方式跟我们不同. 所以这篇博客就是与您探讨探讨客户端国际化过程中对日期的特殊处理. 现在的前提是,你拿到了一个时间戳,要把它进行显示. 这非常简单,使用strftime即可. 博客http://blog.csdn.net

windows客户端开发--使用tinyxml库解析xml文件

例如,微信windows客户端使用的duilib库中,界面就是用xml进行描述的. 所以,今天我们就来谈一谈windows客户端中,也就是C++中如何解析xml. 很多时候,我们都使用.ini文件来存储一些数据. xml确实是有很多的优点,某种程度上来说也确实可以完全取代ini,但也并非如有些人鼓吹的处处都比ini强. xml,对于描述复杂的数据结构非常的方便,缺点相对ini使用麻烦一点.在表达较短的配置时,没有ini简练.而且因为它有比较严格的格式审查机制,容错性也不是特别好,在手写时容易出现