Размножение окон

[Sergey2]

Сообщение от Stilet

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

интересует, в первую очереь, корректность моего решения.

[Stilet]

Исходя из топика решение может и корректно но абсолютно неэффективно.

[B_N]

Сообщение от Sergey2

интересует, в первую очереь, корректность моего решения.

А что Вы понимаете под "корректностью" решения? Вам же три страницы подряд пишут что оно некорректно и объясняют, почему.
По пунтктам:
1.

with TForm2.Create(Application) do

Вы вызываете конструктор, а дальнейшая судьба переменной, которую он создает, Вас не волнует. Я уже не говорю о том, что это даже отлаживать будет сплошное мученье, понять к какой форме относится какая строка будет очень непросто. Да и где гарантия, что с таким походом Вы просто не будете терять память.
2. С чего Вы взяли, что спецификатор private отвечает за "дублирование" членов класса? Попробуйте, перенесите объявление str в паблик, ради интереса.
3.

    try
      Label1.Caption:=Edit1.Text;
      Show;
    except
      Free;
    end;

Что означает сия конструкция? Что такого драматичного в коде

      Label1.Caption:=Edit1.Text;
      Show;

что Вы взяли его в SEH? И почему Вы думаете, что до try дело вообще дойдет, если Вы пишете, что все действия над данными Вы производите при создании формы?

....у него в frmFunc.onCreate происходит запуск всего чего надо и дальше все само работает.

Как из представленного можно оценить "корректность"?
4. Как Вы собираетесь разделять время между вашими обработчиками? Какой смысл делать много форм, если фактически они будут вынуждены ждать друг друга? Или Вы расчитываете вызывать Application.ProcessMessages в обработчике таймера? Ничего не получится, WM_TIMER само надо извлекать из очереди. Вы расчитываете файберы вместо потоков организовать? Чем тогда плохи потоки? Вы Планируете делать какую-то особенную диспетчеризацию? Зачем так усложнять?

[Sergey2]

Сообщение от B_N

А что Вы понимаете под "корректностью" решения? Вам же три страницы подряд пишут что оно некорректно и объясняют, почему.
По пунтктам:
1.

with TForm2.Create(Application) do

Вы вызываете конструктор, а дальнейшая судьба переменной, которую он создает, Вас не волнует.

Именно так.

Я уже не говорю о том, что это даже отлаживать будет сплошное мученье, понять к какой форме относится какая строка будет очень непросто.

Да ни надо ничего отлаживать. Уже все отлажено и работает. Но в одном экземпляре. В крайнем случаи можно сделать Form2 главной, пускат ьее в одном экземпляре и отлаживать.

Да и где гарантия, что с таким походом Вы просто не будете терять память.

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

2. С чего Вы взяли, что спецификатор private отвечает за "дублирование" членов класса? Попробуйте, перенесите объявление str в паблик, ради интереса.

Ну про дублирования я ничего такого не говорил.

3.

    try
      Label1.Caption:=Edit1.Text;
      Show;
    except
      Free;
    end;

Что означает сия конструкция? Что такого драматичного в коде

      Label1.Caption:=Edit1.Text;
      Show;

что Вы взяли его в SEH?

Ну мало ли там памяти нехватит или еще что за фигня произойдет при создании...

И почему Вы думаете, что до try дело вообще дойдет, если Вы пишете, что все действия над данными Вы производите при создании формы?

Я же проект целиком кинул. Он работает, т.е. до try дело доходит. А почему не должно дойти?

Как из представленного можно оценить "корректность"?

А в чем проблемма то? Некоректно это когда производиться попытка изменять код счетчика цикла или когда объект создаеться, но не уничтожается. Все это работает и ерроров не выкидывает, но некоректно.

4. Как Вы собираетесь разделять время между вашими обработчиками? Какой смысл делать много форм, если фактически они будут вынуждены ждать друг друга? Или Вы расчитываете вызывать Application.ProcessMessages в обработчике таймера? Ничего не получится, WM_TIMER само надо извлекать из очереди. Вы расчитываете файберы вместо потоков организовать? Чем тогда плохи потоки? Вы Планируете делать какую-то особенную диспетчеризацию? Зачем так усложнять?

1. ВСЕ РАБОТАЕТ. Ненадо разделять время между обработчиками, нинадо никаких процессмесаджей, нинадо никаких таймеров из очереди извлекать. НИЧЕГО НЕ НАДО.
2. Продолжение ответа на первый вопрос. Потоки тем и "плохи", что под них код надо модернизировать, а в данном случае нет.

[B_N]

Сообщение от Sergey2

Да ни надо ничего отлаживать.

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

Сообщение от Sergey2

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

А Вы что же, полагаете, что при закрытии окна Windows автоматически вызывается деструктор VCL? Вы не пробовали метод FreeInstance переопределить, и посмотреть, попадет ли туда выполнение хоть раз? Или Вы не занимаетесь такой ерундой, как отладка?

Сообщение от Sergey2

Ну про дублирования я ничего такого не говорил.

А вот это кто писал?

Сообщение от Sergey2

Если переменную объявить как не в привайте, то изменение значения переменной в одной форме вызывает изменение значений во всех формах. А если объявить в привайте, то каждое значение индивидуально.

Далее, Вы пишете:

Сообщение от Sergey2

Ну мало ли там памяти нехватит или еще что за фигня произойдет при создании...
Я же проект целиком кинул. Он работает, т.е. до try дело доходит. А почему не должно дойти?

Позвольте, а что создает вот этот участок программы????

      Label1.Caption:=Edit1.Text;
      Show;

Попробуйте в Вашем обработчике TForm2.FormCreate (видимо там Вы ожидаете проблем?) написать вот так:

procedure TForm2.FormCreate(Sender: TObject);
begin
  str:=TimeToStr(Now)+' - ';
  RaiseException(0,0,0,0);
end;

И посмотрите, доберетесь ли до try.
Читал я то, что Вы называете "проектом". Судя по счетчику, я последний, кто пытается ответить на Ваш же вопрос:

Сообщение от Sergey2

Чего еще нехватает?

-------

Сообщение от Sergey2

А в чем проблемма то? Некоректно это когда производиться попытка изменять код счетчика цикла или когда объект создаеться, но не уничтожается.

Вы полагаете, что этим исчерпываются возможные проблемы при разработке? Или полагаете, что если проект скомпилировался, то этого достаточно?

Сообщение от Sergey2

1. ВСЕ РАБОТАЕТ. Ненадо разделять время между обработчиками, нинадо никаких процессмесаджей, нинадо никаких таймеров из очереди извлекать. НИЧЕГО НЕ НАДО.

У вас "работает" "сложение" двух строк, которое занимает от силы полсотни тактов. Давайте посмотрим на Вашу вводную:

Сообщение от Sergey2

Жмешь в ее окне кнопку и она определенный файл обрабатывает и быковки выводит десять раз в секунду в Memo. Ручейком. Это есть. Надо следующее:
Программа-оболочка, в которой выбираешь файл, жмешь "обработать" и появляется окно вышеописанной программы в которой в Memo льются буковки. Потом из программы-оболочки выбираешь другой файл, жмешь "обработать" и появляется еще одно окно в котором бегут буковки второго файла по мемо.

и сэмулируем Вашу "обработку" из того расчета, что файл будет обрабатываться, скажем, минуту:

procedure TForm2.Timer1Timer(Sender: TObject);
var StartTime : dword;
begin
    StartTime := GetTickCount();
    repeat until GetTickCount() > StartTime + 60000;

    Caption:=str+TimeToStr(Now);
end;

Запустили? Ну и попробуйте теперь нажать кнопку.

Сообщение от Sergey2

2. Продолжение ответа на первый вопрос. Потоки тем и "плохи", что под них код надо модернизировать, а в данном случае нет.

Вы извините, но огранизовать и запустить поток - это максимум десяток строчек. Если Вы не знаете, как это делается, это еще не значит, что это так сложно.

Одним словом, если Вы спрашивали советов в своем первом посте, то советов Вам тут надавали с три короба, а уж будете ли Вы к ним прислушиваться - дело хозяйское.

[Stilet]

Кстати, насчет потоков, автор тут лениться маненько. так вот: есть компоненты которые сами организовывают поток и им управляют, достаточно кинуть такой компонент на форму и прописать ему обработчик, и ничего более не нужно мутить сложного, ибо он сам все организует не только правильно, но и надежно - И далеко не надо за ними хотить они есть в бесплатном JEDI. Так что если нет желания самому организовывать потоки, предоставь это мастерам из Борланд - честь им и хвала!.