Developers - WM_NCLBUTTONDOWN and DIB Palettes...

Hi,
I'm porting an application to the HPC, and have hit upon two problems when executing my app on the HPC. Under the emulator, everything is great...

Problem 1: client area drag to move window
My application opens a child window, which then shows a graphic. I want to open the window with no caption, and no system menu so as to display just the graphic. On WM_MOUSEMOVE events, I'm sending a message to the window with WM_NCLBUTTONDOWN and HT_CAPTION as the message type and wParam respectively. This works brilliantly on the emulator, but wierd things happen with the HPC. By wierd, I mean the window moves, but an offset is applied... This could be to do with the fact that I'm using a pen, and the system cannot reposition the mouse like it can on a normal input system? Any advice appreciated!

Problem 2: DIB palettes
The graphic that my application creates is a 16 indexed colour bitmap. The palette is translated from a 9 bit colour (3 bits red, 3 bits green, 3 bits blue) into a standard RGB_QUAD by multiplication or, more accurately, left shifting. I then use the CreateDIBSection with a BITMAPINFO structure containing the palette, and copy the bitmap into the returned bitmap. This works on the emulator, but on the HPC causes the colours to appear waaaay too bright. The colours are there, but just a lot brighter than they should be. Wierd, truly wierd... Could this be something to do with a difference in system gamma?

Any advice appreciated!

Cheers,
nick.
ps - for the interested, the application is a port of Magnetic, a Magnetic Scrolls game interpreter. It's working, and games can now be played

I'm not a programmer, I'll try and attract the attention of some for you though.

However you can't use a mouse event handle as there is no mouse. The cursor position of a touch screen is determined by jumped coorinate update not by progressive updates like with a mouse.
I think that from your description, you're trying to create a full screen splash screen, is that right?
Remember that you need to avoid specifying static window sizes as under the H/PC the actualy display can vary from 480x240 up to 800x480.

As for option 2.
What colour pallet is the 16-bit using. If it's a windows generic pallet (which frankly it would have to be) then your colour scope is limited. Your image will need to use dithering to get any tone out of it. If you are using a custol pallet, and this applies leads into my second point. Be careful using arbitary colour pallet values. A lot of CE devices will only take 8-bit or 16-bit colour.
It is unlikly going to be a gamma level problem. One CE system seems pretty much the same as the next.
If you want to check though, load this up on the deivce:
hpcf_test_card_a.zip

I created is primarily for use on checking linarity when using a VGA adapter on a TV, but should give you a contrast.

Hi Chris,
Thanks for that.
the WM_MOUSEMOVE event occurs when the tip of the stylus is dragged on the screen. WinCE messages are shockingly similar to the Win32 messages to ease development, so even though there's no mouse the messages are still declared as mouse messages...

The DIB stuff shouldn't be a problem: the screen is running in hi color, so I should have access to all the colours that I need. What is truly weird is that the colours appear perfectly on the emulator, but fail to do so on the HPC! It's as if the colours have been massively brightened, and at the moment I can't fathom why... I'm sure it'll be a true "d'oh" moment though!

Any help appreciated! Would there be enough interest to start a developer forum? Despite being rather inexperienced, I'll gladly try to share my knowledge.

Cheers,
Nick.

Oh I see, so the event in the game actually requires a mouse drag. I was assuming "tap tap tap".

I've emailed a couple of developers that I know who loiter around the H/PC community. With any luck they will show up and bash heads with you.

Starting a developers forums is a good idea, something we've discussed many times before, even before we started this site! Alas none of the senior staff here are developers by trade and so could not provide the internal support.
If there were sufficient developers attending this board who wanted the facility. We would happily add it for them.

Well, my hand's in the air for the forum - hopefully others will join in too

I've tried another approach... Capturing WM_NCHITTEST, getting the default window process result for the message, and if the result is a client hit, telling windows that it was actually a caption area hit - which means that it'll move the window.

Guess what?

Works perfectly on the emulator. Doesn't work at all on the device. As background, WM_NCHITTEST is a message that expects a response saying whether the hit was in the client area, or in part of the system controlled areas. If it's in part of the system controlled areas, the system takes care of stuff for you.

I think my problem is that I'm trying to use windows messages that aren't strictly supported by the platform but have been inherited from the Win32 platform for the emulator. I need to step back and look at doing it a manual way.

If anyone's interested, this works on the emulator but not on an HPC. A clue should be that the message number is undefined in the include files, which means that it probably isn't properly supported :-)

		case 0x84:  //NCHITTEST - WORKS on emulator, doesn't work on HPC! 
			i=DefWindowProc(hWnd,wMsg,wParam,lParam); 

			if(i==1) //HTCLIENT 

				return 2; //HTCAPTION 

			else 

				return i; 

			break; 

I guess I'm back to looking at capturing WM_LBUTTONDOWN, noting the X/Y position of the hit and the X/Y pos of the window, then on each WM_MOUSEMOVE calculating the delta and moving the window with a MoveWindow() call... Not a hardship, but not nearly as elegant as having Windows sort it out for me!

Cheers,
Nick.

Nick,

It's just occured to me (dumb as I am sometimes) that you're coding for HPC2000 here.

You do realised that the Emulator (and this if you're using the Emulator the SDK) that you are using is actually the HPC Pro (Ce 2.11) emulator?
The API calls between the two are vastly different.

You can get the 2000 SDK from here

As for the developer forum. If we see enough support for it. Consider yourself it's Moderator.

Hi Chris,
I'm using EVC 3, and have both the HPC Pro 2.11 and HPC 2000 SDKs installed. As you know, the HPC2000 SDK does not have an emulator, so I am developing against 2.11 for the majority of time, then changing to use 2000 to test on the machine.

I have set up project configs for both HPC2000 and HPC Pro 2.11 which are identical.

The APIs between 2.11 and HPC2000 that I am using are the same: there are no differences in anything that I am using. However, it appears that the emulator has implemented above and beyond what is specified in the 2.11 SDK (such as the WM_NCHITTEST, and other stuff) which explains the problems that I'm having.

I'll trap WM_LBUTTONDOWN, store the window position and hit point, then update the window position with the delta between WM_MOUSEMOVE messages.
Cheers,
Nick.

Hi chiark,

i think you mean 16 bit RGB bitmaps and not a 16 color indexed bitmap (4 bit).

All dibs above 8 bit (256 colors) do not have a palette. The values representing a color are not an index to a color palette entry. The bits representing a pixel are direct r-g-b values.

The default 16 bit dibs in windows ce have a R-G-B 5-5-5 bitfield mask (32768 colors). Not a 5-6-5 mask!
You must use the folowing default masks to become the true colors:

RedMask = 0x00007c00;
GreenMask = 0x000003e0;
BlueMask = 0x0000001f;

Rgds
Wolfgang