I've checked the code for any instances where the DropDownHeight is being set, and there aren't any - neither in the *.designer.cs or the main class *.cs file... which according to MSDN means that the width should resize if IntegralHeight is set to true (which is apparently the default but I'm setting it manually just in case). Is there nothing like a Refresh() or Invalidate() that I can call to force it to re-evaluate it's contained items automatically? I really don't want to have to resort to OwnerDrawn to sort this out...

Yep, double-checked that I haven't. Any other ideas?

Hey all, Got an interesting problem where I'm using a cascaded combobox type setup, with the second combobox's IntegralHeight property set to true so that it should resize itself relative to the contents of the items list. However, it's not doing this and I'm stumped. I don't think I should have to go ownerdraw in order for this to work, so can anyone suggest a reason why it might not be working? FYI I am rebinding the combobox datasource to a datatable each time the "master" combobox value changes.

hehe... Unfortunately, I can't test that as I'm running against an SQL2000 server... and my SQL needs to be backwards compatible so... No variables in TOP statement for me! Also, you didn't answer the question: Will the stored procedure I wrote run as fast or faster than the solution which uses the dynamic SQL query?

Okay, so as far as I understand it, having variable SQL queries in a stored procedure (except the obvious WHERE clause exception) is generally a good way to screw up the execution plan... So, seeing your responses to the question, why didn't you just do the following? I'm using the Northwind Database as the test DB.CREATE PROC TestIdead @number smallint AS if @number = 10 begin select top 10 * from Customers end else if @number = 20 begin select top 20 * from Customers end else if @number = 30 begin select top 30 * from Customers end
In hindsight, you could probably reduce the IF...ELSE stuff down to a CASE statement as well... Just wondering why you opt for dynamic SQL queries rather than a logic structure that would result in a faster executing stored procedure (because the queries are static and thus don't modify the execution plan)? I'm a bit new to SQL and stored procs, so please enlighten me. :)