|
Try TextBox1.Width TextBox1.Height or TextBox1.Dock would be better.
Frazzle the name say's it all
|
|
|
|
|
|
In addition to studying Anchor and Dock properties of Controls, as suggested here, you can also use aspects of Padding and Margin to affect the way Controls are positioned ... in relation to other Controls ... and/or in relation to Container Controls they are "placed within."
Note that WinForms, and many Controls, have MaximumSize and MinimumSize properties, that may affect their re-size behavior, depending on how they are anchored/docked, or affected by Margin, or Padding inside Container Controls, and/or in relation to the position of other Controls.
Specifically with a TextBox: I think an important design issue is what the expected content is: how brief, how long ? A single line TextBox is one beast; a MultiLine another ? Under some conditions I would not be concerned with re-sizing a TextBox; under other conditions: yes.
"It is the mark of an educated mind to be able to entertain a thought without accepting it." Aristotle
|
|
|
|
|
On a related note, Bill, how does one go about changing the font size when the size of the textbox changes? Is there a reasonably simple way to calculate the proper font size when the textbox is reduced, perhaps, 50%? Just curious...
Will Rogers never met me.
|
|
|
|
|
I once tried a WinForm experiment where I:
a. in the Form Load event:
1. did a recursive parsing of every Control on the Form, to locate all Controls that had a Font property (Labels, TextBoxes, etc.) that one might want to be changed when the Form was resized.
Each of these selected Controls, and their Font, were stored as Dictionary entries:
private Dictionary<Control, Font> cFontDict = new Dictionary<Control, Font>(); The initial Form Size was then stored.
b. in the Form SizeChanged EventHandler:
1. calculated change ratios in width and height based on the obvious.
2. traversed the Dictionary<control, font="">, via for-loop (so I could alter entries), and messed around with changing the Font based on the calculated change ratios.
WinForms does not make this easy since Control.Font.Size, and Control.Font.SizeInPoints are both read-only properties.
A look at the typical Font assignment code in a Designer.cs file:
this.textBox1.Font = new System.Drawing.Font("Arial", 15.75F, System.Drawing.FontStyle.Regular, System.Drawing.GraphicsUnit.Point, ((byte)(0)));Suggests the tediousness involved in changing the whole damn Font just to get a change in FontSize. I did this so long ago I forget exactly how I coded that up.
And what did I end up with: when the app was run, and the Form resized arbitrarily: a lot of bad-looking UI, with the Fonts often looking crummy. I forget whether I limited this to an experiment involving only certain types of Fonts (TrueType ?), or not.
After all, a change in FontSize means you need to have the AutoSize properties of TextBoxes, Labels, etc., set to 'True. And as their "container" size increases or decreases based on new line-height parameters, they then may be out of alignment with other fixed size Controls. So the container itself needs to be scaled.
So, the next step would have been to resize every Control by the same ratios, perhaps address special properties of certain Controls, like the ItemHeight of a ListBox ... but I never took that next step: because, by that time, I had already concluded that reasonable continuous scaling of Fonts in WinForms was a losing proposition, and that if I really had to have that functionality, I should change over to WPF where it appears to me that functionality is ready-to-go out-of-the-box.
The only scenario I can imagine, currently, in WinForms, where I might try to vary FontSize based on the changing Form Size would be one where some client demanded (and was willing to pay for) an App that "snapped" between two or four different sizes, where I could do the right thing, to make all the Fonts that needed to change look good at each size.
best, Bill
"It is the mark of an educated mind to be able to entertain a thought without accepting it." Aristotle
|
|
|
|
|
One major reason for this looking crappy is that Windows picks a screen font with an integer pixel size. If you're resizing from 10 pixel by 85%, it's going to jump to 9, which is too big and your control alignment will be broken, or 8, which is too small and ditto. As you discovered, you can't really do this for UI.
In a real project at the moment I am doing exactly this on a graph, however, and it works pretty well there. That's because the text components (axis labels, captions, headers, value labels) are not aligned with each other in such a way that you notice the slight inconsistencies. I can also see how resizing the font in an individual text area might make sense. Standard control fonts, though, should be left alone because the user has certain expectations about those; even if you got your scaling working perfectly, it would be a nasty user experience.
You can 'scale' a font thus:
Font newFont = new Font(oldFont.FontFamily, newSize);
Ed: I'm not sure if Windows or the Framework caches font objects. If not, you're going to end up with a huge stack of wasted font resources if you implement arbitrary scaling, at least until the GC gets around to collecting them all (which might be a long, long time since you won't be running low on memory which is what it looks at).
|
|
|
|
|
Hi Bob,
Indeed, I would (and have done). once in a while, scale a label where its changing size did not impinge on the overall layout.
Do you find it interesting that the normal WinForms Font size spec written out in the Designer.cs file is a float with a decimal fractional component ?
best, Bill
"It is the mark of an educated mind to be able to entertain a thought without accepting it." Aristotle
|
|
|
|
|
|
when a program becomes very big in source code, its better to write it within 2 or more seperate source code and then compile them
together. question is this thah how can we do it in C#? and how tow
to combine it to other routines. in delphi we do it by units, but I
am novice in c#. please tell me step by step and explicit. tnx
|
|
|
|
|
That's what partial classes are for.
|
|
|
|
|
I think he is not talking about breaking classes into multiple files, rather it is about breaking the logic into multiple classes and packaging them into libraries.
|
|
|
|
|
You may be right. I may need coffee.
|
|
|
|
|
|
If you want to break your application logic into smaller units, you put them in classes and package them as class libraries. If you are talking about breaking a single class into smaller manageable units, you can use partial classes.
|
|
|
|
|
they're called "assemblies" in .Net. Just create a class library project in your solution, and start adding classes to it. To use the classes in that library, you have to include htis line at the top of your file:
using MyLibraryNameSpace;
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass." - Dale Earnhardt, 1997
|
|
|
|
|
John Simmons / outlaw programmer wrote: you have to include htis line
No you don't, but he will need a reference.
|
|
|
|
|
PIEBALDconsult wrote: No you don't, but he will need a reference.
Actually, both a reference to the asembly and the using statment.
|
|
|
|
|
Shameel wrote: the using statment
Is not required and only weak developers use them.
|
|
|
|
|
PIEBALDconsult wrote: not required
Technically, yes.
But this code
using Com.Company.Suite.Product.Version.Module;
MyClass c1 = new MyClass();
is more readable by an order of magnitude than this code
Com.Company.Suite.Product.Version.Module.MyClass c1 = new Com.Company.Suite.Product.Version.Module.MyClass();
|
|
|
|
|
Shameel wrote: is more readable
I disagree, especially when code snippets are published here.
|
|
|
|
|
Code snippets with references to 3rd-party/programmer-created namespaces is kinda pointless anyway.
And who are you calling weak? 
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass." - Dale Earnhardt, 1997
|
|
|
|
|
PIEBALDconsult wrote: I disagree, especially when code snippets are published here.
Well, the vast majority of code that we write goes into some commercial project rather than CP posts.
Repeating the fully qualified type name of class everywhere it is used makes no sense especially when VS (and SD for that matter) tell you the fully qualified type name just by hovering the mouse over it.
|
|
|
|
|
Shameel wrote: the vast majority of code that we write goes into some commercial project
rather than CP posts
Yet the vast majority of code I see that I didn't write is in CP posts.
Shameel wrote: VS (and SD
Which I don't use if I can avoid it. I also prefer to print out code so I can review it away from the computer.
|
|
|
|
|
Agree 100%. Always use the full name.
|
|
|
|
|
I think another way to "frame" this question ... if my intuition is on-line here ... is to ask: how can I design, or re-design, my getting-very-big project into functional units, or: how can I determine a set of "organic criteria" which to use as an "organizing principle" to divide my project into logical "chunks" which, in the long run, contribute to program extension, maintenance, and de-bugging (and lend themselves to unit-testing in "isolation" ?).
All the "tools" mentioned here, including "Partial Classes," "Class Libraries," etc. are valuable.
... edit in appreciative response to feedback from PiebaldConsult ...
Please note: in Visual Studio the option to create a "Class Library" is one that appears when you create a new Solution, and also appears as an option when you choose to add a "New Project" to an existing "Solution." The question of whether a "Solution," which "begins life" as "only" a "Class Library," is, semantically, a "Solution," or a "Project" ... we'll we won't touch that one ...
... end edit ...
You create it, compile it, and, then, to use it "externally," you must reference it, by adding a Reference to the compiled .dll via the Solution Explorer/ References / Add Reference facility. The location of that compiled .dll can be anywhere: and the Add Reference dialog will let you browse to find it.
Once the Reference is added: you do not need to have a 'using' statement for it to be accessed.
The one "tool," not mentioned here, that may also be useful in "encapsulating functional units,"
is using NameSpaces: within one solution you can add Classes, etc., and encapsulate them in the scope of a different NameSpace.
In that case, to access the "whatever inside" that NameSpace, you will need to have a "using" statement in your Form or whatever it is that requires access. Or, you can avoid having a "using," statement kby using a "fully qualified" reference: Example:
using SpecialNameSpace;
SpecialClass theSpecialClass = new SpecialClass();
SpecialNameSpace.SpecialClass theSpecialClass = new SpecialNameSpace.SpecialClass();
However, when your solution, with multiple NameSpaces, is compiled, the resulting .exe incorporates everything: no separate files are created just by using different NameSpaces.
I have never experimented with trying to import a compiled class library dll into another class library, but, come to think of, I think I will ~
"It is the mark of an educated mind to be able to entertain a thought without accepting it." Aristotle
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
