Archive for the ‘CodeProject’ Category.
June 14, 2009, 08:09
A threaded form uploader app in C#
Recently I had to do an app that watches a dir for new files and then uploads them to a DocuShare server using http form post.
I was told, that it is very easy to use form post from code and decided to do the app in C#. Unfortunately, it was not that easy to find code that does uploads via form post, especially for Compact Framework (CF). Maybe it is easier in JAVA, but for JAVA I had to install a JAVA VM onto the windows mobile 6.1 device and for CF all runtimes are already on the device. I searched the internet for valuable form post code in C# and found one titled ‘C# is the better JAVA‘.
OK, this code looked good and i tried it within Compact Framework. After changing the functions to ones available in CF, the code runs fine. As you know, CF does not have the same full featured functions as the .Net Framework for PCs.
Continue reading ‘Windows mobile worker thread to post form data using a queue’ »
June 11, 2009, 10:42
zDump
Do you like to spy your WinCE device? Try zDump! I used it to find the window classes and styles of iesample.exe to be able to write iLockIE2.
You can use it to inspect windows and there styles and you can CHANGE there styles (ie disable the taskbat window).
In this screen I spyed the X button of iesample.exe.
[Download not found]
May 27, 2009, 09:17
recently I read an article about using SetSystemPowerState instead of KernelIOControl:
SetSystemPowerState(NULL,POWER_STATE_RESET,0);
Using KernelIOControl to reset a device (warm or cold boot) may not flush buffers to storage and so the article shows how to use SetSystemPowerState to reboot a Windows Mobile device.
I recommend all to use SetSystemPowerState to reset a WM device instead of using KerneIOControl to avoid missing data. SetSystemPowerState with argument POWER_STATE_RESET will first flush disk buffers and then perform the reset. This will be much safer than doing it the ‘hard way’ with KernelIOControl.
see also here and at MSDN and this great article at CodeProject
May 27, 2009, 06:10
when you got a memory problem, it will hard to find the cause. We have seen failing scanners and failing GPRS connections for ‘no reason’. These cases where identified with a tool called memoRX available for WM5 only.
The problem with WM memory handling is, that all processes share the same DLL space. Every process is loaded into a 32MB memory slot. All DLLs loaded by any runnning process is ‘mirrored’ into these 32MB slots. Process memory is used from bottom to top and DLLs are loaded from top to bottom. When the usage borders get closer, strange problems may occur. Device.exe, which loads all drivers, is a critical memory slot.
Continue reading ‘Managed application suddenly fails to invoke DLLs’ »
http://www.led-mg.de