Yes, I had tried that. However, it did not accomplish what I wanted to achieve. The menu item will be completely custom drawn, but there is some text that I'll need to assure will fit. So, I calculated the width of a space in the menu item font, measured that text that will be rendered to it (though text measuring in .NET is sometimes inaccurate), and set the menu item text to all spaces (see code below). However, every menu item in that drop down will have the same height now if there is more than one line. And, we have no way of making the menu item an exact dimension since we can only affect width/height using spaces and newlines in the menu item text. Ideally, I'd like to know if there is a clean way to resolve such drop-down menu and menu item dimension inconsistencies. Perhaps a "DoWhatIWant" flag? :)

private void AutoSizeCustomMenuItem(ToolStripMenuItem oMenuItem, string sText)
{
int iPreferredHeight = 50;
int iPreferredWidth = 0;
int iPadding = 50;
SizeF oSizeSpace = SizeF.Empty;

using (Graphics oGraphics = oMenuItem.Owner.CreateGraphics())
{
iPreferredWidth = (int)oGraphics.MeasureString(sText, oMenuItem.Font).Width + iPadding;
oSizeSpace = oGraphics.MeasureString(" ", oMenuItem.Font);
}

int iSpacesWidth = (int)Math.Ceiling((double)(iPreferredWidth / oSizeSpace.Width));
int iSpacesHeight = (int)Math.Ceiling((double)(iPreferredHeight / oSizeSpace.Height));
string sSpacesWidth = new String(' ', iSpacesWidth);

StringBuilder sbMenuItemText = new StringBuilder();
if (iSpacesHeight > 0)
{
string sLineDivider = String.Empty;
for (int i = 0; i < iSpacesHeight; i++)
{
sbMenuItemText.Append(sLineDivider);
sbMenuItemText.Append(sSpacesWidth);
sLineDivider = "\r\n";
}
}
oMenuItem.Text = sbMenuItemText.ToString();
}

I am attempting to populate a ContextMenuStrip (or any ToolStripDropDown for that matter) with ToolStripMenuItems that have AutoSize set to False and a specific Height and Width. However, I cannot get the ContextMenuStrip to AutoSize (which is set to True on the ContextMenuStrip). The Height appears to be resized, but the Width cuts off the menu items. I have tried using varying values for Margin, Padding, AutoSize, Width, Height... etc... but to no avail. Any ideas?

private void AddMenuItem (ContextMenuStrip oContextMenuStrip, string sText)
{
oContextMenuStrip.AutoSize = true;

ToolStripMenuItem oMenuItem = new ToolStripMenuItem(sText);
oMenuItem.AutoSize = false;
oMenuItem.Width = 300;
oMenuItem.Height = 40;

oContextMenuStrip.Items.Add(oMenuItem);
}

Haven't tried this, but noticed you are using the type char(50) instead of varchar(50). Is the char(50) adding padded characters to the end of the string, causing it to not match?

It really depends on how it is being used, and I personally use both techniques. I can't say I've read much on the benefits/pitfalls of each approach, but within T-SQL, I prefer the OUTPUT param simply to favor variable assignment rather than having a result set returned. If the stored procedure is being called from .NET, I usually SELECT out the record ID, and utilize the ExecuteScalar method of SqlCommand. The T-SQL usage doesn't really favor one over the other (in terms of keystrokes):

EXECUTE StoredProc @Param1, @Param2, @RecordID OUTPUT

SET @RecordID = EXECUTE StoredProc @Param1, @Param2

OUTPUT Parameter: If stored procedure is being called from within T-SQL. If the new record ID is not always used by the caller. SELECT Record ID: If stored procedure is being called from .NET (use SqlCommmand.ExecuteScalar). If the new record ID is always used by the caller. If you do choose to take the OUTPUT parameter route, I would suggest you are careful about how you assign the new record ID to that OUTPUT parameter. If the stored proc is being called within a loop, you'll want to make sure the previous value does not remain in the output parameter (in the event that a record is not actually affected). You may also want to set the default value for that OUTPUT param as NULL so it is optional (in the event the caller does not require the record ID).

You may want to take a look at the sp_executesql system stored procedure: http://msdn.microsoft.com/en-us/library/ms188001.aspx[^] This allows you execute the dynamic SQL string, as well as specify parameter definitions and parameter assignments that can bind local SQL variables to the dynamic SQL call.

DECLARE @InputParam int,
@OutputParam int

EXECUTE sp_executesql 'query',
N'@DynamicInputParam int, @DynamicOutputParam int OUTPUT',
@DynamicInputParam = @InputParam,
@DynamicOutputParam = @OutputParam OUTPUT

Within 'query', use the dynamic parameters/variables defined in the 2nd parameter (@DynamicInputParam and @DynamicOutputParam). Within 'query', these variables will initially contain the values of (@InputParam and @OutputParam). If a dynamic parameter is defined as an OUTPUT parameter (@DynamicOutputParam), any assignment to that variable will be reflected in the local variable (@OutputParam) after the call to sp_executesql.

You may also want to take a look at OleDbConnection.GetSchema (Google it to find the MSDN documentation link). This will allow you to directly obtain schema information for the Excel file. The schema is returned as a DataSet containing DataTables for a variety of entities. One of these DataTables will contain a list of table names (which are the Excel worksheet names you'll use in your queries). This will allow you to avoid using COM automation entirely (ie. Excel Object library) to obtain the list of Worksheets. The benefit: no dependency on Excel object library DLLs, registration, versioning, etc... all the headaches that come with COM automation.

You are building your SQL string by concatenating the object Sheet. This object is of type Excel.Worksheet - which is not a string. Thus, as with all objects, it is calling it's ToString() method to obtain a string value it can concatenate with the rest of the SQL string. Since Excel.Worksheet is a COM Object, it's ToString is returning "System.__ComObject". You'll need to obtain the actual text name of the worksheet and use that to build the SQL string.