Я думаю потому, что во втором случае должен быть массив значений.

ikki, это я уже в примере так нарисовал.  
Раньше так и было: ComboBox1.Text = "". Не работает.  
 
Hugo, не понял, почему массив?  
.Value - значение, находящееся в данный момент в поле ввода, .Text - значения, которые может принять .Value? Так, что ли?

Мне кажется, что там должен быть .List

Агент F1 сообщает про Text Property  
 
For a TextBox, any value you assign to the Text property is also assigned to the Value property.  
 
For a ComboBox, you can use Text to update the value of the control. If the value of Text matches an existing list entry, the value of the ListIndex property (the index of the current row) is set to the row that matches Text. If the value of Text does not match a row, ListIndex is set to –1.  
 
For a ListBox, the value of Text must match an existing list entry. Specifying a value that does not match an existing list entry causes an error.  
 
You cannot use Text to change the value of an entry in a ComboBox or ListBox; use the Column or List property for this purpose.

Стоп-машина. Не туда поехали :)  
 
Есть ComboBox с заданными свойствоми RowSourse (именованный дианазон), но с разными свойствами Style.  
Затирать или восстанавливать RowSourse не нужно! Нужно очищать поля на форме.    
 
Как обнаружил то, о чем говорим.  
Раньше в коде писал ComboBox2=(одно из значений выпадающего списка) - работало.  
Но без указания свойства - неправильно? ComboBox.Text=.... Нормально. Начал исправлять, дописывать .Text. и вот в коде очистки формы обнаружил такую особенность - ComboBox.Text="" не работает.  
 
Вот и возник вопрос: почему? В чем разница?  
Если посмотреть в  свойствах:  .Text=.Value=(текст, вписанный в поле ComboBox)  
 
 
А ComboBox1.Clear выдает ошибку.

Нет, не понятно: ComboBox1.Text = "256" - работает...

Я не переживаю, умный ведь - знаю про .Value :)  
 
Вопрос остался открытым:  
- справка говорит о том, что "Вы не можете использовать Text для изменения значения", но ведь получается использовать (ComboBox.Text = "2");  
- для чего в свойствах .Text, если есть .Value?  
 
Т.е. заглавный вопрос темы: в чем разница, кроме невозможности работать с "пустотой"?

Касаемо примера: не пройдет без ошибки .text. У тебя в первом установлено свойство Style - DropDawnCombo, который позволяет вводить в поле наряду с имеющимся в списке произвольные значения. А у второго свойство Style - DropDawnList, который позволяет вводить исключетельно значения из списка. Таким образом никак не получиться присвоить ему значение, не соответствующее значениям из списка.  
 
При таком подходе будет ошибка:  
ComboBox1.Text = "a"  
ComboBox2.Text = "a"  
 
если записать так, то нет:  
ComboBox1.Text = "a"  
ComboBox2.AddItem "a"  
ComboBox2.Text = "a"  
 
Записать пустое значение не получиться, т.к. список по мнению VBA не должен его содержать.  
 
Что касаемо .value. Дело в том, что это как бы так сказать...свойство, больше относящееся все же к Excel, чем к VBA. Поэтому VBA в данном случае назначит текущему значению КомбоБокса то, которое указано в Value. Я бы отнес это скорее к недоработке интеграции, чем к фиче. Т.к. в данном случае именно .Text отрабатывает правильно, согласно назначенным КомбоБоксу свойствам.

{quote}{login=vikttur}{date=10.05.2012 08:28}{thema=Re: }{post}...Использование ComboBox.Value=... в коде нежелательно.  
ComboBox=... Неуказание свойства при написании кода - только лишь "дурной тон" при программировании?{/post}{/quote}ComboBox.Value= - ну почему нежелательно? Даже твой пример в этой статье можно использовать для себя. Например вручную никак не ввести значения не из списка, а кодом ты без проблем и лишних проверок можешь это сделать. Так что все зависит от цели.  
 
А вот неуказание свойства(ComboBox=) это не просто дурной тон, но и возможные ошибки и сюрпризы-нежданчики. Потому как по умолчанию будет обращение к свойству .Value, а это не всегда нужно. Может ты рассчитываешь там увидеть .Text... Да и вообще не указыать свойство нежелательно даже исходя из того, что VBA может и еще какую злую шутку сыграть - обратиться даже не к .Value, а еще к какому иному свойству/методу, в зависимости от ситуации. Сам не сталкивался и могу ошибаться - делаю вывод на основе работы без обращения к ячейкам без указания свойства.