Logged in as Guest   Fri, Mar. 12th, 5:09 AM.
Recent Entries: My Dev Setup Lately Three Ways To Randomize on the iPhone How to Remove .svn Directories On a Mac How To Detect The iPhone Simulator iPhoneMom Likes Doodle Games! Updates To the Doodle Games Line Three Jacks Now Tweets Second iPhone App Submitted For Approval! Pinch Media Analytics for iPhone New iPhone Game Coming Soon! Archive: January - 2010 November - 2009 October - 2009 September - 2009 August - 2009 July - 2009 June - 2009 April - 2009 March - 2009 January - 2009 May - 2008 April - 2008 March - 2008 October - 2007 August - 2007 July - 2007 June - 2007 May - 2007 April - 2007 December - 2006 November - 2006 September - 2006 August - 2006 July - 2006 March - 2006 February - 2006 January - 2006 December - 2005 November - 2005 October - 2005 September - 2005 August - 2005 July - 2005 June - 2005 May - 2005 April - 2005 February - 2005 January - 2005 December - 2004 November - 2004 October - 2004 September - 2004 August - 2004 July - 2004 June - 2004 May - 2004 April - 2004 March - 2004	Symbian Error Codes If you have ever debugged on a Symbian device, then you know how handy having an error reference "cheat-sheet" is. That's why I was pretty happy to find this list. Submitted by bosshogg on Tuesday the 07th of September 2004, at 08:11 am WiFi-Where Works With New PalmOne WiFi SD Card So, I managed to get my hands on one of PalmOne's new WiFi SD cards that is compatible with the Tungsten T3 and Zire 72. I was curious if the same SDK that is available for the Tungsten C would work on it, and I was pleased to find that it did. I grabbed a Zire72 from work, and I ran WiFi-Where 1.0 on it, and quickly scanned all the hotspots in my neighborhood. This is a great move by PalmOne because that means that all the apps that have been written for the Tungsten C will just automagically work with the new card. Submitted by bosshogg on Friday the 03rd of September 2004, at 08:30 am Direct Screen Access On Palm So, I have been doing a little bit of research into direct screen access on the Palm. From everything that I've seen, it appears that there are three ways that direct screen access can be accomplished: 1. WinGetDisplayWindow()->displayAddrV20; 2. WinScreenLock(...); 3. BmpGetBits(WinGetBitmap(WinGetDisplayWindow())); The first method is obsoleted, and even though you can get around it by turning off some of the compiler directives, it fails on most OS 5 devices. Because of that, I won't talk too much more about it here. The second method is basically a double-buffering method. When you call WinScreenLock(), you get a pointer to the offscreen buffer, and all system drawing is performed on the offscreen until you call WinScreenUnlock(). Unfortunately, this method isn't supported on all devices. Strangely enough, it isn't even supported on some newer devices like the original Tungsten T. The third method is the 'safest' method and should work on all devices. However, there has been some discussion about whether or not this actually returns a pointer to VRAM on all devices or if it is 'emulated' on some devices. I can't comment on that since I don't have the source for any vendor implementations, however. The other downside to this is that if you don't perform your screen refresh quickly enough, the user will see flicker, whereas with WinScreenLock, it is guaranteed against flicker. However, if device independance is your goal, then you will definitely want to use the third method. Submitted by bosshogg on Thursday the 02nd of September 2004, at 09:08 am