I've created an application that paints on the window using GDI functions. It works fine. But because it is still under development it sometimes craches. It seems that if there are certain craches Windows Vista suddenly decides to treat my application in a new way: while drawing on the window it decides it must redraw that was on the screen when i started my application. The effect is that some drawing is lost. Windows continues with this behavour till i reboot my pc. After i booted the same piece of code draws the window correctly. I used Spy++ to find out what's happening. When the window is correctly displayed i see the following:

<00037> 00340626 P WM_LBUTTONDOWN fwKeys:MK_LBUTTON xPos:1215 yPos:640
<00038> 00340626 P WM_LBUTTONUP fwKeys:0000 xPos:1215 yPos:640
<00039> 00340626 P WM_LBUTTONDOWN fwKeys:MK_LBUTTON xPos:1249 yPos:711
<00040> 00340626 P WM_LBUTTONUP fwKeys:0000 xPos:1249 yPos:711

(I press the mousebutton to start drawing, it draws the window, i press the mousebutton again to close the window)

When things go wrong Spy++ reports the following:

<00037> 00340626 P WM_LBUTTONDOWN fwKeys:MK_LBUTTON xPos:1219 yPos:643
<00038> 00340626 P WM_LBUTTONUP fwKeys:0000 xPos:1219 yPos:643
<00039> 004904B2 S WM_WINDOWPOSCHANGING lpwp:0012FE20
<00040> 004904B2 R WM_WINDOWPOSCHANGING
<00041> 004F0646 S WM_WINDOWPOSCHANGING lpwp:0012FE20
<00042> 004F0646 R WM_WINDOWPOSCHANGING
<00043> 00340626 S WM_WINDOWPOSCHANGING lpwp:0012FE20
<00044> 00340626 R WM_WINDOWPOSCHANGING
<00045> 004904B2 S WM_WINDOWPOSCHANGED lpwp:0012FE20
<00046> 004904B2 R WM_WINDOWPOSCHANGED
<00047> 004F0646 S WM_WINDOWPOSCHANGED lpwp:0012FE20
<00048> 004F0646 R WM_WINDOWPOSCHANGED
<00049> 00340626 S WM_WINDOWPOSCHANGED lpwp:0012FE20
<00050> 00340626 S .WM_SIZE fwSizeType:SIZE_RESTORED nWidth:1280 nHeight:770
<00051> 00340626 R .WM_SIZE
<00052> 00340626 R WM_WINDOWPOSCHANGED
<00053> 004904B2 S WM_WINDOWPOSCHANGING lpwp:0012FE20
<00054> 004904B2 R WM_WINDOWPOSCHANGING
<00055> 004F0646 S WM_WINDOWPOSCHANGING lpwp:0012FE20
<00056> 004F0646 R WM_WINDOWPOSCHANGING
<00057> 00340626 S WM_WINDOWPOSCHANGING lpwp:0012FE20
<00058> 00340626 R WM_WINDOWPOSCHANGING
<00059> 00340626 P WM_PAINT hdc:00000000
<00060> 00340626 S WM_ERASEBKGND hdc:D1011D9A
<00061> 00340626 R WM_ERASEBKGND fErased:False
<00062> 00340626 S WM_GETICO

See: SetWorldTransform() at http://msdn.microsoft.com/en-us/library/dd183475(v=VS.85).aspx[^]

But what Godel proved was: There can be no system (identity) that is powerfull enough to prove its own trueness. I'm a humanist..

Guess God is an object created from a class that inherits from itself...

First they create a PC that is not owned by the user anymore, now it is even not owned by the programmers... Can anybody write a descent OS?

Not an answer to your question, but what i don't understand is: Why not render the dimmed icon offline (with the commandline) and read this icon in, during runtime? I guess you don't create icons in runtime on the fly, so what is the use to create a dimmed version in runtime?

Ever tried WINE (http://www.winehq.org/[^])?

Flicker occurs when there are intermediate pixels on the screen. Example: draw a blue,filled rectangle, then draw a non-rectangle bitmap over that. The blue pixels 'under' the bitmap cause the effect. There are 2 solutions: 1) avoid the drawing of unneeded pixels by making your algorithm better (and faster) or using regions (see winapi documentation), 2) draw everything in a buffer (memory DC) and transfer that to the screen. This is called 'double buffering'. The first solution is most of the times too difficult to implement, so solution 2 is widely used, although it is actually slower.

I hope i understand your questions clearly. Im not using GDIplus (but GDI) and Im not using your program language, but maybe this helps a little: - to get transparency on the pixellevel every pixel in your bitmap must be 4 bytes (RGBA) and not 3 bytes (RGB). See MSDN for exact info. In the A byte (called alpha channel) you may set the transparency level between 0 and 255. You should use the winapi function Alphablend() (or the gdiplus equevalent) to copy the bitmap to the screen. - One of the problems with transparent bitmaps is that when you put them on screen the transparency is visible but this information is lost (on the screen). Let me explain this: Suppose you want to fade in a bitmap. Then for every step you must first repaint the background (that what wad on the screen before the bitmap was painted on it) and then copy the transparent bitmap on it, decreasing transparency in every step. If you don't repaint the background first you will not get the desired result (but a transparent bitmap on a tranparent bitmap). The screen has no transparency set (it is a RGB-surface) so saving it will result in a bitmap that only shows 'what was on screen'. Transparency is a property of a bitmap not of the screen that displays it (the screen shows the result only). Hope this helps a bit... Good luck, Rozis

I guess it is because reposition and size lead both to a repaint of the window. You could use validaterect() or validatewindowrgn() (these are GDI-functions, look for GDI+ equivalents) after reposition so windows believes there's no need to repaint. Then repainting only occurs after size showing the reposition also. Hope this will work...

Look for ROP2 drawing codes in the GDI documentation (function SetROP2()). They do exactly what you want. Rozis

And what about WS_EX_CLIENTEDGE and WS_EX_STATICEDGE?

I'm not using MS-stuff. Do you know if there's a win32 equivalent? Thanks, Rozis

When i open chapter and sections, the window shown is bigger then the screen but there's no way to scroll it... The menu Questions and Answers has the same problem (suggestion: use submenu's)..

I'm trying to create a RichEdit without any borders tried to set off ES_SUNKEN, WS_EX_CLIENTEDGE but nothing works: it keeps coming with that ugly sunken border. Has anyone a clue, or better, an example in C or C++? PS. of cource ES_MULTILINE,ES_AUTOHSCROLL,ES_AUTOVSCROLL are on... Thanks in advance... Rozis [Update] I found out i was still using version 1. Did some changes to support version 3 and 4.1. Because the control displays correctly (apart from that ugly border) I conclude this code must be ok. WS_EX_CLIENTEDGE ultimatly leads to SetWindowLong(). So I thought to be smart and set everything off, like this: SetWindowLong(whnd,GWL_EXSTYLE,0) To my surprise it still displays the border! What i want to get rid off is WS_BORDER, WS_EX_CLIENTEDGE and WS_EX_STATICEDGE. For version 4.1 I use Loadlibrary("MSFTEDIT.DLL") and classname "RichEdit50W". The MS-documentation says not all styles are implemented, so i thought maybe it is not possible. Your reactions indicate i'm not right... But i still can get it to work. Someone any (win32) suggestions? [Solved] Used Spy+ to find out wich styles where there. Used Setwindowlong() to put the styles in. I think this was a quirk of my gui-classes Thanks anyway [End Update]

modified on Friday, July 2, 2010 4:15 PM

As a dutch guy i was already ashamed with Mr. Balkenende (Harry Potter runs Holland) for 8 years, but now that so many people vote for Mr. Wilders, shame came to new heights. Holland known for its tolerance votes now for a near racist party... I'm sorry guys...

What i would do: - Create a bitmap of a car. - define rectangles where the user may click on. Save those rectangles (origins and sizes) in an array or file - run the program and measure its screen-size - calculate the difference in size of the screen and the bitmap in a ratio - read in the bitmap and put it on screen. Stretch it when needed (use StretchBlt() ?) - read in the rectangles - When stretched multiply all coords of the rectangles with the ratio. - program the actions - Monitor the mouse up messages: when the mouse is in one of the rectangles, invoke the corresponding action. ready... If you still have time over: - take the bitmap and cut out every rectangle, colorize it a bit and save it as a new bitmap. Now every rectangle has a (sub)bitmap that can be displayed while the mouse hoovers over the rectangle (you'll need to monitor mouse moves also) .. Rozis

modified on Wednesday, April 28, 2010 8:38 PM

Hi Iain, Thank you for your answers, and the time to get the answer. Of course you're right about the button down vs button up. I have to reconcider that. But actually you found out how it really works (WM_CONTEXTMENU). So i'll track that one and throw in the void... Thanks again Rozis

This is a part 2 on a question i posted earlier on this forum. The problem: In a Keydown handler, when a user pressed the VK_MENU key an editbox is created. So far so good. Problem is that the standard behaviour of windows for a KEYUP-message of this key is to open a context menu. I was suggested: 1) to create the editbox in the keyup handler. This is not an option. 2) to swallow the keyup-message. This sounds good. My question: how to swallow the keyup message? Is it setting up a local message dispatcher that dispatches messages till the keyup event comes in view, and then just trow it away? What happens to the keyboardstate then? I'm using C. A light on the right approach would be welcome... Rozis

I agree on your answer - clever