I am creating one user control in windows form. It is some data entry form. The application opens in minimize mode initially. And the from looks good in minimization mode. But when i maximize the form is not getting filled up. I mean the there is lot of room in maximize mode. The form should grow size according to minimize or maximize. The form has tab control, group box and grid view. thanks.
If I understand your problem correctly, check your anchor points of the controls on your form. Also, check that form controls are set to grow and shrink, as you see fit. The combination of the two may fix your problem.
Related
After searching for a few days, i thought maby someone can help me.
I'm making a Windows form Application. And on one of my views i have a repeater with a label in there. This label is dynamicly sized. But My DataRepeater item won't adjust to the size of my label.
Has anyone a idea how to fix this?
The datarepeater i use is from the visual basic powerpacks.
If any more Infromation is needed to help me, please let me know.
Regards Stephan
It looks like DataRepeater is very limited with regards to resizing. I found this website that it looks like they got it working, but all of the items resize to the same size.
http://social.msdn.microsoft.com/forums/en-US/vbpowerpacks/thread/c93579f2-8b4c-4002-9ce2-152e2dddd10e/
Edit:
This solution is a little bit more complex, but VERY flexible:
You can use a FlowLayoutPanel:
You create an User Control for the item on the list and add a Select Property to the User Control.
You add a list of the User Controls to the FlowLayoutPanel.
When the User Control change size, it automatically adjust everything in the FlowLayoutPanel. (Disable WrapContents to prevent Horizontal Scrolling)
http://msdn.microsoft.com/en-us/library/ms171633.aspx
You can use the following in the UserControl to enable Click on the User Control to select it:
Click event for .Net (Windows Forms) user control
In the form that use the FlowLayoutPanel, you add the Click event, and then apply the Select to only that one User Control.
You can use the SetBoundsControl inside the User Control to set the size of the item.
I have a problem with screen size. In my computer, I set form size is 1915*1130. However, when open project in other computer (the same resolution), form size is change into 1910x1020.
2 computer resolutions is set as the same.
Is there any property to prevent that.
Does anyone have the same issue?
Please help me.
Thanks,
Ankata
Try this, http://forums.aspfree.com/visual-studio-how-to-73/windows-form-height-size-cant-be-made-bigger-than-screen-382576.html
He puts a panel control onto the form with scroll bars on. This allows you to set the size of the panel and somehow the form accommodates it. Haven't tried it myself.
This may not be the kind of question one should ask on StackOverflow, but here's a frustration that I've been trying to find a work-around for.
When using the form designer, suppose the entire form does not fit in the space allotted to the form designer, and I have a control say, down near the bottom of the form.
If I try to re-size that control, or move it using the mouse, the work area will auto-scroll to the top of the work area. This essentially pulls my control to the top of the screen. It isn't possible to scroll with the scroll wheel while "holding" a control, and even ScrollLock does nothing for me.
Is there any way to just turn the auto-scrolling off? That way I can at least work on my form without guessing numbers to type into the properties window.
Can't you just turn off autoscroll for the form?
I think it's off by default.
Form.AutoScroll = False
Following on from a question I posted yesterday about GUIs, I have another problem I've been working with. This question related to calculating the bending moment on a beam under different loading conditions.
On the GUI I have developed so far, I have a number of sliders (which now work properly) and a pop-up menu which defines the load case. I would like to be able to select the load case from the pop-up menu and position the loads as appropriate, in order to define each load case in turn. The output that I need is an array defining the load case number (the rows) and a number of loading parameters (the itensity and position of the loads, which are controlled by the sliders).
The problem I am having is that I can produce this array (of the size I need) and define the loading for one load case (by selecting the pop-up menu) using the sliders, but when I change the popup menu again, the array only keeps the loading for the load case selected by the pop-up menu.
Can anyone suggest an approach I can take with (specifically to store the variables from each load case) or an example that illustrates a similar solution to the problem?
The probem may be a bit vague, so please let me know if anything needs clearing up.
Many Thanks,
James
You could use Application Data to store the current loading case and have a application data structure to store the values of each slider for the different loading cases.
In short, you could use the setappdata and getappdata to save and load the data you need. Mathworks has more information here.
I've found many answers, here or inside MS' UI guidelines, regarding button positioning, but none about how to position (in which order) buttons when you have three actions to do, New, Edit and Delete.
I have a simple UI, in the upper part I placed a grid listing some data. Beneath, these three buttons. Following what I see around, I have to place them in this order:
New - Edit - Delete
But it seems to me that the delete button is more prevalent and easier to reach and click than the others (it falls on the lower-right corner of my window).
Any suggestion?
I think the order you cite (New - Edit - Delete) is most common because you would logically tab order from left to right when using the keyboard. New would arguably be the most used button (possibly edit depending on the application, but rarely delete) and therefore you wold want the fewest tabs to get to the New button.
Column layouts are always good for these kind of buttons, as one has to move the cursor into the button area, which is horizontally slight and therefore less likely to be accidentally clicked.
Also it provides a perceived division from the main GUI widgets, instead of spanning their length, which tends to create less of a perceived division in the user's mind.
But if you do not wish to change the overall layout, I would say that your current layout is good. Maybe add a delete confirmation box if one is not already present.