We Keep Coding

Moving controls on a form onto a tab

I have been working for months on a project in c# in Visual Studio 2010 (it interfaces with a camera, power supplies, and motion control). There is a form with many controls on it (radio buttons, buttons, text boxes, bitmap displays...). Now I would like to put all of that on a tab so i can have another tab. This is so that the second tab can have all the default settings on it (e.g, portnumber, baud rate, integration times, pathname...).
Is this doable? Is there a way to cut and paste or click and drag?
Update:
I created a form, put a button on it that when clicked displays a message box with "Hello World". Then i added a tab control to the form, and dragged the button onto the first tab. The button still functions in the same way, displaying the message box when clicked.
So on my big form, i added a tabcontrol. Without resizing it, i did a select all, then unselected the tabcontrol, then dragged everything onto the tab. I then moved the tab control and resized it, then iteratively resized the tab window and moved all the controls. this worked, except the picturebox controls somehow got resized so they were larger than a screen width. Resized the pictureboxes and everything works. (perhaps i just needed the encouragement to give it a try...sorry if not the best question:).
To do this in code, in Form1.Designer.cs can add:
this.tabPage1.Controls.Add(this.button1);
However, I would have to do this for every single control (about 200 of them in Designer.cs).

This can usually be done with some editing of the .Designer.cs file. First, make sure you make a backup in case it all goes horribly wrong. Place the tab control and add a single control (a button or anything) to it. Then examine the .Designer.cs file. As you point out yourself, you will see a line like this:
this.tabPage1.Controls.Add(this.button1);
As for the existing controls on the form, there will be a bunch of lines like this:
this.Controls.Add(this.meErrorReport);
this.Controls.Add(this.peWarningSign);
this.Controls.Add(this.meHeaderText);
this.Controls.Add(this.btnClose);
So what you do is to cut these lines (not including the one for the tab control!), and paste them just following the line shown above, and do a find-and-replace to change them so they match the first one:
this.tabPage1.Controls.Add(this.meErrorReport);
this.tabPage1.Controls.Add(this.peWarningSign);
this.tabPage1.Controls.Add(this.meHeaderText);
this.tabPage1.Controls.Add(this.btnClose);
This should usually do the trick. The controls may be positioned wrong, and most will be hidden until you increase the size of the tab control, but these are minor problems that can be fixed.
PS. I know you've already fixed your problem, but I'm posting this answer in case it can help you, or someone else, in the future.

failedtoperformactiononhiddencontrolexception despite the textbox being clearly visible

I have a wpf application which has a text box in which I can write a text value to just fine the first time around. If I exit the window the text box is in and then reopen that same window the box can no longer be found by the testing, despite being enabled, and clearly visible on my screen.
I looked at the values of the box, the x,y = -1,-1 and height,width are also -1,-1 which is confusing seeing as the box is completely visible.
I know what the text in the box will be, is it possible to search for a text box with that as a workaround?
I'll keep researching this but any feedback is appreciated :)
EDIT: Upon further study there is a second field on top of the original field providing an initial explanation as to what the box is for ("Enter field value").
Maybe this is a wpf error?

I found that the box wasn't being updated properly on the UIMap. This can be solved by setting the application windows SearchConfinguration (only in the specific test) to always search like so:
UIMap.ApplicationWindowName.SearchConfigurations.Add(SearchConfiguration.AlwaysSearch);
Apparently this can cause a performance hit but I haven't noticed!

I would look at the SearchProperties and FilterProperties of the text boxes, I suspect that two have been found and the wrong one is chosen. Or, it may be that the second window has some different values for the properties used to identify the windows.
One idea: Run the program again manually, move the first window with the text box to one corner of the screen, then close that window. Cause the window to be reopened and move it to the opposite corner of the screen; leave the window on display. Open the UI Map of the Coded UI test and use the Locate command to find the box - it should draw a blue line around the text box.
Another idea is to call FindMatchingControls (as shown in Coded UI conditional check on a method is not working) then use the properties (such as some of x, y, height, width) to select the wanted control.
I doubt if it is a WPF error, but it may be an error in the WPF application where it is not clearing up properly when the first window closes.

Graphical hiccups in C# User Control - Resize obscures components

I'm experiencing difficulty with a custom-made User Control, and my searching on Stack Overflow, MSDN, and Google didn't pop up any troubles quite like the one I'm experiencing.
I have a very simple User Control: It's a label, a text box, and a button, with a SaveFileDialog and a FolderSelectDialog available. The text box and button are anchored Left,Right and Right respectively, with the intent that if the control is resized larger, the text box will enlarge to fill the gap, and the button will stay on the right edge of the control.
The problem I am encountering is that when the control is enlarged, the area to the right of the default width of the control becomes blank space when the project is built and run. The pictures here will illustrate what I mean:
In editor:
Running:
The control is smallish in its design window, but when I add it to a form and widen it, it behaves as intended. However, when I run the form the control was added to, half the control isn't visible.
I suspect that I'm overlooking something fairly straightforward, but I wasn't able to find anything addressing this point in my search. Help would be much appreciated.

My guess is that there is a panel or something that is added to your control and will be brought to front somehow runtime.
from property window's top there's a combo from which you can select all the controls in your User Control.
check if all the controls are what you want.
if you find that panel or anything delete it :)
EDIT:
alright this was not your problem.
now I can only assume that you have set some manual sizes to your user control, i.e. in its constructor. in that case designer will show the correct size of you user control,
now some other place in your code, you have set the user controls size manually again. if the layout is suspended and size changes, I think that the anchored controls' size will not change automatically.
if this is your problem, it is probably hard to find.

Why does clicking in a text box cause an AutoScroll panel to scroll back to the top?

Finishing up a register form in a C# application and I noticed with the panel if I enable AutoScroll and then have a textbox that is below the scroll and click on it it jumps all the way back up to the top. Is there a way to fix this with some code or is it a propriety?
It's a little difficult for me to explain it in words, so here's a short video that shows the behavior.

I have had the same problem. I fixed it with this code in my panel:
protected override Point ScrollToControl(Control activeControl)
{
return this.AutoScrollPosition;
}

I had this exact problem. I had to remove the docking from my panels on the form and this fixed the problem.

Since apparently no one has seen this behavior before and could provide a quick answer, I opened up Visual Studio to try and reproduce what you describe.
I created a new WinForms project with a GroupBox containing a Panel whose AutoScroll property is set to "True". Then, I added two new GroupBox controls inside of the Panel, each containing two TextBox controls. The first embedded GroupBox is at the top of the form, entirely visible at startup; the second embedded GroupBox is at the bottom where it must be scrolled into view. This is equivalent to the design/layout that you have as best I can tell from your description and video.
However, when I run the project, scroll down to the second embedded GroupBox and select one of the TextBox controls that it contains, it performs exactly as expected. The TextBox control that I clicked on gets the focus, without scrolling the entire panel back up to the top. I can't seem to reproduce what you're seeing. If you could either tell me what I've done wrong in designing my test sample or post the smallest sample project needed to recreate the behavior you're experiencing, I might be able to help.
Otherwise, here are a few suggestions of things to investigate:
The tab order of the objects on your form. This really shouldn't be causing the behavior described because clicking on a control should set the focus to that control, regardless of its position in the tab order, and jumbling up the tab order multiple times in my sample project still doesn't appear to have the same effect. But I suppose it's worth a try anyway. In Design Mode, go to your "View" menu, and click "Tab Order". All of the controls that you can set the tab order for will have a little colored box at their top-left corner, indicating their tab order in each container. To set the tab order, click once on each of the controls in the natural order you want them to be focused.
Scour your code for any <Control>.Focus or <Control.Select> statements. Make sure that you don't have any validation code that's altering the tab order in any way during run-time. This could be causing focus to jump back to a control located near the top of your Panel, forcing it to auto-scroll to the new location.
Try to reproduce the behavior in a brand new, clean project. Ideally, create a new project in Visual Studio and lay out the controls the exact same way you have them in the project with which you're experiencing difficulties. This is the same thing I did, partly because I don't have your particular project to work with, and also because this is the best way to troubleshoot particularly tricky behavior. It's more likely there is some quirk to your design or source code that's causing this behavior, rather than some kind of bug in the controls themselves. But either way, this will let you know exactly where the problem is occurring, which will get you that much closer to a solution.

You can use TableLayoutPanel" instead of "Panel" to avoid scrollbar change its position.

How to change position of caret in MSHTML during mouse click?

I have a MSHTML-based control embedded in an application and the ContentEditable mode is used to edit documents inside it. The body of the HTML document initially contains the following lines:
<div></div>
<div id="signature"></div>
The caret is placed at the beginning of the document, that is inside the first DIV element. Now when user clicks with mouse inside the control in a place below the last line, the caret is moved into the second DIV element, as it's the closest one to the point where the user clicked.
I want to move the pointer to the end of the first DIV on the mouse click. Now I have the code to calculate the intended position of the caret as IMarkupPointer and IDisplayPointer. What I need to know is where to intercept the MSHTML event pipeline to do the actual caret move.
I've written code that implements IHTMLEditDesigner and moves the caret using IHTMLCaret.MoveCaretToPointer to the intended position. The problem is that no matter where I intercept the event (PreHandleEvent, PostHandleEvent or PostEditorEventNotify) the caret position is eventually reverted to the default one on single click (but it is not reverted if I hold the left mouse button pressed for a while or if I click with right mouse button).

Use jscript inside of the HTML that you load into the IE control. If you do not know HTML and jscript very well you will find this task very painful.
See these questions for my experience when I tried do so something like this.
Risk of using contentEditable in
IE
Why is ContentEditable
removing “ID” from div
I also had lots of other problem, including have to write resize logic in jscript to get the HTML editor to size along with the WinForm form and having to pass the default form/coontrol colours into the HTML editor so that it looked write then users changed colour schemes on Windows.
Even better just find a HTML editor and load it into the IE control, you will still have to code with standard window colours etc yourself.
There are also 3rd party winforms HTML editors you can use. If possible I think you should buy in a solution as ContentEditable is a lot harder in real life then it look.
A quick google found.
Writer by Lutz Roeder (of Reflector fame)
NetRix by netrixcomponent
Html Editor by Carl Nolan
HTML viewing and editing component for WinForms apps

Have you tried using a winforms timer with a timeout of 0?
When you get the mouse down event start the timer.
Then the MSHTML control will process the event
You will then go back to the windows message loop
All other messages in the message queue will then be process before the timer
Hopefully by now MSHTML has set the default caret position on single click
You can then move the caret position yourself when the timer fires
Have a look with Spy++ to see what events are being sent between the diffent windows in the MSHTML control to get other ideals. The MSHTML control is like no other winforms control and you have to go back to all the trick you used in the days of C and Win32 programming.

Maybe there are separate events for mouseDown mouseUp and mouseClick.
You intercept mouseClick but default behavior gets executed on mouseUp.

Have you tied setting the "focus" to the first div by finding the dom item for it, and calling the setFocus (or whatever it is called) dom method? The caret should move to where the fosus is.
(There are interfaces that MSHTML expose to find dom items and call methods on them. Sorry I don't recall the details of how to do this)

I believe you need to change the SelectStart property and leave the SelectionLength = 0. That will move the caret to a new position.