Проблемы с GUI в C++Builder 5 Опции

[Kayur]

Разработана в среде С++Builder 5 программа управления неким устройством через USB.
Программа выводит на экран окна с текстовой и графической информацией.
Все идеально работает под Билдером, однако, если запустить файл exe вне Билдера,
при выполнении некоторых операций на экране появляются белые прямоугольники.
Попытка реализовать многопотоковый режим к успеху не привела, при этом эффекты появляются
даже под Билдером.
Вопрос: что привносит Билдер в мою программу, позволяющее ей безупречно работать с одним
потоком? Может, кто сталкивался с подобной проблемой и решил ее, подскажите, в каком
направлении искать? Спасибо, кто дочитал до конца!

[sigmaN]

прямоугольники где именно? не прорисовывается содержимое окна? отдельные контролы? при выполнении каких именно операций?
а лучше скриншот бы ещё.
И вот прямо так белые сразу и появляются?
Нужно больше информации в общем....


Что привносит Билдер.... даже не знаю...под присмотром отладчика прога вертится....что он ещё может привнести то....

может ли быть такое, что под билдером и в рантайме - прога разные версии dll цепляет? Опции компиляции одинаковы?

[DpInRock]

Белые прямоугольнички - это скорее всего зависшая прорисовка элементов управления.

Типа, создавая многопоточное приложение вовсю и смело используйте команду Sleep. Причем, если не знаете куда ее ставить - ставьте куда попало. Все лучше будет.

[sigmaN]

а ещё Application->ProcessMesages(); в длинных циклах почаще вызывать )
Только вот всё равно это такие советы все пальцем в небо.... мало данных. мало.

[Kayur]

Добрый вечер, спасибо за проявленный интерес к моей проблеме.
Белые прямоугольник - судя по всему - результат того, что
процессор не успевает прорисовать все детали, которые должны
быть на экране. Прямоугольник закрывает одно из рабочих окон,
(например, окно редактора) то одно, то другое, а может и не закрыть.
При этом программа продолжает выполнять текущую операцию без
отображения на экране хода ее выполнения. После завершения
экран полностью восстанавливается.
Внешнее устройство работает медленно, поэтому для синхронизации его
с программой многократно использую Sleep( от 30 до 300).
Наличие или отсутствие отладчика не влияет, проверял.

[DpInRock]

Значить слип не в потоке.
Достаточно 1-10 слипа.

Кроме того, такое случается, если вы ухитряетесь в события вставить что-то неправильное. Тогда вообще будет висеть...

Кроме того, надо умеючи обновлять графический интерфейс (основной поток) из дочернего.

Приоритет дочерних потоков не надо задирать.
--
Короче, набор совершенно очевидных вещей.
И если они вам известны - просто ищите ошибки. Больше ничего.

Сообщение отредактировал DpInRock - Jan 11 2011, 16:22

[Xenia]

с программой многократно использую Sleep( от 30 до 300).

Если вы под OWLем пишите, то попробуйте вместо Sleep() вызывать:
GetApplication()->PumpWaitingMessages();
Там, внутри этой функции все сделано, как надо.

Но если цикл какой-то длинный крутите, но на каждом обороте ее вызывать не надо, а то замедление сильное будет. Но если нет другой возможности, то в длинном цикле ее можно вызывать периодически, через неколько оборотов. Например так:

Код

for( int i=0; i < 10000000; i++)  // цикл на 10 млн. оборотов
{
................... // что-то делаете в цикле

  if( i%1000==0) GetApplication()->PumpWaitingMessages();  // вызывем один раз через каждые 1000 оборотов цикла
}

Просто Sleep() в этой ситуации может не помогать, т.к. тормоза не с апдейтом картинки, а с прорисовкой "самодельных" элементов (например, функцией Paint). Тогда в условиях захвата времени в вычислительных циклах, очередь сообщений стоит на месте, и сообщения WM_PAINT тоже не обслуживаются. Вот и получаем белые квадратики.

[sigmaN]

Прямоугольник закрывает одно из рабочих окон,
(например, окно редактора) то одно, то другое, а может и не закрыть.
При этом программа продолжает выполнять текущую операцию без
отображения на экране хода ее выполнения.

Т.е. вместо этого прямоугольника по идее у вас должно было быть окошко с отображением хода выполнения? Что за окошко? как показываете его?

Тогда в условиях захвата времени в вычислительных циклах, очередь сообщений стоит на месте, и сообщения WM_PAINT тоже не обслуживаются.

Ну так Application->ProcessMassages(); как раз самое оно для таких случаев )))

А вообще да, конечно по уму надо эти медленные операции все в отдельный поток, чтоб ГУЙ не тормозили. Application->ProcessMesages(); к примеру не спасёт, если кто-то нажал на кнопку(отмена к примеру). Обработчик события от этой кнопки будет вызван только по завершении цикла(порою длинного и долгого). Так что тут как ни крути, даже если с прямоугольниками разобраться, всё равно, наверное, придётся второй поток организовывать...

[Kayur]

Непонятно, что делает Application->ProcessMessages(), как ее применять?
В Help на нее ничего нет. Примерчик бы...

[sigmaN]

Лентяй Вы )))
http://www.delphihelp.org/processmessages.html
http://forum.vingrad.ru/forum/s/d73c7ca0b8...y1685334/0.html
а вот тут даже "тёмную сторону" обсуждают
http://delphi.about.com/od/objectpascalide...s-dark-side.htm

в этом случае вообще не важно Delphi или Builder - только синтаксис разный...суть остаётся такой же )

[Kayur]

Честно говоря, не верил, что обращение на форум приведет к успеху.
SigmaN, тебе а-а-громное СПАСИБО за Application->Messages!
Все получилось сразу и легко после установки Application->Messages
в длинные и медленные циклы, без всяких там дополнительных потоков.
Спасибо всем, тема закрыта.

[sigmaN]

Нет, форум - это сила.
Я свой первый самостоятельный проект ни за что бы не осилил без форума)