собственно есть поток, в нем создается форма, нужна ли для этой формы синхронизация при доступе к ней из самого потока?

У меня все сделано через синхронизацию, но я вот тут подумал, а нужна ли она вообще здесь?!

По идее ничего страшного не произойдет, если сделать так.
Но если нужна гарантия, то лучше послать форме WM_SETTEXT.
Добавлено @ 11:36
Посмотрел код. Не зачем возиться с WM_SETTEXT.
Присвоение капшена и так его вызывает.
Можешь смело присваивать.

Snowy, я нетолько про кэпшен хотел узнать
а вобщем, можно ли обращаться к форме созданной в потоке, атакже ко всем контролам на ней (из самого потока) без синхронизации?

z-END, она нужна в том случае, если кто то в этот момент будет читать твой Caption.
Добавлено @ 12:01

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

тоесть я правильно понимаю что форма созданная во вторичном потоке приложения "живет" всеравно в основном?

Все формы живут в основном.
А вот что у формы можно менять из внешнего потока, а что нельзя, нужно выяснять по коду VCL.
По крайней мере параметры окна (положение, текст и т.п. можно менять.)

Snowy, представь, что ты начал менять Caption формы из вторичного потока и успел написать туда "По" (а хотел "Поток") и в этот момент его выполнение прекращается и главный поток пишет строку "Форма", после чего возобновляется выполнение вторичного потока и он дописывает остаток "ток". В результате получаем "Фоток". Это желаемый результат?

<Spawn>, Представь, что ты посылаешь из другого приложения сообщение WM_SETTEXT.
Главный поток получает это сообщение и производит обновление заголовка. Пока он это не сделает, ничего другого он делать не будет.
Присваивание Caption'a не присваивает значение переменной. А вызывает Perform(WM_SETTEXT).
Получение Caption'a не берет данные из какой-то переменной, а делает WM_GETTEXT.
Все это делает главный поток. Вторичный поток замирает, ожидая, когда основной поток завершит действия и вернет управление.
Добавлено @ 12:51
Поэтому я и говорю, что некоторые действия можно делать вполне безболезненно.

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

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

Snowy, <Spawn>, спасибо=) ну вобщемто так и думал что нельзя...

Отчего ж нельзя. Можно, но не все.
Для гарантии лучше конечно делать все в синхронизации.
Но многие вещи доступны и без нее.

Нельзя создать и работать с формами в дополнительном потоке. Увы, такова технология VCL-форм. Работать безопасно можно только с окнами, созданными на чистом Win32API.

Не стоит даже пытаться работать с формами. достаточно просто посмотреть на модуль Forms.pas изнутри. Можно даже по ключевому слову Application.

И что там такого страшного ?

Как это относится к работе с формой ?

Относится напрямую. Формы в Delphi неразрывно связаны с TApplication. Любая форма работает только в основном потоке.
Добавлено @ 10:00
На основной вопрос топика, естсетвенно, ответить нельзя. Потому что нельзя создавать формы в дополнительном потоке.
При желании можно, конечно. Но это если хочется проблем.

где это выражено?
Добавлено @ 10:14
пример код плз и место откуда он

Создавать можно. Создание - всего лишь выделение памяти. А она общая.
А вот работать оно все равно будет в основном потоке, т.к. всем рулит главное окно - Application.
А оно в главном потоке.

Давайте разберемся , что есть форма? Это обычное окно виндов + дополнительные прибамбасы. Я прав?
Если да, то что есть окно - это графическое окно + ф-ция обработки сообщений этого окна, прав?
Если да , то кто мешает эту ф-цию засунуть в поток?
( Я так понимаю что все что мы кидаем в метод Exectute класса Tthread это и есть ф-ция которая выполняется отдельно от основного потока, да?
Тогда прямо в этом методе можно обозначить ф-цию типа WndProc, и юзать форму отдельно от апликейшена, если я не прав поправьте где?

Добавлено @ 11:00


Я бы сказал, что не совсем.



Весь смысл в том, что куды бы ты ни засунул эту функцию, все сообщения будут обрабатываться в основном потоке. Прежде всего.
Добавлено @ 11:06


Предлагаю попробовать на практике этот метод.
Сразу скажу, что придется
1. владельцем сделать Desktop
2. Все(абсолютно все!) сообщения обрабатывать вручную, от всех контролов на форме, которые хочется видеть.
3. По существу, это будет (почти) обычное окно WinAPI. НО! От TApplication никуда не денешься, а он НЕ ПОТОКОБЕЗАПАСЕН.

Обрати внимание на использование TApplication. ИСпользуется без всякой сипнхронизации в недрах VCL.

Хочу добавить, что этот вопрос я специально изучал. Ответ по использованию форм в отдельных потоках однозначно отрицательный. Честно - просто не хочу повторяться и переливать из пустого в порожнее. Предлагаю попробовать и самому убедиться.
И опять же отошлю к Forms.pas - там все видно прекрасно, как и где используются переменные и классы.

Это сообщение отредактировал(а) Демо - 28.2.2006, 11:00

Плз с объяснениями

Обратно же почему?
Если имеется связь по родительскому окну, то







Это имхо самое правильное замечание только практика покажет где глюки бывают
Добавлено @ 11:13

Хоть одну ссылку дай на метод?

Поправляю.
Для TForm эта функция находится в Application.
Именно он получает сообщения, а потом раздает их нужным формам.
Именно поэтому TForm нельзя засунуть в отдельный поток.
Вот, если отказаться от VCL, то можешь выбрать другую процедуру обработки сообщений.
Я для TForm она предопределена.

А перегрузить нельзя?



не проканает

Грузи не грузи... Принцип действия такой.
TForm при создании регистрируется у Application.
Application получает за нее все сообщения, смотрит кому они адресованы и передает в оконную процедуру нужной формы.
То есть окна формы получают сообщения не сами - им их передает Application.
Тут тесная взаимосвязь с Application и я не представляю, как ее можно разорвать.
Если только код VCL править...
Добавлено @ 11:34
Отсюда и действие Application.ProcessMesages.
Именно Application разгребает все сообщения, а не формы.
Поэтому в длинных циклах виснут все окна, а не одно, если не делать ProcessMessages.
Так устроен VCL. Такова его архитектура...
Не скажу, что это минус - "умные существа делали". Но ограничений добавляет.

Ну подожди , апликейшен это тоже VCL и тоже окно имеющий свой хендл, и имхо сообщения передаются от родительского окна к дочернему, так ?
ЗЫ да и кстати , уходим мы от темы
сообщения то вооще то не зависят от потока
Да и обработка будет

Добавлено @ 11:42

Это понятно , если все выполняется в одном потоке

И мне так никто и не показал где в коде форм есть привязка к апликейшену

Тебе весь Forms.pas выложить сюда?

Посмотри классы TScreen, TApplication, TCustomForm. Практически везде используются, во всех методах. БЕЗ учета многопоточности.

нет , только ссылку где TCustomForm юзает TApplication, и все

Да почти первая попавшаяся ссылка -
procedure TScreen.AlignForms(AForm: TCustomForm; var Rect: TRect);

Много где используются TForm/TCustomForm.

Не обязательно. Как закажем.
Вот VCL заказывает строгую иерархию - от Application формам и т.д.


Сообщения нет. А их обработка да.

А все и выполняется в одном потоке.
Application ловит сообщение и передает принятое сообщение форме.
Не посылает, а передает. В своем потоке.

где здесь

Или я не правильно вопросы задаю или .....
Добавлено @ 12:23

Кто мешает поменять заказ?

Это вызывает соответсвующую ф-цию?

Это не Form юзает Application, а наоборот.

Ты готов сам ловить все сообщения и передавать их во внутренней структуре VCL?
Учитывая, что она может поменяться в следующей версии?
Учитывая, что после всех трудов это может вообще не заработать?
Учитывая, что вероятность получения глюков - 90%?
Если готов - пробуй.

Исходи из того, что не TCustomForm использует, а наоборот, её юзают.

Именно. Мы вызываем метод TForm и отдаем ему сообщение.

Что я нашел в формах

Более об Application, упоминаний нет ( при создании окна)
Добавлено @ 12:40

Тобишь сделать можно , но дабы не усложнять себе жизнь так не делают!

Так правильно?

Теоретически можно все сделать.

Согласись, что проще делать синхронизацию, чем городить огород с отделением TForm от TApplication.
Добавлено @ 12:48
Смотри код
constructor TCustomForm.CreateNew(AOwner: TComponent; Dummy: Integer);
в самом низу строка:
Screen.AddForm(Self);
Это и есть регистрация формы.

Нет, неправильно.

TApplication и TScreen используют методы форм, созданных в приложении, без синхронизации.

Я бы увеличил вероятность глюков дло 100% без всяких оговорок.

почему теоретически?

Да на все 100%
Добавлено @ 12:59
Демо,
Я так понимаю вы это имели ввиду, что апликейшен создает окно а не форм?
но последнюю строку никто не отменял, и вызвав ее еще раз но с другим FObjectInstance, который будет в потоке, и все будет работать без проблем Одно но

никому не хоцца


Это не регистрация для винды, FForms это список, это регестрация внутренней структуры

Потому что практически сделать ВСЕ невозможно

Вот о том и речь, чтобы отрезать от TForm все взаимодействия с TScreen и TApplication. Теоретически это возможно. Но практически я бы даже и пытаться не стал бы.

P.S. затянулась наша теоретическая дискуссия.
Добавлено @ 13:03

Это регистрация у TApplication - чтобы она сообщения отдавала

почему? Я даже где то видел такую подпись:
"Я бы изменил мир , но Бог исходники не дает" (с) не помню автора


Согласен заворачиваем с этим