The proper way to implement non-rectangular windows in .NET WinForms is via the Control.Region property, not via any hackish, homegrown color-keying approach.
Color-keyed approaches to transparency are possible, but the results vary widely with the video hardware/mode (8bpp? 15/16bpp? 24bpp? 32bpp?) and therefore the techinique is all but useless in the space of end-user apps. > Since the GUI coder located out of the country, I've emailed screen shots from > all of the various machines to her and she still can't put her finger on the problem. > > Between this and trying to resolve issues of threading with C++ backend code that > must communicate with the GUI in C# .NET I'm starting to pull my hair out. Umm... What's wrong with Control.Invoke? Is this the kind of quality people are accustomed to, with overseas development outsourcing? Are you still convinced it's saving you money? Do you really believe that this is a "language bug", and that paying your offshore dev team to port the code from C# to C++ will somehow fix things? </bitterness> No. Here's the thing: software development, even with .NET, is still hard. Your team may be 100x more productive with C# than they are with C++, but they still have to understand the underpinnings of the OS when it comes to implementing features like non-rectangular window regions and multithreaded UI programming, or else they will have no success at all. If you really must do these kinds of things, you should hire an expert consultant to help put your dev team on the right track. -S -----Original Message----- From: Peter D. Vouvounas [mailto:[EMAIL PROTECTED] Sent: Tuesday, November 11, 2003 10:03 Subject: Expert guidance or idea's needed Morning Folks, I could really use some input from one or more of the experts on the list regarding the following conditions: First we have a GUI under development and the coders are using C# and .NET framework. I supplied all of the graphics which consists of a couple of hundred gif files. The individual gif files are cutouts from the main GUI body plus mouse up, mouse over (Hover) and mouse down graphics for the various controls. Now this is where the initial problems start:!!!! The GUI is not a square window - it has many rounded borders or contours. Our graphic artist mentioned using a blue background in the programming process so that the square edges can be keyed out. The current result is as follows - We have at least five different people (machines) that attempt to run the C# .NET GUI as the development continues. 1. Windows ME 2. Windows 98SE 3. Three machines with XP Pro Each person (geographical different) has downloaded .NET ver 1.1 from Microsoft and installed on their machine. When the GUI is executed on ME and 98SE it always has a ragged border of blue around the GUI - Not just a square outline but blotches of blue - They never ever have seen the GUI come up without the blue and the performance is extremely sluggish in response to various button presses. For example the GUI has three roll-out panels. In the mode just described the panels roll out very slow and a bit jerky - Same when moving the GUI around the screen it's a bit jerky. Now the alternate to the description takes place in my computer environment. Randomly when I start the GUI on my XP Pro machine it looks perfect! Very smooth as it is moved around the screen - No blue at all anywhere around the contoured borders. Panels rollout smoothly and timely - Demonstration mode that simulates action graphics in an LCD like window are smooth and they startup in less then a second of the button press. It does not stay that way though - sometimes it starts up in my XP PRO system and looks and operates pretty much the same as I described above on the 98SE and ME machines. The demo mode then takes five to eight seconds to start - jerky around screen - blue splotches etc. What is a bit interesting is that I can command my video (GeForce4) to rotate my CRT screen (desktop) 180 degrees and then rotate back to normal and sometimes by doing this the GUI goes back to what I would call the normal mode! We have been looking long and hard to try and figure this out as our C# .NET developer has not been able to duplicate this on her machine running 98SE. Since the GUI coder located out of the country, I've emailed screen shots from all of the various machines to her and she still can't put her finger on the problem. Between this and trying to resolve issues of threading with C++ backend code that must communicate with the GUI in C# .NET I'm starting to pull my hair out. Are any known documented or undocumented problems inherent in C#. .Net that might cause this? Or are we missing some basic concept in the coding of C# or .NET? Outside of the above items we believe the coder is going to move to C++.NET so that we can thread our native C++ back-end code with the GUI. I'm holding on to my cap for this as it will probably throw more items into the mix. Thanks for any help advice. PeterV WB3FSR [EMAIL PROTECTED] =================================== This list is hosted by DevelopMentor. http://www.develop.com Some .NET courses you may be interested in: Guerrilla ASP.NET, 10 Nov 2003 in London and 26 Jan 2004, in Los Angeles http://www.develop.com/courses/gaspdotnet Guerrilla .NET, 8 Dec 2003, in Los Angeles http://www.develop.com/courses/gdotnet View archives and manage your subscription(s) at http://discuss.develop.com =================================== This list is hosted by DevelopMentorŪ http://www.develop.com Some .NET courses you may be interested in: Guerrilla ASP.NET, 10 Nov 2003 in London and 26 Jan 2004, in Los Angeles http://www.develop.com/courses/gaspdotnet Guerrilla .NET, 8 Dec 2003, in Los Angeles http://www.develop.com/courses/gdotnet View archives and manage your subscription(s) at http://discuss.develop.com
