|
Hi,
I think this article will help me solve a flickering issue i have in a VB.Net app. Im not sure if its that ive been working on this for 2 days without sleep but my brains are mush at the moment and i cant seem to get this to work.
Ive created a class lib and have referenced it in my application but i cant figure out how to wrap the form and use this class in VB.Net.
|
|
|
|
|
Great API. I really appreciate it.
After integrating it into a ton of stuff I'm using, I realized that the opacity changes won't occur if Form.ShowInTaskbar = false. I'm sure there is a fairly simple work around for this, but I'm not sure where to look.
Any pointers?
|
|
|
|
|
Thanks, Glad you like it.
As per your problem. Its not that it doesn't work with a window that has ShowInTaskbar set to false. The problem lies in that when you change the "ShowInTaskbar" property on a form windows destroys that form and creates a new one remembering the state of objects on that form. I have no idea why or exactly how it works. But your window's handle changes when you change that property. And this, the setlayeredwindow api no longer has a connection to you form.
The simple solution to this is to remember to always create the DDFormFader object AFTER you set the ShowInTaskBar property. or if you must for some reason Change this property multiple times during the life of your form. you must create a new DDFormFader object passing the new form handle to it.
Sorry for that inconvenience but it is out of my hands and has something to do with the way Windows handles that property. Simple to work around though.
thanks,
Rickey Ward
(DiamondDrake)
|
|
|
|
|
Sory for my bad english. Very good job. How about child forms? Property Opaque don`t work if TopLevel set false.
|
|
|
|
|
If you mean using MDI, then no. the Windows Layered API doesn't support transparent MDI child forms.
But it will work on any top level form, so if you need such a thing, you can create a form and use an event to have it keep position with the main form as if it were a child.
|
|
|
|
|
Although some may argue a few of the finer points, your work here - research, solution and follow-on article - is exemplary. More often than not, general developers look towards simpler solutions in order to build applications more rapidly, and often we are (I am including myself in this group) often devoid of the initiative it takes to look at issues at a very deep level.
I for one get frustrated at why things work the way they do sometimes, but do not have the time to dig into the deep unknown to resolve them. (In other words, I tend to find acceptable work arounds and/or oter solutions and continue on...)
As to the one who commented you don't know what you're talking about - I could not disagree more. There is sound logic in your reasoning - maybe not perfect, but sound. If nothing else, I actually learned quite a bit from reading both the article and other peoples responses. You get a 5 from me.
|
|
|
|
|
Thanks for the kind comment. A lot of time when into this.
|
|
|
|
|
Hi,
I think re-titling your article as "Use the Layered Windows API for Setting Opacity and Fading Forms" would be better since the case of flicker you mention is really quite a rare thing.
In fact, I've done several applications where I had a slider so the end-user could set the opacity of a "secondary" form on the fly, and I have never seen flicker as you describe ... honestly, though, I'm not sure if I ever let the end-user make it completely transparent ... why would I ?
The comment by the other commenter on your article noted :
"It seems that the behavior of transparent colors changes when a window's opacity is set to something other than solid. I would guess such change happens for exactly the same reason as the flicker. Would I be correct in guessing that the changing transparent-color behavior would also be solved with the techniques illustrated here?"
And that's interesting; I think if you can give a clear-cut example, not speculation, of that happening, and clear-cut proof that explicitly using the API fixes that (compared to using 'Opacity), that would be very valuable.
You might also benefit from reading Jeff Anderson's recently updated great article on a very complex use of WS_EX_LAYERED and transparency[^], and the very active discussion of transparency issues there.
I look forward to your continuing to develop the article.
thanks, Bill
"Many : not conversant with mathematical studies, imagine that because it [the Analytical Engine] is to give results in numerical notation, its processes must consequently be arithmetical, numerical, rather than algebraical and analytical. This is an error. The engine can arrange and combine numerical quantities as if they were letters or any other general symbols; and it fact it might bring out its results in algebraical notation, were provisions made accordingly." Ada, Countess Lovelace, 1844
|
|
|
|
|
Thanks for the comment,
I have read that article previously and I have done extensive research on WS_EX_LAYERED and the layered windows API. Jeff Anderson's article refers to the "other side" of WS_EX_LAYERED. there are 2 uses, one is to updateLayered window where traditional paint events no longer update the form (that is what his article discusses) my article refers to the simpler use of setLayeredWindowAttributes. They both use the same technology developed by windows but the system I choose still allows the paint event of the form to update the graphics object.
My class and code are identical to the way the forms opacity property updates the form's actual opacity. This article is an attempt to show how the form's opacity is actually modified and that there is more control inherited by the system that the forms interface hides for the sake of simplicity.
the flicker I describe is most seen on winXP with a typical home computer. This flicker most often occurs at the point where the .net framework makes the call to setWindowLong and updates the forms alpha for the first time, the form will flush black. it happens less often on multiprocessor machines regardless of video card, as I have tested it, I can reproduce it in a screen cap video if you need evidence. I don't see it as rare because I am still using a single processor machine. my Desktop with 2 GB of ram, 3.66 ghz processor and 256mb 400mhz gpu video-card produces the flicker evertytime. and so does my 1.86X2 ghz laptop with 2 gigs of ram running vista 32 bit home premium. I tested it on a dell demention 2400, and an HP pavillion tx100 and the flicker is there everytime. when setting the opacity from 1 to anything else the flicker always occurs.
|
|
|
|
|
Hi DiamondDrake,
A most thoughtful, and informative reply, thanks. The fact I didn't see the effect you mention on an XP single-core machine should not limit my appreciating your obviously extensive experience with it.
I think if you "fold in" the comments about the two scenarios for using WS_EX_LAYERED decribed in your response to my query, the article will be even better.
I have upgraded my vote to a #5
best, Bill
"Many : not conversant with mathematical studies, imagine that because it [the Analytical Engine] is to give results in numerical notation, its processes must consequently be arithmetical, numerical, rather than algebraical and analytical. This is an error. The engine can arrange and combine numerical quantities as if they were letters or any other general symbols; and it fact it might bring out its results in algebraical notation, were provisions made accordingly." Ada, Countess Lovelace, 1844
|
|
|
|
|
Just wanted to piggy bag this thread and say that I also had the flicker issue until I used your class. Thank you very much for your time and effort to develop and share this.
Tom
|
|
|
|
|
I've found that the quirk shows when the value of the Opacity property is set to 1.0, so the issue can be avoided by ensuring this value ranges from 0.0 to 0.99, for example. This way there is no need for interop. And the good news is that this also keeps the window a "layered" one, whatever that means. Am I wrong?
modified 21-Nov-20 21:01pm.
|
|
|
|
|
That is the typical workaround for simplicity's sake only. It is important to understand that the Opacity property uses the same methods that I use in my class. the Opacity Property of a form is a wrapper for the same interlop that I use. Only the true range of control is a byte value (0-255) so using the opacity property you loose that range of control. using a HACK-n-SLASH lazy code method like avoiding a true opaque setting by using .99 or 252 as it is actually sent to the windows API Isn't good code practice.
This article is about understand how ALL windows form opacity works. There is only one way to do it regardless of how it appears to the programmer, via a property or class or Interlop methods, Windows does it native through windows messages. I am not sharing a silly workaround effort. But a well implemented, simple to use class that exposes the true system behind how form opacity really works.
but technically you are correct, if you never set the value of the form opacity value to 1 then the form is never fully opaque, and thus the call from the .net forms.dll telling the windows layered api to cancel is never made. So the window does stay Layered. (the interlop still happens when you use the opacity property you just don't see it, just as my class keeps your from seeing it unless you open the class file)
also a window being "layered" refers to the setting that tells windows to draw the window by blending the window's pixels with the pixels of screen data behind it via a byte alpha blend setting. (simply put a layered window is draw with a solid alpha channel where a normal window has no alpha channel data)
|
|
|
|
|
Message Closed
modified 21-Nov-20 21:01pm.
|
|
|
|
|
This time around you are more clear, but what I insist is this, the framework makes calls using the same method that I do. The framework is just a set of compiled library. it is no different if you compiled my class in a library and shipped it with the application. Its the same thing!!!
I have thoroughly investigated this. I decompiled the SYSTEM.WIDNOWS.FORMS.dll forms class and here is the call that setting the opacity property reflects STRAIGHT out of the framwork
//Here is the frameworks form class's opacity property where you can clearly see that it makes the call to setwindowlong
[System.Windows.Forms.SRDescription("FormOpacityDescr"), DefaultValue((double) 1.0), TypeConverter(typeof(OpacityConverter)), System.Windows.Forms.SRCategory("CatWindowStyle")]
public double Opacity
{
get
{
object obj2 = base.Properties.GetObject(PropOpacity);
if (obj2 != null)
{
return Convert.ToDouble(obj2, CultureInfo.InvariantCulture);
}
return 1.0;
}
set
{
if (this.IsRestrictedWindow)
{
value = Math.Max(value, 0.5);
}
if (value > 1.0)
{
value = 1.0;
}
else if (value < 0.0)
{
value = 0.0;
}
base.Properties.SetObject(PropOpacity, value);
bool flag = this.formState[FormStateLayered] != 0;
if ((this.OpacityAsByte < 0xff) && OSFeature.Feature.IsPresent(OSFeature.LayeredWindows))
{
this.AllowTransparency = true;
if (this.formState[FormStateLayered] != 1)
{
this.formState[FormStateLayered] = 1;
if (!flag)
{
base.UpdateStyles();
}
}
}
else
{
this.formState[FormStateLayered] = (this.TransparencyKey != Color.Empty) ? 1 : 0;
if (flag != (this.formState[FormStateLayered] != 0))
{
int windowLong = (int) ((long) System.Windows.Forms.UnsafeNativeMethods.GetWindowLong(new HandleRef(this, base.Handle), -20));
System.Windows.Forms.CreateParams createParams = this.CreateParams;
if (windowLong != createParams.ExStyle)
{
System.Windows.Forms.UnsafeNativeMethods.SetWindowLong(new HandleRef(this, base.Handle), -20, new HandleRef(null, (IntPtr) createParams.ExStyle));
}
}
}
this.UpdateLayered();
}
}
//here is the method from the forms class that updates the SetLayeredWindowAttributes just as I do!
private void UpdateLayered()
{
if (((this.formState[FormStateLayered] != 0) && base.IsHandleCreated) && (this.TopLevel && OSFeature.Feature.IsPresent(OSFeature.LayeredWindows)))
{
bool flag;
Color transparencyKey = this.TransparencyKey;
if (transparencyKey.IsEmpty)
{
flag = System.Windows.Forms.UnsafeNativeMethods.SetLayeredWindowAttributes(new HandleRef(this, base.Handle), 0, this.OpacityAsByte, 2);
}
else if (this.OpacityAsByte == 0xff)
{
flag = System.Windows.Forms.UnsafeNativeMethods.SetLayeredWindowAttributes(new HandleRef(this, base.Handle), ColorTranslator.ToWin32(transparencyKey), 0, 1);
}
else
{
flag = System.Windows.Forms.UnsafeNativeMethods.SetLayeredWindowAttributes(new HandleRef(this, base.Handle), ColorTranslator.ToWin32(transparencyKey), this.OpacityAsByte, 3);
}
if (!flag)
{
throw new Win32Exception();
}
}
}
and here is some excerpts the unsafenativemethod class strait from the forms.dll
public static IntPtr SetWindowLong(HandleRef hWnd, int nIndex, HandleRef dwNewLong)
{
if (IntPtr.Size == 4)
{
return SetWindowLongPtr32(hWnd, nIndex, dwNewLong);
}
return SetWindowLongPtr64(hWnd, nIndex, dwNewLong);
}
public static IntPtr SetWindowLong(HandleRef hWnd, int nIndex, System.Windows.Forms.NativeMethods.WndProc wndproc)
{
if (IntPtr.Size == 4)
{
return SetWindowLongPtr32(hWnd, nIndex, wndproc);
}
return SetWindowLongPtr64(hWnd, nIndex, wndproc);
}
[DllImport("user32.dll", EntryPoint="SetWindowLong", CharSet=CharSet.Auto)]
public static extern IntPtr SetWindowLongPtr32(HandleRef hWnd, int nIndex, HandleRef dwNewLong);
[DllImport("user32.dll", EntryPoint="SetWindowLong", CharSet=CharSet.Auto)]
public static extern IntPtr SetWindowLongPtr32(HandleRef hWnd, int nIndex, System.Windows.Forms.NativeMethods.WndProc wndproc);
[DllImport("user32.dll", EntryPoint="SetWindowLongPtr", CharSet=CharSet.Auto)]
public static extern IntPtr SetWindowLongPtr64(HandleRef hWnd, int nIndex, HandleRef dwNewLong);
[DllImport("user32.dll", EntryPoint="SetWindowLongPtr", CharSet=CharSet.Auto)]
public static extern IntPtr SetWindowLongPtr64(HandleRef hWnd, int nIndex, System.Windows.Forms.NativeMethods.WndProc wndproc);
[DllImport("user32.dll", CharSet=CharSet.Auto, ExactSpelling=true)]
[DllImport("user32.dll", CharSet=CharSet.Auto, SetLastError=true, ExactSpelling=true)]
public static extern bool SetLayeredWindowAttributes(HandleRef hwnd, int crKey, byte bAlpha, int dwFlags);
the unsagenativemethods class of the FORMS.DLL library used to construct forms by the .netframework as over 800 lines of interlop.
It doesn't matter what library you call it from if you reference it in a project its being interloped. I don't at all see your point. Unless you are saying that you don't like to do it because you don't understand it. or you don't like to do it just because you don't like to.
there is only one way to set the opacity of a window in the MS WINDOWS OS. regardless if the code is hidden in a library or not.
|
|
|
|
|
Message Closed
modified 21-Nov-20 21:01pm.
|
|
|
|
|
Honestly, I don't feel that portability to a different operating system applies here. My article addresses the layered windows api. that doesn't exist outside of MS Windows.
I think it is really interesting that a compatible platform independent framework concept has been developed. But I also think its kinda a JIP to microsoft, the .net framework is the best thing they have come up with in years. and to have that concept taken and reimplemented right out from under them kinda says they have all the idea and none of the credit.
also, this article applies to windows programmers, and the troubles with opacity that it can face, the tags on this article are C#, Windows, .NET (.NET 3.5), Win32. non of them are MONO 2.4
I feel that a good application that spans across different platforms should contain classes that represent each feature with similar implementation but background code that is tailored to the best performance for that particular operating system. In that case, a widget style app written in C# for windows should use a system similar to the one I implemented and a C# application written for a MONO distribution should use a standard opacity property system.
If the monoframework had a monocompatibility flag, I could easily write my class to use and if(monoframework_compatible) system and have it work great on both. Is there something like that? cause then we could both be happy
|
|
|
|
|
Diamonddrake wrote: Honestly, I don't feel that portability to a different operating system applies here. My article addresses the layered windows api. that doesn't exist outside of MS Windows.
...
Diamonddrake wrote: I think it is really interesting that a compatible platform independent framework concept has been developed. But I also think its kinda a JIP to microsoft, the .net framework is the best thing they have come up with in years. and to have that concept taken and reimplemented right out from under them kinda says they have all the idea and none of the credit.
You really have no idea do you? That entire paragraph you have written is complete rubbish.
http://www.mono-project.com
Open your mind.
Diamonddrake wrote: I feel that a good application that spans across different platforms should contain classes that represent each feature with similar implementation but background code that is tailored to the best performance for that particular operating system. In that case, a widget style app written in C# for windows should use a system similar to the one I implemented and a C# application written for a MONO distribution should use a standard opacity property system.
You are *so* wrong. That is exactly what the .NET framework is meant to solve... NOT having to write multiple classes to port your application to a multitude of operating systems.
Diamonddrake wrote: If the monoframework had a monocompatibility flag, I could easily write my class to use and if(monoframework_compatible) system and have it work great on both. Is there something like that? cause then we could both be happy Smile
There are ways to detect if you're running on the Mono runtime engine... but this is bad and something you should never do. Your application shouldn't behave differently on different frameworks - that will confuse your end-users. You should make all effort to implement your application with the minimum of reliance on any OS feature.
-- Tom Spink
|
|
|
|
|
Tom Spink wrote: You are *so* wrong. That is exactly what the .NET framework is meant to solve... NOT having to write multiple classes to port your application to a multitude of operating systems.
No sir, you are entirely wrong, the .net framework was written by Microsoft so that developers using the 3 different MICROSOFT WINDOWS DOT NET PROGRAMMING LANGUAGES running on MS WINDOWS could write applications and libraries that cooperate with each other, seamlessly as if they were the same programming language.
It includes sets of useful libraries that make application develop FASTER. by each program not having to worry about how to save an image as a jpeg, or url encode a string. Its an amazing asset to any programmer. but IT WAS NEVER INTENDED TO ALLOW APPLICATIONS TO SPAN OPERATING SYSTEMS. that whole thing is just something the mono project people did with it.
MONO is just a platform independent copy of what Microsoft come up with. They may have expanded it a bit. but regardless. It was micrsoft's idea, they did it first, they developed VB.net and C#. C# is a hybrid of C++ and VB. both Microsoft languages.
MONO is a neat idea. but all operating systems work differently. A program should be tailored to its operating system. That's my opinion as a developer. No open source framework that allows applications to run on multiple operating systems is going to change that to me.
Here is an example. using my article. Say you are developing a program that is a windows application. the MS dot net framework makes a call to setWindowLong to change your form to a layered window in order to alpha blend your form. to get more power for this, you do this manually, because the framework exposes a minimalistic methodology. now, a particular Linux distribution may Nativity support alpha blending, so it its always on, you just update the forms opacity value. the framwork would handle this differently depending on which version of the framework your application used, the windows, or Linux versions of MONO. Problem is. since you had to do it the framework's way. now you are LIMITED to the framework's methodology. Even though its a program that would really target windows, and you want to do something on windows related, just so you can hope it would work on linux too, you bail on what could be a great windows related asset.
what limits a program from running on different applications is how it communicates with hardware and how its code communicates with the environment that the operating system creates for it. the CLR is all that is really needed to be platform independent. its the CLR that in realtime converts the Intermediate language that managed applications compile to into something really understandable by the operating system. the framework around it just to make programming easier and faster.
My article isn't about easy. Is about knowing how WINDOWS WORKS, and how to take advantage of its features.
If you use MONO, don't bother reading my articles, Its not tailored to you.
|
|
|
|
|
Diamonddrake wrote: No sir, you are entirely wrong, the .net framework was written by Microsoft so that developers using the 3 different MICROSOFT WINDOWS DOT NET PROGRAMMING LANGUAGES running on MS WINDOWS could write applications and libraries that cooperate with each other, seamlessly as if they were the same programming language.
The CLR is Microsofts Implementation of the CLI - which they developed as an open specification:
http://en.wikipedia.org/wiki/Common_Language_Infrastructure
Diamonddrake wrote: It includes sets of useful libraries that make application develop FASTER. by each program not having to worry about how to save an image as a jpeg, or url encode a string. Its an amazing asset to any programmer. but IT WAS NEVER INTENDED TO ALLOW APPLICATIONS TO SPAN OPERATING SYSTEMS. that whole thing is just something the mono project people did with it.
...? Yes it *WAS*! That's exactly what is was intended to do. Albeit, Microsoft's *implementation* spans the Windows generation of operating systems, and is restricted to their line of processors, Mono's implementation spans Windows, Linux and OSX and a multitude of processor architectures.
Read the first paragraph in that Wikipedia article VERY CAREFULLY:
The specification defines an environment that allows multiple high-level languages to be used on different computer platforms without being rewritten for specific architectures.
Remember, here we're talking about the runtime, not the framework. The runtime is what translates the IL to machine code.
Diamonddrake wrote: MONO is just a platform independent copy of what Microsoft come up with. They may have expanded it a bit. but regardless. It was micrsoft's idea, they did it first, they developed VB.net and C#. C# is a hybrid of C++ and VB. both Microsoft languages.
C++ isn't a Microsoft language. C# is another ECMA standard, again implemented by both Microsoft and Mono.
Mono is an *IMPLEMENTATION* of the *CLI SPECIFICATION*, just like .NET is an implementation of the same specification.
Diamonddrake wrote: MONO is a neat idea. but all operating systems work differently. A program should be tailored to its operating system. That's my opinion as a developer. No open source framework that allows applications to run on multiple operating systems is going to change that to me.
Then you are surely *VERY* narrow minded.
Diamonddrake wrote: Here is an example. using my article. Say you are developing a program that is a windows application. the MS dot net framework makes a call to setWindowLong to change your form to a layered window in order to alpha blend your form. to get more power for this, you do this manually, because the framework exposes a minimalistic methodology. now, a particular Linux distribution may Nativity support alpha blending, so it its always on, you just update the forms opacity value. the framwork would handle this differently depending on which version of the framework your application used, the windows, or Linux versions of MONO. Problem is. since you had to do it the framework's way. now you are LIMITED to the framework's methodology. Even though its a program that would really target windows, and you want to do something on windows related, just so you can hope it would work on linux too, you bail on what could be a great windows related asset.
I'm not denying that... in fact, I agree with you that some things are *not* implemented by the framework, which are useful features. And indeed, those things should obviously (and can only) be written to work on that platform.
Diamonddrake wrote: what limits a program from running on different applications is how it communicates with hardware and how its code communicates with the environment that the operating system creates for it. the CLR is all that is really needed to be platform independent. its the CLR that in realtime converts the Intermediate language that managed applications compile to into something really understandable by the operating system. the framework around it just to make programming easier and faster.
The CLR doesn't compile the IL into "something really understandable by the operating system". It compiles it into native machine code. The operating system doesn't understand that - it just dispatches it to a CPU.
Diamonddrake wrote: My article isn't about easy. Is about knowing how WINDOWS WORKS, and how to take advantage of its features.
Again, if you read carefully, I'm not slating your article. I'm really not. I'm trying to open your mind. You made some bad comments about Mono, which are very wrong, and I'm trying to set you right.
Diamonddrake wrote: If you use MONO, don't bother reading my articles, Its not tailored to you.
I love reading any articles, even ones about Windows - even though I'm a Linux user.
-- Tom Spink.
|
|
|
|
|
I get your point. But if you read the wiki on C# C# wikki you will see that C# is part of the ECMA standard but was created originally by Microsoft. And so was .net, prior to being added to the ECMA standard. This includes the CLI concept as it was orignially devleoped by mirosoft CLI wikki
Microsoft developed it all, in fact. Microsoft assisted mono's project extensivly with the Shared Source Common Language Infrastructure project where due to its licensing is not allowed in commercial products, but is a stripped down version of the source code of the .net framework CLI base.
I have an open mind, and Linux is pretty cool, I don't knock it. I in fact have a laptop with a ubuntu partition. I just really like windows XP.
and as a MS.net developer, I target the MS .net framework.
and yeah cpp is not technically for windows, but most current cpp compilers compile to win32 applications.
|
|
|
|
|
Diamonddrake wrote: I get your point. But if you read the wiki on C# C# wikki you will see that C# is part of the ECMA standard but was created originally by Microsoft. And so was .net, prior to being added to the ECMA standard. This includes the CLI concept as it was orignially devleoped by mirosoft CLI wikki
But that's my point. I'm not arguing Microsoft originally created it... I'm really not! I'm just saying that an open-source implementation is not a bad thing. It's a very good thing...
Microsoft did not create the HTTP protocol, yet they have created an implementation of that protocol in web browers and servers alike. The same goes for NNTP, POP3, IMAP, etc. The alternative implementation of the CLI is the same thing.
Diamonddrake wrote: Microsoft developed it all, in fact. Microsoft assisted mono's project extensivly with the Shared Source Common Language Infrastructure project where due to its licensing is not allowed in commercial products, but is a stripped down version of the source code of the .net framework CLI base.
Actually, if you've ever worked on Rotor, i.e. Microsofts "open" implementation of the CLR, then you can't contribute to the Mono project. So Rotor, in fact, doesn't help Mono at all.
Diamonddrake wrote: I have an open mind, and Linux is pretty cool, I don't knock it. I in fact have a laptop with a ubuntu partition. I just really like windows XP.
and as a MS.net developer, I target the MS .net framework.
That's good to know. I myself use Ubuntu exclusively, and I'm not ashamed to admit I have Windows Vista in a virtual machine to test my creations on.
However, as you've just said, you target the MS .NET framework - and targetting the framework means not using P/Invoke calls - that's targetting the operating system. So, if you write your application exclusively with the .NET framework in mind, it will already run without problems (generally) on Mono.
I'm currently the project leader for a group of developers writing a bespoke enterprise software product. It's a very complicated product... it's distributed, makes heavy use of reflection for the back-end database framework, has a very rich front-end. And it's written with only framework classes.
It works perfectly on Linux and Windows - to be honest, I haven't tested it on a Mac. And this makes me happy, because now I can reach much more people than if I was selfis, and wrote it only with Windows in mind.
-- Tom Spink
|
|
|
|
|
When I said I target the MS Framework, I mean I write Windows Managed applications.
but anyhow. I'm not currently concerned with writing applications for non windows OSes.
|
|
|
|
|
It seems that the behavior of transparent colors changes when a window's opacity is set to something other than solid. I would guess such change happens for exactly the same reason as the flicker. Would I be correct in guessing that the changing transparent-color behavior would also be solved with the techniques illustrated here?
|
|
|
|
|
Indeed! I do believe that is caused by the limited control the Opacity property gives you. actually the Layered Windows Api has a flag for using a transparent colors. LWA_COLORKEY = 0x1 Although I have yet to play with it and learn its full functionality.
More information on this may be released in further articles. possible a form fader part 2. This class and article was originally written to help demonstrate techniques of opacity while creating widget type applications in C#, to help out a poster on DaniWeb.com IT forum.
|
|
|
|
|