если хочешь сделать его модальным и проимитировать виндовую идеологию, во первых есть флаг modal для BFilePanel, а, во вторых, while придется реализовывать более хитро, через создание и удержание семафора.
Гнило это все конечно. Так делать, но иногда приходится.
Пример кода смотри здесь:
http://lxr.mozilla.org/seamonkey/source/widget/src/beos/
файлы
nsFilePicker.cpp и *.h

Кроме того, одна рекомендация.
создай BFilePanel где нибудь в начале существования программы один раз навсегда.
Делай только Show() и Hide() когда требуется.

Большое спасибо за (оперативный!) ответ.
1. Свойство modal в конструкторе — это какая–то другая модальность, т.е. не та, которая мне требуется.
Ибо делая так:
HelloWindow::HelloWindow(BRect frame) {
…
od_ = new BFilePanel(B_OPEN_PANEL, NULL, NULL, 0, false, NULL, NULL, true);
…
bool CBFileDialog::execute() {

done_ = false;
dlg_–>Show();
message("!");
…
Я получаю сообщение “!" сразу после вызова диалога.
Искомая мной модальность: чтобы Show работала как ShowModal() в VCL.
2. Насчет семафоров я пока еще не смотрел. И в пример еще не врубался.
Вроде бы такая рядовая ситуация, а какие заморочки! :)

Спасибо за рекомендацию.

P. S. Программируя под BeOS, вспоминаю год эдак 1995, когда я пытался писать под Windows 3.11 на Borland OWL.

А пример действительно дельный. Кажется, это именно мой случай. Буду разбираться.

Будучи спроектировано [практически] с нуля BeAPI имеет свойство не следовать некоторым ущербным и по сути вредным концепциям° — как–то безусловная(дефолтная) модальность диалогов свойственная windows. Конечно, Ваша ситуация, когда нужно спортировать уже готовую программу — не очень располагает к идеологическим переработкам, но тем не менее — это сделано так. И придется использовать такие решения как уже предложены — с блокировкой на семафоре до завершения обработки диалога. Правда придется озаботится еще и disable для основного окна. =–) Как правило виндовые программы наивно полагаются на то, что пока висит модальный диалог никто к ним не пристанет … а зря. =–)

Могу ошибаться, но даже в нормальных (не от М$) рекомендациях по UI диазайну рекомендуется избегать модальности как черт ладана. Мол нельзя усера ограничивать …

Косвенным подтверждением правильности моего мнения служит то, что, как правило, всякий вопрошающий о необходимой ему модальности не имеет вразумительного ответа на вопрос: «А зачем тебе модальность?» кроме как бараньей упертости «Хочу и все.» либо «чтоб как в винде».

°)А уж за то, что протащили в win32 этот ущербный MessageBox не предложив более вменяемого решения — того, кто за это отвечал дОлжно пороть до полусмерти на главной площади прилюдно.

ПС: Все не от вредности но с целью обьяснить ситуацию. =–) Удачи.

Я не собираюсь особенно обсуждать идеологии, MS, теории UI–дизайна и т.д.
Я также интересуюсь человекомашинными интерфейсами и могу сказать, что да, модальность — это режим, что режимов следует по возможности избегать. Однако, если BeOS–разработчики по умолчанию имеют немодальные файловые диалоги — ну и что, это верх прогресса? Давайте уж тогда идти до конца.
Дело в том, что полностью исключая модальность мы (в пределе) подходим к полностью параллельному программированию. Это совершенно другая (здесь могли быть ваши эпитеты) сложность. Вот, допустим в BeFAR я ищу файл на диске, почему бы этому BeOS–созданию не искать его фоном, чтобы я мог также просматривать (ReadOnly!) какие–то файлы и настраивать тот же BeFAR?
А что делать, когда пользователю нужно принять решение в этих двух параллельных задачах? Давать каждой задаче по окну, чтобы человек переключался? Или завести специальный, назовем его, interaction manager, в главном окне, а сам «поиск» спрячем (зачем ему окно?). А представляешь, каково неопытному пользователю переключается между всеми этими немодальностями? Где главное, где второстепенное? В этом смысле модальность может быть проще не только для программиста (для него она однозначно проще), но и для пользователя — ему нужно пройти через ряд шагов. Ну а вот wizard–ы — этож модальность в пределе — и ничего, не жалуемся.

А если я как раз переношу wizard? (вот тебе уважительная причина ЗАЧЕМ)

Ну да мы отвлеклись. Значит говоришь, без семафоров мне никак? :)

Предупреждение.
Не знаю, с каким API ты в виндах работал.
В смысле, использовал ли потоки.
Тут это главное, про них понимать.

Применительно к нашему случаю — если ты запустишь такое же решение как в мозилле из главного потока программа, то будет работать, но неэстетично. Например, при передвижении файловой панели поверх основного окна, он перерисовываться не будет. То есть будет некий визуально непрятный след от движения верхнего окна на нем оставаться.
поэтому лучше сделать для запуска такого FileDialog отдельный поток. Как — это другая история.
Коротко — три пути — или создание дополнительного окна, можно — невидимого если надо. или создание объекта класса BLooper (базовый класс для BWindow) — ну или специальное создание потока (Kernel Kit в BeBook).

насчет параллельности ты это правильно. тут так оно и есть. в потенции. если в БеФар это не использовано — это его проблема, но идеология именно такая. А вот как это в UI использовать чтоб удобно — тут две стороны.
С одной — разрабочик должен сетреотипы перебить и голову включить, с другой стороны — и пользователь должен быть не до конца упертым:)
Что касается семафоров — делал я и без них как -то.
Если совсем прижмет — поищу в архивах.
Но из «тренировочных» целей — не сейчас:)

А кто сказал, что BeFAR это BeOS аппликация? Никоим боком. Это порт — в данном случае порт идеи(также, кстати, неактуальной в XXI веке). =–)

А в Тракере поиск распараллелен. =–) И еще много чего делается вполне интуитивным и естественным образом. Главное не плодить сущности и не усложнять жизнь без нужды. А что касаемо программирования — играть по правилам, которые приняты в системе под которую пишешь.

А с «волшебниками» — то мое личное мнение — необходимости в построении усеров в колонну и прохождении их строем через некие обязательные процедуры не вижу. Если кажется что без этого не обойтись и обьем запрашиваемой информации велик настолько что не помещается на окошке разумных размеров — значит нужно вернутся и еще раз обдумать дизайн всей системы. Что, в конце концов мешает использовать столь популярные «формочки со оглавлением(деревом) опций слева» для этой цели? Нежелательное взаимодействие опций, меняемых не в том порядке? Так, позвольте, речь о программировании или о халтуре? =–)

Оговорюсь сразу — речь не о промышленных масштабах кодировки — там другие (моральные) принципы.

А «неопытного» пользователя и не стоит загружать сверхвозможностями и сверхтребованиями.

И вправду отвлеклись… В любом случае понимание сильных и слабых сторон приходит с опытом. И желание узнать альтернативные решения однозначно заслуживает похвалы. =–)

Знаешь, я вроде не чайник, но понимаю тех юзверей, которых и Мозилла и особенно Опера отпугивают своими настройками:)

Вот IE хорошо, хехе. Там пользователь до настроек в жисть не добирается:) По пользователю и программа.

Ну ты лучше меня знаешь, что Mozilla — тоже порт. =–))))))

Кстати, а что портируешь, если не секрет? =–)

О!
Это концепт, в некотором роде исследовательский проект. У меня это первая разработка с переносимой моделью интерфейса. Можно, конечно, написать опять под винду на другой GUI–библиотеке (первый вариант на c++ builder), но это не интересно.
А вообще, это специфическая программа: расшифровка «черных ящиков» (параметров поездки) с железнодорожного транспорта.
Так что никакой ценности для всех BeOS–приверженцев эта программа не имеет. :)

Спасибо, Сергей!

Я постараюсь сделать это каким–нибудь способом. Пусть будет грубо, для начинающего пойдет. Потом, если что, переделаем.
О результатах сообщу.