酷派S100手机DIY教程之二-修改主菜单
这次的教程,其实很简单,依然只需要对一个配置文件做简单的修改即可。修改后,你可以:
1. 按照自己的喜好灵活安排主界面菜单的排列;
2. 为主界面菜单换上自己中意的图标;
3. 换上自己喜欢的开关机动画。
* 准备工作
1. 手机充满电;
2. 准备好驱动程序,以及上次提到过的工具软件;
3. 图片编辑软件,要求是可以将图片保存成png格式的,例如Photoshop或者Fireworks,Windows 7的画图也可以。
这次的教程,其实很简单,依然只需要对一个配置文件做简单的修改即可。修改后,你可以:
1. 按照自己的喜好灵活安排主界面菜单的排列;
2. 为主界面菜单换上自己中意的图标;
3. 换上自己喜欢的开关机动画。
* 准备工作
1. 手机充满电;
2. 准备好驱动程序,以及上次提到过的工具软件;
3. 图片编辑软件,要求是可以将图片保存成png格式的,例如Photoshop或者Fireworks,Windows 7的画图也可以。
最近公司要求统一使用电信的天翼189号码,发了一部宇龙酷派S100手机终端。
……
这几个快捷方式一不小心就会点到,尤其是互联星空,占着第一个位置,一点就启动浏览器开始上网,关都来不及关,很是不爽。之前也看到网上有机友在抱怨这种做法,但目前好像还没有人拿出解决办法。今天刚好有空,就研究了一番,最后这个问题终于被我成功解决了。下面是破解过程的说明。
上次说到ExtJs 3.0将在4月14日左右发布,其实早在4月4日,ExtJs在其官方博客上发布了相关的消息,同时对外发布了Ext Core 3.0 Beta 版并提供下载。但是这次的发布并没有包含之前所说的可视化开发环境,只包含了源码、示例、文档及许可信息等内容,这不免令人有点失望。
我注意到原文中有这么一句:
"Ext Core is a subset of the upcoming Ext JS 3.0 release optimized for speed & file size."
即:(这次发布的)Ext Core 3.0 是即将发布的Ext JS 3.0的一个子集,Ext JS 3.0在速度和文件体积上将有所优化。
还是没有提到可视化开发环境,难道这只是传言么?看来只能等待正式版发布才能知晓了……
利用C#开发Pocket PC程序,想在程序里调用设备的震动功能,至少再wm5中还没有这样的API,上网查了不少例子,都只能再c++下调用。既然这样,那唯一的办法是运用P/Invoke了,在"coredll.dll"中有这样两个函数 C++代码 BOOL INAPI NLedGetDeviceInfo( UINT nInfoId, void *pOutput ); BOOL WINAPI NLedSetDevice( UINT nDeviceId, void *pInput ); NLedGetDeviceInfo 是获得LED数量,NLedSetDevice是来设置LED状态的,我们只有通过它来启动或者关闭Pocket PC设备的震动与否。说明一下:一般PPC设备都有两个LED,一个就是扬声器0(Radio LED),另一个则是振动器1(Vibrator)了。在我的PPC设备上发现第二个是Vibrator,不知道是不是所有的PPC都是这样子的。后来查到"On the HTC Himalaya the vibration device is implemented at index 1。"也就是HTC内核的都是1. C#代码 using System; using System.Collections.Generic; using System.Text; using System.Runtime.InteropServices; using System.Threading; namespace BluetoothChatPPC { class LED { class NLED_SETTINGS_INFO { public [...]
我目前做过的几个项目,在界面方面基本上都使用了ExtJS框架。从yui-ext,到Ext2.1,再到目前的Ext2.2,称不上精通,也算是比较熟悉了。 昨天在Ext中文资讯站看到消息说,ExtJS3.0及其IDE可视化编程环境将在近期(很可能是4月14日)发布。真是个好消息,这意味着我们将可以直接拖拉控件到界面,从而省去了很多手工写代码的麻烦,而且,用户可以制作自定义的可重用的控件,真的是无比强大! Ext JS 3.0的一些新特性: Ext JS Road Map Ext JS 3.0 (Early 2009) * All new lightweight, high-speed core base library * Flash Charting API * Ext.Direct - Remoting and data streaming/comet support * Integrated client-server data binding/marshaling of updates * ListView component * Enhanced Button and Toolbar components * ARIA/Section 508 accessibility improvements [...]
最近有个在页面上传Excel文件至服务器指定目录并进行数据校验、最后入库及进行进一步处理的应用情境,我写好代码在模拟环境下测试,完全没问题;但客户试用的时候,却老是报告“No such file or diretory ”的异常,上传不了。后来发现是文件路径的问题。我的模拟测试环境是windows+tomcat,而客户的环境是linux+tomcat,文件路径的分隔符在windows系统和linux系统中是不一样。 比如说要在temp目录下建立一个test.txt文件,在Windows下应该这么写: File file1 = new File ("C:\tmp\test.txt" ; 在Linux下则是这样的: File file2 = new File ("/tmp/test.txt" ; 如果要考虑跨平台,则最好是这么写: File myFile = new File("C:" + File.separator + "tmp" + File.separator, "test.txt" ; File类有几个类似separator的静态字段,都是与系统相关的,在编程时应尽量使用。 separatorChar public static final char separatorChar 与系统有关的默认名称分隔符。此字段被初始化为包含系统属性 file.separator 值的第一个字符。在 UNIX 系统上,此字段的值为 '/';在 Microsoft Windows 系统上,它为 '\'。 separator public [...]
# oracle中nls_characterset与nls_nchar_characterset的设置及其影响 在众多的资料中,仅是说了 nls_characterset数据库字符集 nls_nchar_characterset数据库国家字符集或者国际化设置字符集 nls_characterset与数据库中char、varchar blob类型的属性字段有密切的关系 nls_nchar_characterset与nchar、nvarchar2属性字段类型相关 偶然的一个机会,让我怀疑,虽然,还没有查到确切的文献依据,nls_characterset Oracle数据库字符集的设置,对C/S结构下的数据库访问应用有比较大的影响。在这种结构中存在一个不起眼的细节,即在C/S结构下的数据库访问中,客户端经常将要执行的SQL语句发送到数据服务器端DBMS去执行,而这个SQL语句必定是要按照一定的字符集进行编码的。发送SQL语句编码的这个字符集或者是约定或者是客户端和服务器端协商得到的。但是,不管这个字符集是如何确定的,这个对我们要说明的问题影响不是太大,我们所需假设的即这个发送到服务器端执行的SQL语句是按照某种字符集编码。 一般情况下,服务器端只要对客户端发送过来的SQL语句解码正确,我们是不会发现其有异常的。但是,在国际化数据库应用下或扩展已有的数据库应用成为国际化版本时,如果nls_nchar_characterset设置欠乏考虑,就会出现写入数据库的数据,在字节级的信息就是乱码,更况论其显示值了,那就更是错误百出了,因为根基就是错的!观察表属性的字节级信息,在oracle里是通过dump(columnName,16)观察。 例如,在某个数据库中nls_nchar_characterset的设置为GBK,为了应付国际化,数据库应用对数据库表中可能包含非GBK字符集范围的列,全部定义为nachar(注:觉得应该是nvarchar)或者其他国际化属性类型。按照通常网上资料或者简明Oracle说明书,这样的设置应该是没有问题,但是,在这里再次强调下,我们出问题的不起眼的源头,某些C/S结构下的数据库访问,客户端是通过发送SQL语句到数据库执行的方式,达到访问数据库的效果。这样架构下,就会牵扯数据库服务器端,会以何种字符集,让DBMS统一看待、处理SQL语句呢?我想,这里Oracle数据库系统,可能会简单地以ASCII字符集处理SQL关键字、分割符,而以nls_characterset设定的字符集应对SQL语句中非关键字,例如查询条件、赋值等。或者它会以更简单、明快的处理方案,将客户端不管以何种编码过来的SQL语句串都转换到nls_characterset设定的字符集,统一进入SQL后续执行的核心区。不管Oracle可能会采用这两种可能的哪一种,对于客户端发送过来的SQL语句中非SQL规范关键字范畴的部分,数据库服务器端可能都会采用nls_characterset设定的字符集在后期进行处理,这样,在后面的继续处理中就会发生问题。 关于Oracle客户端访问程序,其发送过来的SQL语句的字符集可以和Oracle数据库nls_characterset设置是不同的,而不是像有些网上文档说的两者之间要保持严格相同。实际上,Oracle可能提供了对客户端不同编码格式的数据进行解码的过程,但是,Oracle解码完成后的终点基座、最终的目标可能是Oracle自身设置的nls_characterset数据库字符集。 呵呵,在这里声明一下,我也是以概念逻辑上的推测、猜度别人,而非查到第一手的关键文献资料。但是,上面所有基于猜测,都是某次Oracle故障后,自己找出的唯一比较近乎合理的解释!我也没有强求这个文档的真金白银的价值,只希望对大家有用,提供一个可能的新视角,对其价值看做仅作参考即可。很多时候,我喜欢的编程生活是,不需要懂得太多的技术细节,只需要知道它的概念逻辑即可,即其可能的实现是什么就可以了!懂得太深,会耗去很多宝贵的时间的。而且,只要你懂得其概念逻辑和模型后,后面的全部只是时间问题,也和具体实现语言也没有太大的关系,这就是概念逻辑的优势,在没有硝烟的战场是取得胜利。在这里将这次的故障总结写入博客,也是希望有人能够指出其中纰露 :) 基于上面的所有分析,我们就可以看出来,如果客户端JDBC访问以utf-8方式将要在服务器端执行的SQL语句发送到服务器端,而其insert或者update的值域信息里面含有非nls_characterset,这个时候,请注意,字节级的乱码就出现了。因为两个字符集间utf-8<-->nls_characterset的映射关系,在事实上确实也并不是完全包含的。当然,你可以严格限定你的客户端发送到服务器端的utf-8字符编码,就是nls_characterset的一个子集,这样你也就不会出现乱码问题。但是,当你扩展你这个数据库应用,来应付更多的国际化的时间,你一定要小心了。虽然,Oracle JDBC驱动为了处理国际化的问题,已经将自己发送到服务器端的SQL语句的字符编码按照utf-8字符集进行实施,它可以是被认为近乎无限的语言处理能力,但是,你的数据库服务器端,在Oracle9i版本,未必有能力能够处理,因为它可能按照nls_characterset字符集的设定去处理客户端发送过来的SQL语句。不过,实际上Oracle可以作的更多,它可以进一步分析,如果SQL语句中含有nchar的属性列的处理,就不能以nls_characterset来处理SQL中的"值域“信息,我们程序员的控制力是还有很大空间的 。从故障的各方面分析来看,在Oracle9i版本好似还没有这样的特殊智能。 验证我这个推测的一个佐证是查看V$SQLArea视图的定义,可以看到其SQL_TEXT列的类型为varchar(1000),即这个号称可以共享SQL语句的缓存统计表,处理客户端发送过来的SQL语句,其存储的字符集为nls_characterset! 欢迎大家指正! [face32]以上文章是我在写上一篇《ArcSDE启动发生GEOMETRY_COLUMNS相关错误的解决办法》后查nls_characterset相关资料时找到的,粗略看了一下,没有细究,但觉得很有见解,收藏。
同事去客户现场安装调试ArcSDE时遇到问题,SDE安装过程很顺利,显示成功安装。但是在启动SDE时却报了一个错误。 [sde@SDE_SERVER bin]$ ./sdemon -o start -p sde@sdedbsid ------------------------------------------------------- ArcSDE 9.2 for oracle10g Build 1081 Sun Sep 17 16:01:22 2006 ------------------------------------------------------- ST_Geometry Schema Owner: (SDE) Type Release: 1007 Instance initialized for ((sde)) . . . Connected to instance . . . Inconsistent data type in GEOMETRY_COLUMNS table. Could not start ArcSDE -- Check Network, $SDEHOME [...]
坐标是GIS数据的骨骼框架,能够将我们的数据定位到相应的位置,为地图中的每一点提供准确的坐标。 ArcGIS自带了多种坐标系统,在${ArcGISHome}\Coordinate Systems\目录下可以看到三个文件夹,分别是Geographic Coordinate Systems、Projected Coordinate Systems、Vertical Coordinate Systems,中文翻译为地理坐标系、投影坐标系、垂直坐标系。 关于地理坐标系和投影坐标系的区别,网络上有相关的文章介绍--地理坐标系与投影坐标系的区别,简而言之,投影坐标系=地理坐标系+投影过程。 1 Geographic Coordinate Systems 在Geographic Coordinate Systems目录中,我们可以看到已定义的许多坐标系信息,典型的如Geographic Coordinate Systems\World目录下的WGS 1984.prj,里面所定义的坐标参数: GEOGCS["GCS_WGS_1984",DATUM["D_WGS_1984",SPHEROID["WGS_1984",6378137, 298.257223563]],PRIMEM["Greenwich",0],UNIT["Degree",0.017453292519943295]] 里面描述了地理坐标系的名称、大地基准面、椭球体、起始坐标参考点、单位等。 2 Projected Coordinate Systems 在Projected Coordinate Systems目录中同样存在许多已定义的投影坐标系,我国大部分地图所采用的北京54和西安80坐标系的投影文件就在其中,它们均使用高斯-克吕格投 影,前者使用克拉索夫斯基椭球体,后者使用国际大地测量协会推荐的IAG 75地球椭球体。如Beijing 1954 3 Degree GK CM 75E.prj定义的坐标参数: PROJCS["Beijing_1954_3_Degree_GK_CM_75E",GEOGCS["GCS_Beijing_1954", DATUM["D_Beijing_1954",SPHEROID["Krasovsky_1940",6378245.0,298.3]], PRIMEM["Greenwich",0.0],UNIT["Degree",0.0174532925199433]],PROJECTION["Gauss_Kruger"], PARAMETER["False_Easting",500000.0],PARAMETER["False_Northing",0.0], PARAMETER["Central_Meridian",75.0],PARAMETER["Scale_Factor",1.0], PARAMETER["Latitude_Of_Origin",0.0],UNIT["Meter",1.0]] 可以看出,参数里除了包含地理坐标系的定义外,还有投影方式的信息。 北京54和西安80是我们使用最多的坐标系,在ArcGIS文件中,对于这两种坐标系统的命名有一些不同,简单看去很容易让人产生迷惑。在此之前,先简单 介绍高斯-克吕格投影的基本知识,了解就直接跳过,我国大中比例尺地图均采用高斯-克吕格投影,其通常是按6度和3度分带投影,1:2.5万-1:50万 比例尺地形图采用经差6度分带,1:1万比例尺的地形图采用经差3度分带。具体分带法是:6度分带从本初子午线开始,按经差6度为一个投影带自西向东划 分,全球共分60个投影带,带号分别为1-60;3度投影带是从东经1度30秒经线开始,按经差3度为一个投影带自西向东划分,全球共分120个投影带。 为了便于地形图的测量作业,在高斯-克吕格投影带内布置了平面直角坐标系统,具体方法是,规定中央经线为X轴,赤道为Y轴,中央经线与赤道交点为坐标原 点,x值在北半球为正,南半球为负,y值在中央经线以东为正,中央经线以西为负。由于我国疆域均在北半球,x值均为正值,为了避免y值出现负值,规定各投 影带的坐标纵轴均西移500km,中央经线上原横坐标值由0变为500km。为了方便带间点位的区分,可以在每个点位横坐标y值的百千米位数前加上所在带 号,如20带内A点的坐标可以表示为YA=20 745 921.8m。 [...]
JavaScript调试起来很不方便,有时候需要知道某个对象有哪些属性和值,利用下面的代码就可以了: function getAttribute(obj) { // 用来保存所有的属性名称和值 var props = ""; // 开始遍历 for(var p in obj){ // 方法 if(typeof(obj[p])=="function" { obj[p](); }else{ if(typeof(obj[p])=="object" { //递归 getAttribute(obj[p]); }else{ // p 为属性名称,obj[p]为对应属性的值 props+= p + "=" + obj[p] + "t"; } } } // 最后显示所有的属性 document.write(props + " " ; }