divil

Nice try, but the window will not repaint correctly when someone drags a window over it (see attached screenshot). You have addressed this by making the splash screen window topmost = true, and there are few things more annoying than splash screens that display over whatever you're trying to do. One of the core things you need to make sure you do (as a windows programmer) is paint the whole of your window when asked to. The method you're using is not painting all of it, resulting in the background being left showing. This is fine until windows asks for a repaint or someone drags something over the form. The layered approach draws the entire background - taking pixels from behind the window if necessary. Thus repainting is handled like it should be. Remember my example wasn't supposed to be easy, it was supposed to be the best way of doing it. If you don't mind your splash screens being topmost and not necessarily repainting correctly, use Dameon's approach :)

Override the GetHitTest method in your designer so that area of the control has mouse actions passed to the control and not the designer.

As you have no doubt noticed, this forum recently received a facelift and software upgrade by our new owners, iNET Interactive. The site has a great new look and feel designed to be in keeping with their other sites. We have now inherited some alternatives to the default gray style from our sister site. You can change the colour scheme you view the forum with by going to Profile -> Edit Options (at the bottom of the page). Please continue to bear with us as any last issues are worked out :)

Removed call to SetLayeredWindowAttributes for win9x operating systems so the sample code runs.

Ok. 1) 32bit icons are supported only in Windows XP. No previous version of Windows will identify or cope with an alpha channel in an icon. 2) Large icon sizes are also only supported in Windows XP. 128x128 is the highest supported size, although as you have shown it can work with larger. 3) My method *does* work in previous versions of Windows, and you cannot tell the difference visually. The only restriction is that the window will not all be repainted if another window is moved across it. I didn't realise backwards compatibility was an issue to you, but since it is I feel I need to remind you that your code will crash on any version of windows prior to XP, and mine will work with no visual difference whatsoever. I'm attaching a couple of screenshots comparing the output on Windows 98. I did not mean to put your code down, but I also don't want people shipping applications using it and not realising that they will crash on pre xp systems :)

First you need to detect if you're running on XP or later, by checking Environment.OSVersion. Then you need to use the IsAppThemed api, exposed in uxtheme.dll. For more information on this api consult msdn.

Using 32bit icons is not a good way of achieving this effect. I have written and posted an example of how to create splash screens like the ones in Adobe products using layered windows and alpha blending. The sample is downloadable from the Code Library. http://www.xtremedotnettalk.com/showthread.php?t=83910

In response to requests for code to create splash screens similar to those found in recent Adobe products I decided to knock together a code example and reusable class for displaying splash screens with varying opacity (drop shadows). Note that the layered effect is only possible on Windows 2000 and later operating systems. Layering allows the window to be repainted correctly if another window is moved over it. However, because of the momentary nature of splash screen this will likely not be a huge concern and the code will look just the same on Windows 98 from a translucency point of view. This code is primarily about alpha blending, not layered windows. The key to achieving this effect is manipulation of pixels. We want to take a source image in 32bpp format (I'm using a PNG), a source image taken from the screen (the area behind your splash screen) and perform alpha blending to draw the surface of the layered window. The default layered window support only allows for uniform translucency within a window which is why we are doing the hard stuff ourselves. The most important issue with this kind of pixel manipulation is speed. For a splash screen, you do not even want to be aware that there is image processing going on. I have therefore written this code in c# using pointers for direct memory access to the bitmap data. The splash screen in the sample requires nearly a quarter of a million pixel values to be calculated in a split second. To run the sample, open the solution in Visual Studio and press start. The splash screen shows itself for five seconds then the application terminates. I apologise for the poor quality of the splash screen, but I'm a programmer not a pixel fairy. splashscreen.zip

Yes, because what the world needs is another programming language.

I beg your pardon?

Why would you want to? You said yourself that you'll be incorporating custom controls and objects, the whole point of plugins is that you don't know every bit of functionality you'll get, just a common base.

Take a look at Activator.CreateInstance. You'll need all your plugins to implement a common interface or inherit a common base class.

It sounds like it can't handle getting the main window handle.

I'll run a few tests and see what I can come up with.

I am surprised you're still seeing it as extreme .net forums mailer as the name of the forum has been changed.

No. There is likely a much better method of doing what you're trying to do, if you gave us the bigger picture we are more likely to be able to help.

That means you cannot use the Process class in the way you are from Windows 98. It doesn't have anything to do with the API you're using.

How recently did you notice this?

The hardest part of good collision detection is the part that comes _after_ the detection, i.e. what do I do about it? I found writing a simple platformer with sloped surfaces a great refresher on the applied maths I took back in college.

http://www.irritatedvowel.com/Programming/Standards.aspx These are the naming conventions you should be using with .NET. You should ensure you comply with these for all public or exposed members at the very least, but it's probably best if you just comply completely.

I guess I never considered that people would use a server OS for that kind of thing :)

You're running DirectX and games on Windows Server 2003?

Or click on the link in my signature...

You could use GetWindow to get the handle of the child textbox window. You would have to do this whenever the parent combobox's handle was recreated, i.e. by overriding OnHandleCreated. You'd then have to subclass this handle for the WM_PAINT message by create a class that inherits from NativeWindow. Remember to unbind this class in the parent combobox's OnHandleDestroyed method.

Drawing combo boxes is a pain. The first thing I notice about your code is that you're not releasing the DC you got, a very bad thing not to do. Also I would circumvent that problem entirely by using Graphics.FromHwnd instead of FromHdc. You should not try to paint on top of the text box area as this will have unpredictable results - if you want to owner draw the combo's border you should paint only the bits that aren't the text box (you can use the system metrics to get the areas to draw). If all you want is for your ownerdrawn items to show up in the combobox, then you should just use the DropDownList style and it will do it automatically. Also there will be no textbox.