I have been trying to figure this out for just over a year now -[RESOLVED]-

[joey o.]

Hi All

I need an expert whose seen this before:

I use an operation to create irregular cuts in a paint project that creates a mask using flood fill and blits to do an invert in a seperate picture box dc. I use point to get the current color and then feed it to transparentblit function which uses this to create the cut area and mask the outside edge of the cut when I move it. This works fine in Win 98. In XP I want to keep code downward compatable.
Here's the problem:
In XP the floodfilled color when inverted is recognized by point and when the dc is blitted to a form it still shows same number but for some reason transparentblit will not turn this color transparent anymore.
Does anyone know what I'm talking about? How can I fix this? Is it the floodfill or the invert on the original DC that's messing things up? Obviously something is either too fast or persisting where it didn't in 98. I've tried wait and doevent functions with no difference. Please, Please, Please help! I have been trying to figure this out for just over a year now.

[darrenl]

Is the problem anything to do with the colour depth used in XP. I have had some problems in the past with GDI giving problems when the colour depth was not 16 or 32 bits.

[joey o.]

I don't think so but later on I'm going to brake the dc appart using 32 bit code. That'll confirm as it will fail if it is not. What I'm narrowing it down to is that Inverted DC holds it's inverted qualities and inverts every time I do a srccopy on it in 98 not so in xp - it seems to cancell out and turn black. I'll have it isolated to just one or two steps in a day or two and I'll post it. Thanks

[Electroman]

I'm not really following this quite right but when ever you use a DC it will be the same bit depth as the desktop: However my Destop is running at 32bit but DCs will be arranged as if it was 24bit. Don't know if that helps you though .

[Fox]

I'm not exactly sure but in WinXP the parameter of the Floodfill function might have changed it's meaning. Check MSDN for more details. One thing that's for sure is that in WinXP DCs often get 'lost', I don't yet know why this happens but some of my old games don't work under WinXP anymore. You have to restart them x times until all graphics are displayed. However since I switched to DX all the problems were solved.

[joey o.]

Resolved (really I surrendered) the issue by hard coding the floodfillcolor to '0'. Using black doesn't appear to be interpreted in any other way but black and doesn't interfear with additional colors made transparent in dc's added to it. Only down side is any additional drawing in black will be transparent regardless. Thanks for help.

[Electroman]

Well the problem you have with all the black that isn't transparent is easily solved by chnaging it to RGB(1,1,1) .

[joey o.]

I think the reason '0' works is because I invert the dc a few times after the floodfill. Even if I get it right the floodfilled color is still never recognized but the identicle color that drew the outline to fill is. point process even confirms the outline and fill are the same. '0' appears to work because any multiplication or division operation against 0 still results in 0...just my guess. Done with it now. I'm gonna go get a life as is often suggested I do. I guess I'm fortunate that my app is now 100% between all windows versions other than '95 (just my guess that I may have used a late API or 2 but never really tested on 95 to be sure). Let's hear MS and all the other big guys say that!