[RESOLVED] Change form opacity without changing control opactiy

I need to be able to change my form's opacity without changing the opacity of the components.

I really only need to do this on one form in my entire app, so this is getting a little frustrating :p

I've been researching for about half an hour now, trying to figure out if it's possible, but I'm coming up short.

I've seen some WPF examples and if it really comes to that, I'm more than willing to change the app from a WinForms app to a WPF app. I've made a WPF app before, so I'm familiar with it. But, I don't want to have to remake my entire project for this one form.

On that note, does anyone know if I can make a WPF form how I need it and just import it into a WinForm app? It doesn't seem possible, but it's better to ask than not. I'll look into this more.

Any information is appreciated.

It's simply not possible in WinForms. A partially transparent form cannot have opaque controls. Some people might recommend using two forms, one fully transparent with opaque controls over another partially transparent, but I won't go into that.

As for interop between WinForms and WPF, you can't mix and match Forms and Windows. You can place WPF content on a Form or WinForms content on a Window, but you need to use a special hosting control in each case.

Quote:

---

Originally Posted by jmcilhinney

It's simply not possible in WinForms. A partially transparent form cannot have opaque controls. Some people might recommend using two forms, one fully transparent with opaque controls over another partially transparent, but I won't go into that.

As for interop between WinForms and WPF, you can't mix and match Forms and Windows. You can place WPF content on a Form or WinForms content on a Window, but you need to use a special hosting control in each case.

---

I actually thought about using two forms, but I knew that would not be best in the end :p

I was trying my best to stick with WinForms, but it looks like I'll need to convert the whole project.

Luckily, it won't be a hard process, just a time consuming one.

Thanks

It seems I am fated to disagreeing with JMC and others about this: two forms work perfectly well. WPF offers more, of course, but this can be handy if you want to stay with WinForms for the moment.

Here's a simple demo using a default Form1 (the "fade" form) and Form2 (the "controls" form).

Code:

---

Public Class Form1

Private Sub Form1_Load(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles MyBase.Load
        With Form2
                AddHandler .Load, AddressOf form2_Load
                .FormBorderStyle = Windows.Forms.FormBorderStyle.None
                .ShowInTaskbar = False
                .Show(Me)
        End With
End Sub

Private Sub form2_Load(ByVal sender As Object, ByVal e As EventArgs)
        With Form2
                Dim rgn = New Region(Rectangle.Empty)
                For Each ctrl As Control In .Controls
                        rgn.Union(ctrl.Bounds)
                Next
                .Region = rgn
        End With
End Sub

Private Sub Form1_SizeOrLocationChanged(ByVal sender As Object, ByVal e As System.EventArgs) Handles Me.SizeChanged, Me.Move, Me.Load
        Dim p As Point = Me.PointToClient(Me.Location)
        With Form2 'couple forms in XY direction
                .Left = Me.Left - p.X
                .Top = Me.Top - p.Y
                .Size = Me.ClientSize
        End With
End Sub

End Class

---

Lay out the controls on Form2. For demo purposes, include a Trackbar and couple its value to Form2.Owner.Opacity.

BB

Quote:

---

Originally Posted by boops boops

It seems I am fated to disagreeing with JMC and others about this

---

I didn't say there was anything wrong with that approach. It really does feel like a hack but, if a hack is your only option to achieve your aim, a hack is what you have to implement. I just said that I wasn't going to go into it because I've never done it and I doubt that I ever will, so I don't know the details off the top of my head and wasn't all that interested in working them out.

If there's something wrong with it, I'd like to hear. As far as I can see it uses nothing but commonplace Windows Forms properties. If that's a "hack" then just about any solution to a problem is. BB

It's a hack because you're using something in a way that it was never intended to be used to do something that was never intended to be done. That sounds like the very definition of a hack. Again, I didn't say that that's a bad thing. It feels inelegant to me but that's not the measure of good and bad. Like I said, if that's what you have to do then that's what you have to do. If I needed that functionality and that was the only way to get it then I'd do it too. I'm unlikely to need that functionality though and, even if I do, I'll likely be well-versed with WPF by then. You don't have to use a hack with WPF because it was built with that sort of functionality in mind.

Just in case anyone's trying the code in post #4, I've edited it a bit. Some control sizes aren't set until the form is loaded. BB

Quote:

---

Originally Posted by jmcilhinney

It's a hack because you're using something in a way that it was never intended to be used to do something that was never intended to be done. That sounds like the very definition of a hack. Again, I didn't say that that's a bad thing. It feels inelegant to me but that's not the measure of good and bad. Like I said, if that's what you have to do then that's what you have to do. If I needed that functionality and that was the only way to get it then I'd do it too. I'm unlikely to need that functionality though and, even if I do, I'll likely be well-versed with WPF by then. You don't have to use a hack with WPF because it was built with that sort of functionality in mind.

---

Dude programming isnt about using things that have already been made. its about making your own new things. If it isnt meant to be done in the programming language all the better i say.

Quote:

---

Originally Posted by thefiscster

Dude programming isnt about using things that have already been made. its about making your own new things. If it isnt meant to be done in the programming language all the better i say.

---

A hack is a hack, whether you call me dude or not. Let me repeat yet again, I did not at any point say that it was bad and I did not at any point say that it shouldn't be done. In fact, I was the first person who brought up the possibility of using two forms. I had no specific information on doing so so I didn't go into it further. Thanks for your useful contribution none the less.

I've always felt the word "hack" had a very fluid definition.
Clearly, if I use code that bypasses some sort of security that type of hack is "bad".

If I find a creative(and quick) approach to solve a problem that might take a rewrite to fix otherwise, thats also a hack but not necessarily a bad thing, it might be the best solution based on time constraints.

And sometimes a hack is the ONLY solution, and in those case, its a thing of beauty.

Of course thats just my 2 cents on this, and anyone who's ever looked at my code samples, knows I'm nothing but a hack =)

Further reflecting on it, Dude is the same type of word....

Oh mah goodness, the term "HacK" has changed way to much. It no longer even means what it originally meant.

While trying not to fan the flames, it is a 'hack' with any connotation associated with it, either positive or negative.

The point, though, is while it may work, because (as JMC noted) it wasn't necessarily intended to work that way, it's possible under certain circumstances that it won't work, or work in a less than desirable way.

A professional programmers are aware (or, those who rely on producing a working program in their professional capacity) hacks can be quite dangerous things, and so should be consciously aware of the shortcomings of any code they may release.

Quote:

---

Originally Posted by SJWhiteley

While trying not to fan the flames, it is a 'hack' with any connotation associated with it, either positive or negative.

The point, though, is while it may work, because (as JMC noted) it wasn't necessarily intended to work that way, it's possible under certain circumstances that it won't work, or work in a less than desirable way.

A professional programmers are aware (or, those who rely on producing a working program in their professional capacity) hacks can be quite dangerous things, and so should be consciously aware of the shortcomings of any code they may release.

---

And the sky will fall on your heads...

Attachment 83929
BB;)

Is this post serious? Off topic? Comic? A troll? Choose your own adventure!

I don't even know what that cartoon is trying to state. WPF and the MVPs are going to devour a bunch of programming languages? That makes no sense. And how is VB6 still alive? If anything it should be a horse-shaped grease spot on the ground covered by terrified mice beating it with sticks. C# should be President Obama skateboarding over a helicopter. VB .NET should be Rupert Murdoch ramping a limo across the Grand Canyon. C++ should be an aircraft carrier with kitchen sinks for anchors that's levitating via millions of balloons. The Express Editions should be... an analogy? WPF and the MVPs should be... uhhh.... mankind's mortality? I dunno, I never was good at analysis.

Oh yeah, there was a thread here!

I'm more interested in why you think this is a good idea. Let's ignore that it's a hack for a moment, though I can't resist coming back to that one.

It's not a standard UI used by Windows applications. Sure, doing something unique makes you stand out as an individual, but it also puts you in the same league as the zillions of "media players" whose only two features are "plays media" and "has infinity skins". 99% of those skins do clever things like make all the buttons indistinguishable. If you ever wanted to solve a Rubik's Cube before killing the volume on your Bieber tunes, they can hook you up.

I'm masking my hatred with humor there. The standard Windows UI paradigms have some 30-40 years of muscle memory behind them. People know how toolbars work because they've always worked the same way. People know the floppy disk icon means "save" even though millions have never seen a real floppy disk because that icon has always meant "save". Heck, most "print" icons look like ancient dot matrix printers. Ribbons only work because they look like toolbars and menus, which are things people already know how to use.

"But Sitten, people are doing different things on iPhone and getting praised!" Yes. That's like saying it's OK for you to light your house on fire because one time you went camping and told stories around a fire and it was fun. The iPhone's got a different OS, its screen is very tiny, and it can recognize at least 4 fingers at a time. It's been around for 4 or 5 years, so people are still experimenting with what does and doesn't work. Windows has big screens, only supports one cursor at a time, and has at least 20 years of usability research backing up its UX guidelines.

Experimentation is not without risk. Some applications like Tweetie (now the official Twitter client), came up with cool ideas (pull to refresh) that everyone scrambled to copy. Some applications like Color have a really cool premise but launched with a UI so experimental it confused people. Color hasn't recovered yet, and probably won't ever break even on the $40m of capital it raised. Do you want to take such a risk?

I think OP should make a case. Why do you want a partially transparent form with fully opaque controls on it? Maybe you have a good reason. I'll admit it if you do. But right now you're not asking us to help you solve a problem, you're asking us to help you with a solution to a problem. Sometimes the solution's wrong. Sometimes you don't understand the problem. Sometimes there's someone that comes up with a completely different solution that's better than the original. Either way, there's no risk in saying, "This is what I want to do, I'm trying to solve it with a transparent form with opaque controls."

Now, let's talk about hacks. I've already stated an opinion about deviation from standards. I think your cartoon was accusing us of being Chicken Little, but it's a really bad analogy.

Chicken Little had an acorn fall on her head. She decided that Occam's Razor didn't apply, and what hit her on the head must have been the sky. She leaves to tell the King of the impending danger. Along the way, she gathers quite the posse of animals that were probably teased relentlessly in school for their names. Then they meet Foxy Loxy, who realizes that the sky is *not* falling but that dinner is sitting in front of him. He lures them all to his cave where they are promptly devoured by a predator who knows nothing about moderation.

OP had a problem, it's ill-defined. You decided something was the solution. When someone warned you that the solution has some pitfalls, you rolled your eyes and said "It works, good enough for me!" People chimed in again pointing out that "it works" is a horrible method of measuring quality, and now you're accusing your would-be mentors of being naysayers.

You're also forgetting one thing about Chicken Little: she was wrong. The sky wasn't falling, an acorn fell on her head. This mistake was fatal. We're the people along the road to Foxy Loxy's lair (would we be Skuman Human?) that are screaming "HE'S A FOX! HE'S GOING TO EAT YOU! FOXES CONSUME MASS QUANTITIES OF BIRDS! LOOK, HE HAS FEATHERS STICKING OUT OF HIS MOUTH!" Well, the other people at least. I'm not going to scream at you. I've got a deal with Foxy Loxy and I get the drumsticks.

Let's list a few other things that "work" but aren't the best approach:

• Resolving conflicts with murder.
• Getting in arguments on the internet.
• Lulling a baby to sleep with a shot of vodka in their bottle.
• Masturbating with sandpaper.
• Stabilizing a country with a history of ethnic and racial tensions by stationing a military with unclear goals and indescriminate targeting algorithms in their homeland.
• Being a menace to South Central while drinking your juice in the hood.

Seriously. Can you come up with an argument to support the complexity of the two-form approach other than "it works"? If you can, I promise people will get off your back. But I've never had a need for and never found an application that uses the use case you're trying to implement. I've used a lot of programs, and even the ones with bad UI don't do this. That makes me nervous about recommending it.

RE: using code as it's designed rather than "anything goes". Just go read Raymond Chen's The Old New Thing blog. He worked (maybe still works) on Microsoft's app compatibility team and you would not believe the hoops they've had to jump to thanks to "clever" programmers that work for Big Companies that think outside the box enough to find undocumented ways to use the Windows API. Most of the time there's a really simple solution to what they want. Sometimes what they're trying to do is downright harmful. But in almost all cases, everyone who uses the Windows API has had to go through some misery in the form of weirdo bugs that can't be fixed thanks to these "forward thinkers" who aren't afraid to stretch the boundaries.

When you use an API in a way it wasn't designed, you're doing things that the designer didn't expect. That means there could be errors that aren't handled properly and mysterious, unexplained behaviors. Or it could work perfectly. But if you had a choice between the stairs to the top floor or riding an elevator that's on fire, why would you risk doom?

Hi Sitten, I tried to quote your message with interspersed comments but it started getting far too long. My cartoon was a flippant response to SJWhiteley's gloom-laden warnings. I didn't know the full Chicken Little saga. but the implied threats sounded more like sky than like acorns. Perhaps a bit of resentment about the lack of a decent free designer for WPF crept in there too. However, if you want to interpret it as an allegory of Microsoft's strategy towards development languages you are welcome:D.

I didn't post the code in #4 as a "good idea" but as an optional solution in WinForms to the question posed by the OP. Whether or not he is right to want multiple transparency is not something I considered.

I can understand the concern about chaotic design spreading to business systems, but that doesn't mean there are no valid uses for nonstandardized design on the desktop outside the corporate envrironment. Besides entertainment and games, consider educational games for children for example. If I want to make a form shaped like a clown with a red nose that beeps when you click it, why shouldn't I? It's possible for people to make overcomplicated or plain ugly designs, but I don't think it's the task of this forum to police that. Let the user decide.

Two other objections were raised to the code I posted. Firstly, it is said to make an "unintended" use of Windows Forms. I hope this doesn't mean that Forms can't be used for purely graphic purposes: they have several properties dedicated to graphic diversity such as TransparencyKey or Opacity, so I suppose we are allowed to use them. I haven't seen any explicit statements e.g. in msdn of what are and are not "intended" uses of Forms. Is this guidance available somewhere?

Secondly, there's the question of technical reliability. The code works mainly by setting a few public properties on a form, and coupling two forms together as a main form and a modeless dialog box. All of this functionality is documented in msdn. The code plays no obscure tricks with APIs or Reflection. It is so simple that I think most of the people on this forum could understand it at first sight. The argument seems to be that the method is described as a "hack" (for whatever reason) and that hacks can often be dangerous. In my view that is just faulty reasoning. I want to know what is dangerous about THIS code, without resorting to the dubious "hackiness" argument.

I hope you will understand that I am not trying to provoke an argument just for the sake of it. Whether I am wrong or right, I think there are some important points still to be clarified here.

BB

It looks like you completely missed the point, bb, and decided to go on the defensive because someone critiqued what you posted.

No one said it doesn't work, shouldn't be done, is even 'bad' code or that you are wrong.

Would you use a flat-head screwdriver on a cross-head screw? I'm sure we have all done that and the 'sky didn't fall', but that doesn't mean that we don't need cross-head screwdrivers and that using a flat- on a cross-head is a good idea.

Quote:

---

It's possible for people to make overcomplicated or plain ugly designs, but I don't think it's the task of this forum to police that. Let the user decide.

---

If I have no other context, I assume it is an application intended for distribution within a company or sale to customers, as that covers the vast majority of software that is created. Thus, if something's a bad idea in that context, I make my statement. If other context (such as a children's application) is provided I use that.

This is why I and so many others stress that a good question has as much information as possible. Occasionally I've decided the horrible UI choice was in fact the only way to accomplish the task, but only after a round of 20 questions that spanned over a week. If enough information is in the post to begin with, much time is saved.

It's especially important on this forum, which seems to value speed and copy/pastability more than some other forums I frequent that prefer gentle nudges. It's a bit of culture shock for me. But even in a copy/paste environment a bad OP can waste time. I've seen plenty of threads here that are like some kind of weird interview: "I need X. That's good, but it also needs to do Y. OK, but what if Z? Could you please make it do A as well?" That's why I don't post code until I'm certain I have enough context.

Quote:

---

I haven't seen any explicit statements e.g. in msdn of what are and are not "intended" uses of Forms. Is this guidance available somewhere?

---

This is a little too coy. First, I'll answer the question: I don't know. The golden book is the Windows User Experience Interaction Guidelines. They don't seem to say much about transparency, but do note there is an emphasis on using Aero Glass (which is a straightforward way to get a semitransparent window with opaque controls) as sparingly as possible.

Besides, there doesn't have to be a published document to tell you something's nonstandard. You can look around and tell. MS holds your hand through the common cases, like setting button text or resizing an image in a picture box. More advanced cases still have API to let you accomplish them, but might require more effort. For example, making a non-rectangular form using regions and a borderless form is somewhat challenging. If there's no interface to accomplish your goal *at all*, that's a sign that so few people have tried it that Microsoft did not see fit to provide you with the tools to do so. For example, there's no API at all for recognizing arbitrary touch gestures in any version of Windows before 7, because until that point Microsoft felt there wasn't enough demand to warrant the effort. I saw plenty of people with factory machines that crammed XP on a tiny touchscreen that would have loved it, but they had to make do with writing their own gesture support.

I understand that your code probably doesn't do anything technically wrong. I haven't looked it over. I don't really care to. My opinion is the approach is wrong because it's so non-standard you have to be clever to make it work. That raises a red flag, and I'd like to hear an explanation of why this UI is required before recommending your approach. Besides, Aero Glass is probably a better solution anyway; I had forgotten about it because it's quite agitating to get it working from .NET.

Quote:

---

Originally Posted by Sitten Spynne

If I have no other context, I assume it is an application intended for distribution within a company or sale to customers, as that covers the vast majority of software that is created. Thus, if something's a bad idea in that context, I make my statement. If other context (such as a children's application) is provided I use that.

---

I get the impression that the makeup of people who post to the forum is different. There seems to be a rather larger minority -- students, hobbyists and other oddballs -- who are not involved in production software, or not yet, or are in less conventional areas. Perhaps I notice them more because it's the main area I'm interested in.

Quote:

---

This is why I and so many others stress that a good question has as much information as possible. Occasionally I've decided the horrible UI choice was in fact the only way to accomplish the task, but only after a round of 20 questions that spanned over a week. If enough information is in the post to begin with, much time is saved.

It's especially important on this forum, which seems to value speed and copy/pastability more than some other forums I frequent that prefer gentle nudges. It's a bit of culture shock for me. But even in a copy/paste environment a bad OP can waste time. I've seen plenty of threads here that are like some kind of weird interview: "I need X. That's good, but it also needs to do Y. OK, but what if Z? Could you please make it do A as well?" That's why I don't post code until I'm certain I have enough context.


This is a little too coy. First, I'll answer the question: I don't know. The golden book is the Windows User Experience Interaction Guidelines. They don't seem to say much about transparency, but do note there is an emphasis on using Aero Glass (which is a straightforward way to get a semitransparent window with opaque controls) as sparingly as possible.

---

Thanks for the link to the guidelines, which are impressive. Although they are addressed to Vista/Win7 it looks like most of the advice is equally applicable to XP and o Windows applications in general.

Quote:

---

Besides, there doesn't have to be a published document to tell you something's nonstandard. You can look around and tell. MS holds your hand through the common cases, like setting button text or resizing an image in a picture box. More advanced cases still have API to let you accomplish them, but might require more effort. For example, making a non-rectangular form using regions and a borderless form is somewhat challenging.

---

They provided the TransparencyKey to make it easy. Regions have a few advantages but require more processing. Perhaps that matters on old systems.

Quote:

---

If there's no interface to accomplish your goal *at all*, that's a sign that so few people have tried it that Microsoft did not see fit to provide you with the tools to do so. For example, there's no API at all for recognizing arbitrary touch gestures in any version of Windows before 7, because until that point Microsoft felt there wasn't enough demand to warrant the effort. I saw plenty of people with factory machines that crammed XP on a tiny touchscreen that would have loved it, but they had to make do with writing their own gesture support.

I understand that your code probably doesn't do anything technically wrong. I haven't looked it over. I don't really care to. My opinion is the approach is wrong because it's so non-standard you have to be clever to make it work.

---

There is nothing difficult about it at all. Still, it's not common practice. I wonder why, considering all the queries we get on the forum about transparency. I suspect that people tried it but they didn't notice that the Owner argument was needed in Form.Show (Form2.Show(Me)), so their Z-stacking was unreliable. My experience is limited, but I never heard about the Owner/Owned relation until I ran across it in Intellisense and checked it in msdn. Yet it has been amply supported with form properties and methods since .Net 1, and it seems to solve a lot of problems.

Quote:

---

That raises a red flag, and I'd like to hear an explanation of why this UI is required before recommending your approach. Besides, Aero Glass is probably a better solution anyway; I had forgotten about it because it's quite agitating to get it working from .NET.

---

WPF clearly offers a more organized way to do it, but WPF isn't immune to people wanting to make awful designs. Besides, it's sometimes a hill to climb.

BB

Its been a long time since I enjoyed a thread as much as this one. Sitten should write a book, and I mean that, it is entertaining. JMC is the contributor that has helped me more than anyone here or in any forum so I dare not challenge his recomendations... though I dont think this is a Hack and I will leave it at that. Its just me. boops: dont take it personally, I see where you are comming from, I have seen the implementation of the second form and it looks like it does what it was designed to do, just not commonly used like that.

But what I think is more fun in this post is that Weirddemon (the one with the problem, remember?) has not checked it in over two months and here we are still in a tasty heated discussion about hacks and chickens.

Long Live the KING!