Agreed.

while (e) { Coyote(); }

One night and as I stepped into the bath and the water rose a light went on in my head. The next day at Starbucks I was having a latte with my buddy Archimedes and I mentioned it to him. I'm sure y'all know what happened next.

while (e) { Coyote(); }

Couldn't you have the tabs in multiple rows? That wouldn't take up too much more vertical screen real-estate.

while (e) { Coyote(); }

... when Articles, Blogs and Tips were separated into different tabs on the main screen. Just my opinion.

while (e) { Coyote(); }

I believe that a ListView uses a VirtualizingStackPanel for it's ItemsPanel and that the IsVirtualizing property defaults to true. Try setting it to false if you don't need your listview to hold many items. Either that or try using a regular StackPanel for the ItemsPanel.

while (e) { Coyote(); }

Sorry, I forgot to check the bug list. Nice to see you're working on this one.

while (e) { Coyote(); }

It would be great if there was a way of copying a snippet of code (or an entire file) from within the Browse Code tab, but without all the line numbers.

while (e) { Coyote(); }

WTF?

while (e) { Coyote(); }

Not a comment, but in a defect report under "steps to reproduce" ... "Chant magic incantation three times then wave wand."

while (e) { Coyote(); }

Why is this message even displayed? So what if I don't live in a particular area ... should that stop me from seeing what jobs are out there?

while (e) { Coyote(); }

You can't do this in the TextBox control. However, you could create your own control that derives from TextBox and override the Paint method to do whatever you wish. Of course you'd have to come up with some way of specifying which word(s) have different colour backgrounds. Seems like a lot of work when RichTextBox already does this.

while (e) { Coyote(); }

Call Application.DoEvents() after setting the textbox value.

while (e) { Coyote(); }

Let's say I have a .NET 2.0 application that needs to load about 30 different .NET 2.0 assemblies during startup. Said application is taking about 35 seconds to cold-start and about 13 seconds to warm-start under a specific environment. I am aware that these numbers are fairly typical of .NET 2.0 applications. Our company did not develop said application, but am tasked with coming up with suggestions on how to improve the cold-start performance. The reading I have done suggests that the difference in the two times is due to pages still being available in memory and not as many hard-faults (disk accesses) need to be performed to reload an assembly. Things I have identified as potential solutions are: 1. Update the minimum hardware requirements (not sure what they currently are, but the tests above were done on a 1.8 GHz P4 with 512MB RAM). The cold-start time drops from 35 to 13 seconds on my development box which is a 3.0 GHz Dual Core with 2GB RAM. Warm-start time drops from 13 seconds to 3 seconds. 2. Update the application and all its assemblies to .NET 3.5. Any idea what improvement is this likely to achieve? 3. Generate native images for the assemblies. This is a trade-off between the time needed to load larger disk images and the time required to JIT-compile a CLR assembly. Is this worth pursuing further? 4. Rebase the assemblies. Using Process Explorer from SysInternals I observed that 30 assemblies were relocated by the OS Loader. Preliminary tests indicate that the performance improvement is negligible. 5. Preload the assemblies. What this would try to achieve is to mimic a warm-start, but I'm not sure how it would have to work. If I have a pre-loader application that loads the assemblies needed by the actual application, aren't different copies of the assemblies loaded by each application into its own AppDomain? How would this help improve cold-start performance unless the assemblies are put in a common place? As you can see I'm a little confused. Help? I have gleaned most of my information online from http://msdn.microsoft.com/en-us/magazine/cc163655.aspx[^]. I look forward to hearing suggestions, ideas. Thanks.

modified on Thursday, April 30, 2009 7:41 PM

Denogginizer?

Yeah, I guess I was just too stubborn to have it sink in. For those that care, creating a class that derives from System.ValueType isn't allowed ... 'TestNamespace.TestClass' cannot derive from special class 'System.ValueType'.

OK. Given that System.Enum is declared as public abstract class Enum : ValueType, IComparable, IFormattable, IConvertible, in your opinion, what should the following return?

Type.GetType("System.Enum").IsClass
Type.GetType("System.Enum").IsInterface
Type.GetType("System.Enum").IsValueType

My guess would be true, false, false when the reality is false, false, false. As far as I can tell, Enum is the only type declared as a class in the System namespace hierarchy where Type.GetType("type name").IsClass returns false. I'm trying to find out why, and nothing I've read so far has answered that question. BTW, not everything derives from Object. Interfaces do not derive from anything.

MSDN also wrote (on the same page you cited):

C#
[SerializableAttribute]
[ComVisibleAttribute(true)]
public abstract class Enum : ValueType, IComparable, IFormattable, IConvertible

When I right-click on Enum in a source window in VS and choose Go To Definition it also indicates it's a class:

using System.Runtime.InteropServices;

namespace System
{
// Summary:
// Provides the base class for enumerations.
[Serializable]
[ComVisible(true)]
public abstract class Enum : ValueType, IComparable, IFormattable, IConvertible
{
members snipped ...
}
}

The Object Browser in Visual Studio isn't sure what it is. Sometimes it thinks it's a struct and sometimes an abstract class. The bottom line? I'm still not convinced one way of the other.

Type.GetType("System.Enum").IsClass returns false, yet all the documentation indicates that System.Enum is a class. What am I missing?

In controls that allow selection of a thing, I've seen two common ways to inform the user that the currently selected thing has changed and what the new selected thing is. In the first method, the event notification arguments contain no extra information about the selected thing but the control has a property for accessing it.

private void someControl_SelectedThingChanged(object sender, EventArgs e)
{
SomeControl someControl = sender as SomeControl;
SomeThing selectedThing = someControl.SelectedThing;
...
}

In the second method, the new selected thing is a property of the event notification arguments.

private void someControl_SelectedThingChanged(object sender, SelectedThingChangedEventArgs e)
{
SomeThing selectedThing = e.SelectedThing;
...
}

One advantage I can see of one method over the other is that the first method is useful if the SomeControl.SelectedThing property is read/write and can be set via code and not just input events. If the SomeControl.SelectedThing property is read-only, then it doesn't really need to exist and the value can be passed in the event arguments as per the second method. Agree? Disagree? Discuss ...

Works now ... Thanks!