[Resolved]Rectangles

[vipkid]

ok, i know how to draw a rectangle and fill it but how do i make it visible over a WebBrowser control, also how would i make the FillRectangle 60% transparent? i have found no understandable results on google. could someone please help me figure this out?

Private Sub Button2_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles Button2.Click
Dim myGraphics As Graphics
Dim MyBrush As New SolidBrush(Color.FromArgb(128, 0, 0, 255))
myGraphics = Graphics.FromHwnd(TextBox1.Text)
myGraphics.FillRectangle(MyBrush, New Rectangle(0, 0, 100, 100))

End Sub

[jmcilhinney]

I don't think you're going to be able to do what you want. Generally speaking, to draw on a control you handle its Paint event and then do your GDI+ drawing there. I'm fairly sure that the WebBrowser control doesn't support that though. You could just stick a Panel over the top of the WebBrowser but then you can't make it transparent. If what you want is possible then I would expect it to require complex unmanaged code. Maybe it would be easier in WPF than in WinForms.

[boops boops]

Hi Vipkid,
You can use an ordinary form to show a partly transparent rectangle in front of the web browser. You need to set various properties of the form to make it work well. If the user can move/resize the form, code the forms Move and Resize events to keep them aligned; otherwise set the bounds in a similar way in the Load event. The following code goes on the form (Form1) which hosts the web browser (WebBrowser1):

Private WithEvents frm As New Form With _
    {.FormBorderStyle = Windows.Forms.FormBorderStyle.None, .Owner = Me, _
     .StartPosition = FormStartPosition.Manual, .Visible = False, _
     .ShowInTaskbar = False, .BackColor = Color.Gray, .Opacity = 0.6}
 
    Private Sub Button1_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles Button1.Click
        If frm.Visible Then
            frm.Hide()
        Else
            frm.Show(Me)
        End If
    End Sub
 
    Private Sub Form1_Move(ByVal sender As Object, ByVal e As System.EventArgs) Handles Me.Move, Me.Resize
        frm.Bounds = RectangleToScreen(WebBrowser1.Bounds)
    End Sub

You only need the WithEvents keyword if you want to do something with frm's events, for example the Click event.


@jmcilhinney. John, I never see anyone else recommending forms for solving this kind of transparency problem. Is there some good reason for not doing so?

BB

[jmcilhinney]

@jmcilhinney. John, I never see anyone else recommending forms for solving this kind of transparency problem. Is there some good reason for not doing so?

It's not really something I considered. It is a hack, and it may have issues under certain unforeseen circumstances, but sometimes a hack is the best option. If it works, it works.

[boops boops]

It's not really something I considered. It is a hack, and it may have issues under certain unforeseen circumstances, but sometimes a hack is the best option. If it works, it works.

I'm not sure what you mean by a "hack" here. What kind of issues do you have in mind? Really it's just a modeless dialog box without a dialog.

After playing around with it for a while I did find a small flaw. If the user manually resizes the main form to so small that the browser is invisible, a small square of frm can remain visible. The Move/Resize event can be improved to eliminate it:

Private Sub Form1_Move(ByVal sender As Object, ByVal e As System.EventArgs) Handles Me.Move, Me.Resize
        Dim r As Rectangle = Rectangle.Intersect(WebBrowser1.Bounds, Me.ClientRectangle)
        If r.Width <= frm.MinimumSize.Width OrElse r.Height <= frm.MinimumSize.Height Then
            frm.Hide()
        Else
            frm.Bounds = RectangleToScreen(r)
        End If
    End Sub

Does that count as a hack or as a refinement?

BB

[NickThissen]

I would definitely consider it a hack to have a partly transparent form act as if it is a drawing on the webbrowser. The point is that something is acting like it is something else. But hacks are not always bad, and I don't see any other way either so I'd say go for it.

[vipkid]

Thanks heaps boops boops, this has helped me heaps, its very simple but effective, there was no issue with the resize the form is locked to a certain size so the first code worked perfect with a few alterations.

[boops boops]

I would definitely consider it a hack to have a partly transparent form act as if it is a drawing on the webbrowser. The point is that something is acting like it is something else. But hacks are not always bad, and I don't see any other way either so I'd say go for it.

I can see the point of preferring PictureBoxes to show pictures, Radiobuttons for exclusive options and so on. But a Windows Form is hugely versatile. You can use it as a free-floating dialog box, a conventional UI main form or the child of another form. Besides hosting controls, it has special properties to support graphical uses such as DoubleBuffered, Opacity and TransparencyKey.

So I don't see what is wrong with using a form as a purely graphical element as in the OP's question. I am not sure how to check this, but I get the impression it requires no more extra memory than a PictureBox or a Panel. It's not as though I were suggesting any obscure coding tactics: there's not an API or a WndProc in sight. It just takes one line in the Load event, frm.Show(Me), and small Move/Resize handler to keep it in place. Everything else can be selected in the designer, apart from Owner= which is actually superfluous since the ownership is set in the Show statement.

Calling something a hack conveys a sense of unreliability. It "may have issues" or "is not always bad" as you put it. So my question stands. I would still like to know whether there is really something unreliable about using forms this way.

BB

[NickThissen]

I never said a hack was something bad. Especially if there are no other options, a hack is obviously good because it's the only way to do what you want. If there are other options that give you the exact same behavior with 'better', more conventional methods, then of course the hack is not recommended, but that doesn't seem to be the case here.

I only call it a hack because it is a 'work around' for something that is impossible (painting on a webbrowser).

As for unreliable things with this method, I can't really think of anything, but that doesn't mean there aren't any. That's the "danger" of these things: you can't really be sure that it will work 100% of the time. The fact remains that there is no 'hard' link between the 'painting form' and the underlying webbrowser. If you close all loop holes, then theoretically you could mimic such a link but you can't be sure if you know all loop holes. Of course, with sufficient testing you can make sure that nothing will go wrong in most of the cases. I've seen you recommend this method for various other things too, so I expect it will be tested sufficiently by now so it should all be fine.

I guess what I'm trying to say is that windows doesn't know about your connection between these two forms, so there is no reason to assume that it will go right. I can imagine windows hiding one of the windows, for some reason, while not hiding the other. It tends to do stuff like that once in a while

[boops boops]

I never said a hack was something bad. Especially if there are no other options, a hack is obviously good because it's the only way to do what you want. If there are other options that give you the exact same behavior with 'better', more conventional methods, then of course the hack is not recommended, but that doesn't seem to be the case here.

I only call it a hack because it is a 'work around' for something that is impossible (painting on a webbrowser).

As for unreliable things with this method, I can't really think of anything, but that doesn't mean there aren't any. That's the "danger" of these things: you can't really be sure that it will work 100% of the time. The fact remains that there is no 'hard' link between the 'painting form' and the underlying webbrowser. If you close all loop holes, then theoretically you could mimic such a link but you can't be sure if you know all loop holes. Of course, with sufficient testing you can make sure that nothing will go wrong in most of the cases. I've seen you recommend this method for various other things too, so I expect it will be tested sufficiently by now so it should all be fine.

I guess what I'm trying to say is that windows doesn't know about your connection between these two forms, so there is no reason to assume that it will go right. I can imagine windows hiding one of the windows, for some reason, while not hiding the other. It tends to do stuff like that once in a while

The relationship between them is rock solid. An Owned Form is locked to its owner in the Z-order, and they are automatically hidden, minimized and closed together. If one is Topmost, so is the other. As my example above shows, coordinating them in the XY direction is a simple task. The relation is no less secure than that between an MDIParent and an MDIChild.

The Framework provides ample support for Owned forms. There are at least three ways to set Form A as the owner of Form B: B.Owner=A, A.AddOwnedForm(B) and B.Show(A). Other Form members associated with ownership are RemoveOwnedForm and the OwnedForms property (array of Forms). MSDN gives a modeless Search/Replace window as an example for an owned form but that is clearly not exclusive.

So it surprises me that so many people seem unaware of Owned Forms. Combined with the Form.Opacity property, it opens up many possibilities for using superimposed forms for graphic purposes. See for another example my CodeBank contribution "Very Simple Slide Show with Cross Fading".

BB