вывод из дочернего потока на форму значения

← →
npr2 (2008-04-29 12:59) [0]

Только начинаю работать с потоками. Может и не по адресу обращаюсь.
Создала форму. Создала дочерний поток в котором читаю данные из сом-порта. Нужно после обработки этих данных, выложить в Edit.text значение этой переменной. Делаю так
type
TCommThread=class(TThread)
private
Stroka:string;
HFile:TextFile;
Procedure ShowStroka;
protected
Procedure Execute; override;
end;
var
Scale_Form: TScale_Form;
TT:TCommThread;
Это описание потока.
Запускаю поток при создании формы TT:=TCommThread.Create(False);
procedure TCommThread.Execute;
var
begin
...
stroka:=Separ_float(w1);
TT.Synchronize(ShowStroka);
...
end;

procedure TCommThread.ShowStroka;
begin
Scale_Form.Edit1.Text:=Stroka;
end;
При выводе переменной задача вылетает по ошибке Access Violation at address. Если пытаюсь выводить значение в заголовок окна, то вообще ничего не происходит.
Где я ошибаюсь?

← →
ANB (2008-04-29 13:03) [1]

1. TT.Synchronize(ShowStroka);
- убрать TT, просто вот так :
Synchronize(ShowStroka);
Хотя ошибку по идее вызвать не должно, но все же.
2. Ошибка скорее всего таки в другом месте.
3. Для неблокирующей работы с ком-портами доп. потоки не нужны. Выкинь нафиг свой код и сделай по человечески.

← →
DrPass © (2008-04-29 13:10) [2]

> При выводе переменной задача вылетает по ошибке Access Violation
> at address

Scale_Form в этот момент точно указывает на готовую созданную форму TScale_Form?

← →
npr2 (2008-04-29 13:13) [3]

ANB TT-Это уж разные вариации. А как по-человечески?

← →
Сергей М. © (2008-04-29 13:26) [4]

> TT-Это уж разные вариации

Вот эта "вариация" как раз и способна вызвать такую искл.ситуацию.
Что ты как раз и наблюдаешь.

← →
npr2 (2008-04-29 13:32) [5]

Это разные попытки после того, что никак уже не получалось. Проблема в чем-то другом, но не могу понять в чем именно.

← →
ANB (2008-04-29 13:41) [6]

> Запускаю поток при создании формы

← →
sniknik © (2008-04-29 13:43) [7]

> procedure TCommThread.ShowStroka;
> begin
> Scale_Form.Edit1.Text:=Stroka;
> end;
procedure TCommThread.ShowStroka; begin if Assigned(Scale_Form) then Scale_Form.Edit1.Text:= Stroka; end;
Edit1 надеюсь не динамически созданный.

← →
npr2 (2008-04-29 13:57) [8]

if Assigned(Scale_Form) then
Scale_Form.Edit1.Text:= Stroka
else
ShowMessage("Error!");

Написала так и всегда уходит на ошибку ( в потоке цикл опроса Сом порта), хотя форма высветилась. Edit1 не динамический. Почему так происходит тогда?

← →
ANB (2008-04-29 14:07) [9]

> npr2 (29.04.08 13:57) [8]

А форма Scale_Form живет в том же модуле ? Если нет - выкинь нафиг эту переменную из модуля потока.

А еще лучше выкини поток и работай с ком портом с помощью штатных функций.

← →
sniknik © (2008-04-29 14:32) [10]

> Написала так и всегда уходит на ошибку
т.е. форма не создана (=nil)

> хотя форма высветилась.
не та значит форма.

← →
Anatoly Podgoretsky © (2008-04-29 14:39) [11]

> sniknik (29.04.2008 14:32:10) [10]

А при ТТ. никогда нельзя сказать одназначно, та или нет, это всегда рулетка.
Да Scale_Form тоже явно глобальная переменная.

← →
Сергей М. © (2008-04-29 14:47) [12]

> т.е. форма не создана (=nil)

Форма-то уже и создана, да вот ссылка на нее еще не попала в Scale_Form, потому как все это чудесатое действо происходит в OnCreate формы.

А там стартует поток, который запросто может успеть обратиться к переменной Scale_Form (что и наблюдается), которая в этот момент еще равна nil и которая будет инициализирована лишь после завершения работы конструирующего форму метода.

← →
sniknik © (2008-04-29 15:07) [13]

> ... потому как все это чудесатое действо происходит в OnCreate формы.
думаю, что это всетаки не та форма... (показывается одна, пишется в/проверяется другая)
т.к.
procedure TForm1.FormCreate(Sender: TObject); begin ShowMessage(IntToStr(Integer(Form1))); end;
вовсе не 0 выдает.

← →
Сергей М. © (2008-04-29 15:25) [14]

> вовсе не 0 выдает

Это если создавать с пом. Application.CreateForm

А если Form1 := TMyForm.Create(..), то как раз эта ситуация и наблюдается.

← →
Игорь Шевченко © (2008-04-29 15:32) [15]

> TT.Synchronize(ShowStroka);

TT убрать однозначно.

Если хочется запускать поток из FormCreate, то первой строчкой
там должно стоять
Scale_Form := Self;
Но лучше не запускать поток из FormCreate

← →
Германн © (2008-04-29 15:51) [16]

И всё таки лучше работать с СОМ-портом асинхронно, а не в потоке.

← →
npr2 (2008-04-30 05:35) [17]

Большое спасибо!!
Scale_Form := Self; решило проблему.

А можно варианты работы с СОМ портом? Просто это задача автоматического взвешивания автомобилей на весах. Весь алгоритм построен на изменениях показания веса с прибора асинхронно. Раньше при пустых весах брали вес по таймеру раз в секунду, при заезде - снимали все показания с прибора, но тогда захватывались ресурсы компа, оператор ничего не может сделать. Если до этого момента (заезда) был запущен сложный отчет, то было плохо - все подвисало. Думала, что так можно было решить эту проблему.

← →
Evgeny V © (2008-04-30 08:36) [18]

> Германн © (29.04.08 15:51) [16]
> И всё таки лучше работать с СОМ-портом асинхронно, а не
> в потоке.

Асинхронно(overlapped) и поток(Thread) -это противоречит друг другу? Или я чего-то упустил? Или речь о частном случае?
Пост не в пику ответу, а просто как желание обсудить и узнать что-то , что я возможно пропустил в этой области...

← →
Сергей М. © (2008-04-30 08:57) [19]

> это противоречит друг другу?

Нисколько.

← →
npr2 (2008-04-30 11:13) [20]

в потоке читаю сом синхронно, но думаю и асинхронно тоже можно.

> асинхронно тоже можно

А зачем ?

Ипользование в потоке (в любом, будь то основной или дополнительный) асинхронного транспорта имеет смысл только если поток кроме транспортных решает и иные задачи. Ну и еще если отмена синхронных блокирующих транспортных операций по объективным причинам не возможна, как, например, операции с пайпами в раде виндовых ОС.

> npr2 (30.04.08 11:13) [20]

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

← →
ANB (2008-04-30 12:34) [23]

> npr2 (30.04.08 11:13) [20]
> в потоке читаю сом синхронно, но думаю и асинхронно тоже
> можно.

Зазвиняюсь. Похоже, в Вашем случае нужен доп.поток.

ЗЫ. Всю задачу лучше сразу описывать.

ЗЫЫ. Тогда надо учится корректно работать с потоками.

← →
npr2 (2008-04-30 12:56) [24]

Это рабочее место оператора весовой на угольном складе на разрезе. Оператор ведет кучу справочников, учет путевых листов, ТТН, печатаеи много разных ртчетов по своей работе. И постоянно открыто дочернее окно взвешивания автомобилей, где я и создаю дочерний поток по чтению из сом порта. Раньше читала без потока асинхронно раз в сек, но прибор выдает 20-60 отсчетов в сек. На экране вес выдавался с задержкой. Были проблемы, когда оператор запускал еще что-то длительное по времени (формирование отчета) параллельно с заездом авто на весы. Сейчас пытаюсь синхронно читать все отчеты в отдельном потоке.

Спасибо всем за советы. С праздником!

← →
ANB (2008-04-30 13:45) [25]

> npr2 (30.04.08 12:56) [24]

Может все равно заклинить, если отчетом пожрешь время процессора и он на компе один.

> оператор запускал еще что-то длительное по времени (формирование
> отчета) параллельно с заездом авто на весы

Чему ж тут удивляться ?

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

> пытаюсь синхронно читать все отчеты в отдельном потоке

Не читать, а формировать.

← →
ANB (2008-04-30 14:30) [27]

> пытаюсь синхронно читать все отчеты в отдельном потоке

Судя по контексту, он собирается читать "отчеты" весов из ком-порта.

вывод из дочернего потока на форму значения Найти похожие ветки