To quote the late, great Mitch Hedberg when describing 2-in-1 shampoo... 2-in-1 is a BS term, because 1 is not big enough to hold 2. That's why 2 was created. If it was 2 in 1, it would be overflowing... the bottle would be all sticky... To store 2 byte values, 2 bytes are required. To store 2 nibbles (half-bytes), sure you could use 1 byte, but the question begs why?

That's kind of annoying. I've noticed these types of subtleties even when using standard MS tools like SSMS. My first reaction when something fails is to change some variable of the experiment before trying again, but with SQL Server, a lot of times, you just need to act like a crazy person and try the EXACT same thing expecting different results. Thanks for your tip, I had managed to workaround the issue, but I might implement this suggestion as well.

Using SMO with SQL Express 2005, I'm experiencing some frustrating behavior. I'm using SMO Server and Database classes to script my database using Database.ExecuteNonQuery. The database objects are getting scripted correctly, but I'm having problems re-connecting to the database (using SqlConnection.Open). I get a SqlException ("System.Data.SqlClient.SqlException: Cannot open database \"MyDatabase\" requested by the login. The login failed.\r\nLogin failed for user 'MyDomain\\MyUser'.\r\n at System.Data.ProviderBase.DbConnectionPool.GetConnection(DbConnection owningObject)\r\n at System.Data.ProviderBase.DbConnectionFactory.GetConnection(DbConnection owningConnection)\r\n at System.Data.ProviderBase.DbConnectionClosed.OpenConnection(DbConnection outerConnection, DbConnectionFactory connectionFactory)\r\n at System.Data.SqlClient.SqlConnection.Open()\r\n at MyCodePath\\DataAccessFactory.cs:line 57") The problem "goes away" if I just wait before trying to create the second connection e.g. if I use a breakpoint and step through the code it works fine. I am closing my previous connection (the one where I scripted the database) and everything is sequential on a single (the UI) thread. I'd hate to have to code some delay or retry logic for something that seems pretty standard.

I would suggest putting the additional buttons in a Panel, then you can toggle just one Enabled property.

Another technique is to use the "Edit and Continue" functionality of VS. Set a breakpoint near the code to be modified, when it hits, you can make your edits and when you continue running (or step), the changes are recompiled. This approach is somewhat limited (i.e. you can't add a new method, alter a try/catch, etc -- the IDE will tell you when you've made a change that requires a full build), but for tweaking procedural code, this is a great technique (and it has the advantage of forcing you to step through the code and make sure it's doing what you expect) :)

Oh man, FXCop... that brings back (painful) memories.... I used it about 6 years ago on a team with lots of junior developers (and senior developers who thought they were above adhering to conventions). It was effective, but comes with a lot of overhead. On a team of competent developers, I much prefer a document describing the style convention rather than a tool that enforces it. Come to think of it, I prefer teams of competent developers outright :)

Rather than including your development machine name, simply use ".\SQLEXPRESS" or "(local)\SQLEXPRESS" as this will point to instance "SQLEXPRESS" on the local machine.

It's good that you're thinking about this now while your code base is small :) I find that Windows Forms code is pretty easy to keep tidy. If you feel like a given class is getting untidy, it's probably time to decompose it into simpler components. That said, don't over-decompose to start with as this creates unnecessary levels of indirection. Defer refactoring until it makes sense (e.g. if you want to re-use common functionality in multiple places). The best tip I can give is to be rigorous about namespace organization and use meaningful type names so that someone else (or you 6 months from now) can know where to start looking.

I'm trying to create a Component that sits in the Forms designer component tray and contains additional subcomponents that can be selected and configured via the document outline view (or through a collection property of the main component). I've looked at numerous code project articles and even peeking at some MS components that behave kind of like this (e.g. ListView), but I can't seem to get my sub-components to show up in the Document Outline. The MSDN is non-helpful in this area, their "documentation" consists of is a 2 sentence blurb describing an esoteric example and then 10 pages of code that assumes an intimate understanding of the entire .NET component model. Anyone know of a good source of documentation on this area, or better yet any tips on what I might try? Thanks, -Chris [solved] I figured out how to do it. In my main component, add a custom designer:

[Designer(typeof(MyDesigner), typeof(IDesigner))]
public class MyComponent : Component

Then in MyDesigner, inherit from System.ComponentModel.Design.ComponentDesigner and override a couple methods, shown below:

  public override void Initialize(IComponent component)
  {
     base.Initialize(component);

     \_myComponent = (MyComponent) component;
  }

  public override System.Collections.ICollection AssociatedComponents
  {
     get
     {
        if (\_myComponent == null)
        {
           return base.AssociatedComponents;
        }
        return \_myComponent.Subcomponents;
     }
  }

Now my sub components are selectable via Document Outline, but suppressed in the component tray (so as to keep it tidy). :cool:

modified on Friday, December 4, 2009 11:57 AM

The problem is that your line:

public List<sGamePort> sgpPortList;

should be:

public List<sGamePort> sgpPortList = new List<sGamePort>();

Need to assign a target to sgpPortList before you dereference it, hence the null ref exception.

I agree with what's been said here, in summary: get should do be limited to: minimal computation involving readily available data set should do be limited to: minimal computation involved to transfer data to a readily available store and any relevant event handler notification. There's nothing worse than expanding this in Visual Studio and having to wait for 5 minutes while it evaluates a bunch of properties that you likely don't care about!

Agreed that type-safe casting is far superior to blanket try/catch in the original code. As for "as" vs. "is"... As far as I know, "as" and "is" both cope with nulls the same way, "as", however has an advantage when you need to use the instance through the casted type, i.e. you wouldn't want to do an "is" check only to then do an "as" cast after the fact. In any event, you should consider exposing functionality common to both product types through the IProduct interface. Inheritence is only a useful design pattern when common functionality exists at certain levels of the type heirarchy -- if you constantly have to up and down cast, you're probably forcing a flawed design.

Uh, that would return true for any case where obj1 and obj2 are the same length.

If you are wanting to compare the contents of the arrays, then consider the following code:

  /// <summary>
  /// Compare 2 arrays for equality.
  /// </summary>
  /// <param name="data1">Array 1.</param>
  /// <param name="data2">Array 2.</param>
  /// <returns><c>true</c> if equal, <c>false</c> otherwise.</returns>
  public static bool CompareArrays<T>(T\[\] data1, T\[\] data2)
  {
     // If both are null, they're equal
     if ((data1 == null) && (data2 == null))
     {
        return true;
     }
     // If either but not both are null, they're not equal
     if ((data1 == null) || (data2 == null))
     {
        return false;
     }
     if (data1.Length != data2.Length)
     {
        return false;
     }
     for (int i = 0; i < data1.Length; i++)
     {
        if (!data1\[i\].Equals(data2\[i\]))
        {
           return false;
        }
     }
     return true;
  }

This problem sent me on various run arounds... the best solution (by far) that I found was: http://dotnetperls.com/single-instance-windows-form[^]

Link works fine for me. Google C# Single-Instance Windows Form by Sam Allen.

Not possible. Kind of the whole point of a framework... Me fail English? That's unpossible!

Alternate implementation. I actually think the other solution is better, but I was curious if this would work (and it does). Note that UseShellExecute is important, otherwise the process is opened in a new window. The disadvantage is that you're more tightly coupled with the OS (i.e. it wouldn't work under Mono on a non MS-platform)

using System.Diagnostics;

// ...

ProcessStartInfo psi = new ProcessStartInfo("cmd", "/c pause");
psi.UseShellExecute = false;
Process.Start(psi).WaitForExit();

By default, "Ctrl+F5" is mapped to "Start Without Debugging"

You did a lot better job explaining yourself this time :) Another appropriate use of nullables can be seen in a recent post: Using LINQ to Calculate Basic Statistics[^] Here, null is used as a return for standard deviation if the set to calculate is invalid (e.g. null, empty, or < 2 elements). I think I tend to like that better than an out parameter and a boolean return value, and is certainly preferable to returning a valid double in an error case. I guess one could argue that a negative value would be ok (since std dev is >= 0), or an exception should be raised... “To err is human, but to really foul things up you need a computer.” -Paul Ehrlich