I have a GUI in Visual Studio 2010 that has several PictureBoxes, LineShapes/Rectangles, and Labels/TextBoxes. The LineShapes/Rectangles need to be in front of the PictureBoxes, and the Labels/TextBoxes need to be in front of the LineShapes/Rectangles.
For months my GUI was working correctly, when I called the BringToFront() method in the desired order in my form's Load event handler. I first called the ShapeContainer's BringToFront() method, and I then called the BringToFront() method for all of the Labels/TextBoxes.
All of a sudden, my PictureBoxes started to show up in front of my LineShapes/Rectangles. Comparing my latest code to my last working tag shows that nothing changed with respect to these objects. I tried calling the SendToBack() method for the PictureBoxes in my form's Load event handler, but it had no effect.
Can someone explain why this behavior spontaneously changed on me, and what I should be doing to ensure the correct display of my PictureBoxes, LineShapes/Rectangles, and Labels/TextBoxes?
If I call all of my PictureBoxes SendToBack methods in my Form's Paint event handler, I seem to get my desired behavior again.
Oddly, I can't call the BringToFront methods for all of my other objects there, or my LineShapes/Rectangles all disappear :/
For now this solved my problem, but I hope that the behavior doesn't change again.
Related
I have a windows application with a tabcontrol. One of the tab of the tabcontrol has a webbrowser control.Now the issue that I am facing is when the focus is inside the webbrowser control, the normal Ctrl+Tab functionality of the tabcontrol is not working.I want the Ctrl+Tab to change the selected tab of tabcontrol even when the focus is inside webbrowser control in selected tab.How to achieve this ?
I have already tries overriding ProcessCmdKey.but it does not get hit when focus is inside webbrowser control.
I also tried registerhotkey method ,it works but it locks the Ctrl+Tab hotkey within my application & system doesn't respond to any other Ctrl+Tab presses outside my application when application is running, which is expected behaviour of registerhotkey.
Here is the code you need:
If WB.ContainsFocus Then
MsgBox("We have focus, disappearing...")
WB.Document.Body.RemoveFocus()
End If
Now, the question is, when to run that code. If you put it in the WebBrowser1_GotFocus event, you'll need to turn it on and off. Turn the code off if the user is interacting with the WB Control, and turn it back on when they are not and when you expect to be experiencing the problem you've mentioned.
Of course, you could add another line to ensure a particular control/tab/panel etc gets focus after you remove focus from the body. Also, here are 3 other SO questions that have answers which may help you, but these will take you in directions different to the direction I've provided, probably due to the fact that the questions are not identical to yours, but are similar enough to be useful (not listed in order of preference).
Prevent WebBrowser control from stealing focus?
Webbrowser steals focus
Focusing WebBrowser control in a C# application
UPDATE:
I just wanted to add, instead of the .Body.RemoveFocus() you could do this:
WB.Document.Body.Parent.RemoveFocus()
Which I prefer, since the .Document object didn't have an explicit .RemoveFocus method on the intellisense I was gettign in VS2012 RC. This is probably referring to the HTML tag (and not the .Document object) and since the html tag is the only parent to the body tag, it makes sense, and there is no "HTML" object directly available in the intellisense under object, since you can get it via other means, so it's just more convenient doing it this way.
Cheers, and let me know if you need more info on anything.
All,
I have a TabControl in an application that started behaving strangely. Some background...
This program was converted from VB6 to VB .NET 2008, and used to refer to forms using their class names. In other words, I might have a form class called frmFoo. In the code for the program you might see:
frmFoo.Show()
or
frmFoo.UserDefinedProperty = True
During some recent changes, I created variables to represent instances of my forms much like these:
Public MyForm as frmFoo
MyForm = New frmFoo
MyForm.Show()
In doing so, I also removed code from the form's Load event handler and put it in the form's constructor.
When the form loads, or when a document is loaded and should influence the TabControl's selected index, something like the following will not necessarily fire the SelectedIndexChanged event.
MyForm.tbsForm.SelectedIndex = ValueReadFromFile
...or...
MyForm.tbsForm.Tabs(ValueReadFromFile).Select
Sorry to be so wordy, but there's more. If I open the form and look at the TabControl to verify that it's been set properly, everything works like it's supposed to. The misbehaving TabControl is contained within another TabControl, so I have to click the parent TabControl to see it. If I can see it, and run a test, the test always works. If I can't see it, and run a test, the first test I run will not fire the event. ...paging Dr. Heisenberg...
It's almost as if the control has to be initialized first by changing the value or making it visible onscreen...I'm totally lost on this one. It's the most unusual behavior I've ever seen. And everything worked perfectly before I began using variables to represent forms and placed the Load event code into the form constructors.
Can anyone help, or at least put me out of my misery?
SH
-------------------------------------------------------------- Edit #2
I just performed a test after having attempted to eliminate some of the variability in the behavior. But I wanted to confirm the previously-stated behavior.
I opened the program and read a file. This file contained a value that should have triggered the event handler. Without making the control visible, I can change the SelectedIndex property of the tab control without the event firing.
I closed the program down again, and reopened it. This time, selected the parent tab that allowed the child tab (the one whose event I'm concerned with) to become visible. I then selected a different tab in the parent control, meaning that the child control was no longer visible. When I opened the same file as before, it fired the event.
I'm tempted to implement a flag that confirms that the control has been repainted or whether the parent tab has been displayed. I may have to fire the event in code if the flag isn't set.
I want to reiterate that everything worked when the program referred to the forms by their class names and much of the arrangement of controls on the forms was done in the load event. Now the program creates variables and the arrangement of the controls is done in the form's constructor. I'm sure this has something to do with the problem I'm having, but I can't understand how. Any wisdom to share?
MyForm.tbsForm.SelectedIndexChanged = ValueReadFromFile
doesn't make a lot of sense. Is tha trying to assign a handler to the SelectedIndexChanged event? or is ValueReadFromFile the name of the tab?
What you're saying is that you have two tab controls, say, A and B. Tab control B is contained within a tab of A, and unless A has the tab page selected that contains the tab control B, the SelectedIndexChanged event of B will not fire if you change its tab programatically?
In which different ways have you tried to select a tab within the child tab control, and when is this code being executed?
I have a DataGridView control in my Windows Forms Application.
I am adding rows to the grid using a background thread. I change the form's cursor to Waitcursor when the process starts and back to Default when it ends. This works well for the form, but not for the grid. When the form's cursor is changed back to default, the grid's cursor does not change, although the cursor over the rest of the form does.
Does this have anything to do with the fact that I am updating the grid from a background thread? (The cursor is being changed from the UI thread directly).
Edit: The background process raises an event, the handler checks the InvokeRequired property of the grid and decides if it needs to "Invoke" the method again from the main thread. So, in effect the actual UI update happens from the appropriate thread. I am not sure if this means that I am "using a background thread" or not. :|
I've had some problems doing single thread updating of my datagrids, where the datagrid did not reset to normal cursor after i've had waitcursor to true.
What I did was right after i went
this.UseWaitCursor = false;
I added
DatagridviewFoo.Cursor = this.Cursor;
Maybe it's just the same problem for you
I've had this problem as well. It was difficult to track down the cause, let alone a solution.
This issue only ever happened when I had a dialog box over the DGV control and the mouse clicked on a button to close the box such that when the box closed, the mouse was over a (resizable) column border. If the cursor ended up over a cell, the problem didn't arise. If I had to guess, I'd say the grid was seeing a column resize event as soon as the dialog box closed which wasn't properly handled.
Using Cursor.Current = Cursors.Default fixed my issue (without the need to explicitly reset the control's cursor). But maybe be aware that Application.UseWaitCursor = False didn't work even with the explicit control cursor reset.
I had a similar problem, but neither of the posted solutions worked for me. Mine was not caused by clicking a button above a movable column separator. It just randomly happened after opening and closing a dialog box. I'm pretty sure it came down to timing because .Net/Windows has issues when it comes to setting cursors and actually having them take effect. To try to overcome that, the library we use for showing and hiding the wait cursor calls - ack! - Application.DoEvents. I set a breakpoint in OnCursorChanged and saw that the cursor was sometimes actually getting set on a latter call to Application.DoEvents (used to keep the UI responsive while waiting for the file system to release a write lock on a file). So I guess sometimes the default cursor was getting turned back on before the call to set the wait cursor had fully taken effect. Anyway, my brute-force approach is to call
Cursor = Cursors.Default;
in my override of OnCellEnter (which always happens after the grid gets refreshed following the dialog box being closed). I'm not particularly proud of this, but it seems to work.
I cant seem to get VB to focus on a textbox correctly at the moment I did
TextBox.focus()
in the load event but still a button keeps grabbing focus anyway. Does anyone know why this would happen?
Try changing the tabindex property.
in webforms, see http://www.w3schools.com/aspnet/prop_webcontrol_standard_tabindex.asp
in winforms View -> Tab Order when the desing view is open
if that doesnt work, try calling the Select() method on your TextBox.
We have a question regarding VB.Net 2008.
We are used control array in vb.net and third party timer controls.
When handle received from external application to timer control event procedure,
after this form becomes blank and controls disappear.
What we have to do to persist the controls.
You asked what you have to do to persist the controls. It's not clear whether you mean winforms or webforms, but I can answer for both possibilities:
If it's the former, you have it backwards. The default behavior of all controls is that they are "persisted" until you tell them otherwise. If anything disappears, it's because you have code somewhere that tells it to. That's where you need to start looking.
If it's webforms/ASP.Net, the problem is that you don't understand the page lifecycle. Everything that raises server events, including your third party timer controls, causes a post back. That's how events work - the browser posts the form back to the same url in such a way that the server knows to call a your event code at the right time. The thing here is that as far your server is concerned, it's still just a new http request, and that means you're working with a brand new instance of your page class every time this happens. If you've previously added some controls to your page, it doesn't matter. That was an old instance that was discarded and probably disposed by the time the page was visible in the user's browser. If you want to keep those controls, you need to make sure you add them to the page on every postback.