|
|
If you have ever wanted a Label or TextBox in Windows Forms that performs a little more like on the web, then you've probably figured out that there's no intuitive way to make a Label or TextBox automatically adjust its height to fit the text it contains. While it may not be intuitive, it's definitely not impossible. In this example, I'll use a TextBox (you could just as easily use a Label) that is docked to the top of a form.To use this, add aTextBox called MyTextBox to the form, and set Dock to DockStyle.Top. Wire up the Resize event of the TextBox to this event handler. |
|
Read more...
|
|
|
In this series, I’ll take a stab at explaining the different types of objects used in every day applications, how they are held in memory, and how they are eventually cleaned up. Along the way, I’ll hopefully clear up some of the haze that generally surrounds the stack, the heap, object finalization, memory leaks, “unmanaged resources,” the GC (garbage collector), and some other things. This is Part 1 of 4, covering managed and unmanaged code, and the stack. Part 2 will discuss the heap. Part 3 will cover boxing and unboxing, stucts and classes, nondeterministic finalization, IDisposable, and garbage collection. Part 4 will discuss buffer overruns, stack overflows, how to hack and Xbox, and a few best practices for memory-management-aware programming in .Net. |
|
Read more...
|
|
|
Type safety basically means using strongly-typed data to protect against nasty bugs caused by type errors. A “strong type” is a programming construct that imposes certain rules or restrictions on specific data and how the data can be used. A “type error” is a bug that only appears at runtime (as opposed to compile time), and can have a considerably undesirable impact on data – often it only appears when you discover that something has gone terribly wrong. So, we should always strive to write type-safe code. Here is an example. The following method call would not be considered type safe: |
|
Read more...
|
|
|
|
|
Feed Entries 
Home