Windows Mobile 开发历险

        windows mobile编程,无论使用eVC还是.net CF,都脱不开windows消息机制这个框架。在日常的程序编写过程中，windows消息也是很常用的，windows消息常用的api函数也是常用。        这里我们不介绍windows api函数，而是介绍一下windows消息在c#使用中的十六进制表述。我给出了其中大部分消息的对照表。但是一些特有消息api函数的

<br />       Optidiy的任务管理器已经开发完毕了。在写“切换”功能的时候遇到了一些小麻烦。<br /><br />       起初，我的思路是利用WM_SYSCOMMAND的SC_RESTORE功能，但是并未达到预期效果，通过MSDN才知道Windows Mobile 对于WM_SYSCOMMAND的支持有限，并不支持SC_RESTORE。<br />       后来，采用ShowWindow这个API函数，思路是：隐藏Optidiy程序而后显示被切换程序，主要利用SW_HIDE来隐藏

using System;using System.Linq;using System.Collections.Generic;using System.Text;using System.Runtime.InteropServices;using System.Windows.Forms;namespace Optidiy.OptiApplication{    class OptiCPUClockSpeed    {        [DllImport("coredll.dll")]        pr

      众所周知，.NET Compact Framework 已经进入3.5时代，不过记得在2.0时代我写过一个利用回调方式EnumWindows的类。而且之前在写DeviceAnywhere的时候，实现过一个释放系统内存的功能。为什么要实现这个释放系统内存的功能呢？因为当初DeviceAnywhere的Phone端是常驻系统内存的，而且在系统内存过度消耗的情况下，会严重影响DeviceAnywherePhone的正常运行。      当初，为了实现这个释放系统内存的功能在Microsoft的线上MS

<br />       众所周知，某些程序需要我们获取其运行路径，并且在程序中使用该路径。在win32系统下，C#语言获取程序运行路径有很多种方法，比如：Application、AppDomain等等，相对来讲非常简单。而在windows mobile系统下，换言之，在.net cf下microsoft并未提供如此方便的方法，所以，在使用C#获取windows mobile系统下程序的运行路径就一波三折了。<br />     方法如下：<br />        //获取程序运行路径，最后不包含"/"<

<br />      目前，Optidiy的外壳程序已经初具规模，能够感知几乎所有复选框类的选择性优化项目。而且Optidiy的logo也已经设计完毕，下面是optidiy的截图，以及核心配置文件optidiy.xml。<br /><br /><?xml version="1.0" encoding="UTF-8"?><br /><Optimize><br />  <Item name="系统" description="Window Mobile 系统优化" version="6.x"><br />  

<br />      之前的监控系统已经在Demo迭代的基础上完成前期的开发工作，所以我的业余时间不必再用来研究GWT了。促使我开发OPtidiy的有两个原因，一个便是nokia e71手机被我再三摧残之下终于over了，在送修的时候又用起了曾经的美好回忆——dopod838；另一个则是，在使用838的时候又翻出了曾经自己写过的几个小软件，于是便在bing上随便查了一下WMAssistant，结果出乎我的意料之外，WMAssistant的生命力还是挺顽强的。所以，我很久之前的一个软件创意又浮现在脑海里——

      在Windows mobile中系统配置服务文件CSP能够实现一些比较"热门"的功能，比如：枚举WIFI热点、建立WIFI连接、建立GPRS连接等等。在windows mobile系统的控制面板中有个粗陋的"删除程序"功能，我们也可以通过CSP实现程序的删除卸载，实现一个属于自己的windows mobile程序卸载器，并且可以根据自己的需要扩展这个程序卸载器的功能。      在实现自己的windows mobile程序卸载器之前，首先，我们要明确程序卸载的实现要点，并且怎样用CSP来实现这些

<br />      经过一段时间的开发，Optidiy已经颇具雏形了，不过离大成总还有段距离。现在只是业余时间在做，开发的时候笔记本不接电源，只把亮度调到最低，大概能坚持2-3个小时吧。每当电耗完的时候，也就是我结束开发的时候。不过其间还伴随着给我家宝宝洗澡等更加有意义的活动，哈哈。<br />      下面便是几张Optidiy的截图，不过是在模拟器上运行的，还有Optidiy.xml现在的模样。<br /><?xml version="1.0" encoding="UTF-8"?><Optim

应哥们要求写了个关闭屏幕的小程序，vs.net 2005基于c++实现， 文件大小执行效率都还可以。不过当时写的匆忙很糙的，图标就用默认那个巨难看的！昨天哥们说让我加个图标，我说我用c#重写吧，图标加着方便，于是用C#重写，虽然文件大小只有8K较c++的32K要小很多，但是执行效率非常低下！分析个中原因，大概是因为c++和c#.net程序的执行方式不同造成的吧，c++是传统的执行方式，而.net则

这里我不是介绍Socket，而是介绍当手机同计算机连接后，如何建立本地Socket连接，而不是建立GPRS或者WAP方式的广域网Socket连接（关于如果建立GPRS或者WAP Socket连接我以后再介绍）。进行本地Socket连接的时候，选用什么样的Socket的模型（异步、同步），我也不做介绍。但是，我要告诉大家SmartPhone和PC分别作为Socket Server时候，绑定的本地

上篇中，我介绍了如何进行本地Socket通信，那只是粗略的介绍了一下Smartphone和PC端IP的获取。我个人认为Smartphone/PC这种虚拟网卡连接结构，实现本地的通讯，UDP是个不错的选择 。UDP是面向无连接的，对于SmartPhone来说所占的资源开销会少得多，而且要比TCP稳定的多。当然这需要我们自己在通讯协议上进行控制，不过SmartPhone/PC这种结构，网络环境相对比较

using System.Collections; using System.IO;         public static string[] GetStorageCardPath()         {             ArrayList tmpSDPath = new ArrayList();             System.IO.FileAttributes fa = Fi

.net CF 1.x 是不支持CallBack(回调)的，所以我们无法用EnumWindows 这个API函数来枚举系统当前所有运行程序的窗口，这里我们可以通过其它的API函数来实现EnumWindows 的功能。（.net CF 2.0中就已经支持CallBack了，无奈.net CF2 还不够普及，这对用.net CF进行windows mobile开发的人来说限制是致命的，我们不得不费很多

我最近在学习windows mobile开发，EVC确实不想学了，所以选择了微软的.net CF(.net框架精简版)。起初用vs2003，后来听说vs2005不错，遂BT了n个晚上才算搞定，装完后感觉还不错！忙不迭的新建了个SmartPhone项目，编译，晕，不能通过。提示让我安装.net framework1.1，我暗骂了微软一百遍，这么先进的vs2005竟然还需要低版本的东西，您vs2005

.NET Compact Framework 1.x中实现屏幕抓取有些难度，其实还是.net cf 1.x的支持库不够强大，微软在.net cf2.0中已经弥补了此处的不足。但是为什么还非要实现.net cf1.x的屏幕抓取呢？因为目前使用windows mobile 2003的用户还是大多数，即使目前刷了windows moblie 5的玩家，其系统也并未集成.net cf2.0。这就需要自己安

<br />最近对Optidiy for PPC进行了重写，包括：<br />1、UI重新设计<br />2、核心代码重构<br />3、外围代码整合<br />4、等等<br /> <br />截图：<br /> <br />