Как стать автором
Обновить

Комментарии 46

Ну отлично! Запускаем программу и в ожидании старта втыкаем в этот splash-screen, который висит поверх всех окон. Со стороны программиста очень наивно думать, что его программа всегда будет стартовать за несколько секунд, и в это время юзер не захочет заняться чем-то еще.
Для того чтобы окно не было поверх всех достаточно закомментировать 1 строчку:
formstyle:=fsStayOnTop;
Вы описали, как сделать красивое окно с некваратными краями. А вот когда его вызывать и закрыть — в событии OnCreate главного окна или сразу после запуска, до создания Application забыли)
Извиняюсь, создавать надо в OnCreate главного окна и уничтожать после загрузки.
В примере это показано.
Я бы рекомендовал немного по-другому. Процесс загрузки приложения — сложная тема. Методом проб и ошибок я понял, что нужно делать так:

1. Дизайните Splash Screen, делаете все, что считаете с ним нужным
2. Весь процесс загрузки выводите в отдельный поток
3. В OnCreate главной формы пишите:
procedure TMainForm.FormCreate(Sender: TObject);
var
  ApplicationLoadTread: TApplicationLoadTread;
begin
  // exception
  Application.OnException:= ExceptionAction;
  SetErrorMode( SEM_FAILCRITICALERRORS );

  // splash init
  SplashForm:= TSplashForm.Create( Application );
  SplashForm.Show;
  SplashForm.Update;

  ApplicationLoading:= True;
  ApplicationLoadTread:= TApplicationLoadTread.Create;
  ApplicationLoadTread.FreeOnTerminate:= True;
  ApplicationLoadTread.OnTerminate:= MainForm.OnFormCreateFinished;
  ApplicationLoadTread.InfoLabel:= SplashForm.InfoLabel;

  ApplicationLoadTread.Start;

  // waiting 'till finished
  while ApplicationLoading do
    Application.HandleMessage;

end;


это запустит тред загрузки и выведет splash screen

4. Когда тред загрузки отработает он вызывает Callback функицию, наподобии:
procedure TMainForm.OnFormCreateFinished( Sender: TObject );
Begin
  ApplicationLoading:= False;

  // slash destroy
  SplashForm.Hide;
  SplashForm.Free;
End;



Это всязано с особенностью обработки Windows зависших приложений. Если ваш spash не бует отвечать Windows на «пинги» он будет помечен, как зависший. Тред помогает избежать этого поведения.

Главное правило при разработке GUI приложения — все действия прячьте в тред. Даже секундные. Так ваше приложение не будет «висеть» по мнению пользователя или ОС.
Спасибо!
Буду использовать в будущем.
Пожалуйста.

Еще вам нужно правильно обрабатывать нестандартные ситуации, возникающие во время работы. В Delphi они всегда падают в стандартное окно Access Violation или подобное, что шокирует даже опытного пользователя. Если сделаете вот так, будет намного лучше:

image
А еще лучше не изобретать велосипед и сделать хорошо и конечному пользователю и себе, как разработчику, с помощью madExcept'а (или EurekaLog'а), который бесплатен для некоммерческого использования и легко купить тем, кто хочет качественной обратной связи от своих клиентов.

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

Про такие штуки не знал, надо попробовать. Может, правда качественные компоненты.
Это не совсем компоненты, это небольшая инфраструктура (стаб [немного кода и кусок, который автоматически патчится в уже собранный исполняемый файл] + немного (или много) отладочной информации на клиентсайде и опционально приложение для удобства работы с фидбэком).
С отдельным тредом нужно быть очень осторожным. Если этот тред будет создавать окна, этот же тред должен будет доставать сообщения из очереди и их диспетчеризировать. Возможно Delphi это как-то хендлит, не знаю, но если нет, то вы просто получите мёртвые окна, сообщения для которых не будут приходить в главный тред.
Да, в Delphi есть класс TThread и вызов Synchronize() который предназначен для этих целей.

К томуже, какие окна может создавать тред загрузки приложения?
Мало ли какие. Если в приложении сотня окон разных используется, то имеет смысл их посоздавать пока сплеш скрин висит, чтобы они потом показывались быстрее. Так вот если их создавать в другом треде, нужно учитывать эти вещи. Поэтому можно сплешскрин запускать в отдельном треде, а инициализировать приложение в главном, не забывая обрабатывать сообщения из очереди.
Но создание окон занимает моменты, зачем из создавать заранее? К тому же, в Windows Vista/7 показ уже созданного окна выглядит некрасиво — оно резко появляется.

У вас есть какие-то тяжеловесные операции в OnCreate окон, которые требуют много времени и не зависят от текущей ситуации в приложении? Как это так?

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

По поводу Delphi и Synchronize ничего не скажу, я на Delphi не пишу, а про создание окон написал из понимания того, как работают окна в Windows.
Так вещи засуньте в классы, которые и создавайте при загрузке. Потом просто укажите классу окна, что вот, такойто вот объект создан, пользовать его. Проблема эта без примера сложно решается)

Да, могут, конечно. И будут баги, это факт. Нужен Synchronize.
На мой взгляд, вызов Splash'а в контексте создания главной формы приложения — есть «странность» в архитектуре приложения. Было бы разумно начать его показ еще в контексте main'а, а уже потом создавать формы и т.д. Относительно вынесения нагрузки в поток — согласен.
Честно — у меня не получилось с первого раза начать показ splash в main (до создания объекта Application), а закрыть его после окончания работы треда загрузки. Если поковыряете и получится что-то — выложите, это, безусловное, более правильное решение.
Уточните, в чем была проблема?
Простите, а как это всязано с темой топика?
Почему все пытаются похоронить Delphi?
По нашим культурным православным традициям так полагается — хоронить то, что умерло.
Коллега, скажите, вы писали на Delphi серьезно? Что-то, что выходит за рамки одной формы и перетаскивания кнопочек мышкой на форму?
Лет 7 назад я писал на дельфях клиент-серверное приложение для автоматизации работы типографии. Отдельно запомнилась работа с СУБД и работа с сетью.

Попытки написать что-то более-менее приличное на стандартных VCL сетевых компонентах и последующее переписывание на нормальных виндовых событийных апи-сокетах. :)

Изначально я лишь посоветовал VS и не слово не говорил про смерть. ;) Заметили? )))
За столько времени многое изменилось. Если есть возможность сделать не на API, а на обертках, это выбор, который некоторым пригодится. Я тоже пользуюсь в Delphi WinAPI иногда, когда этого требует ситуация.

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

Проведем исследование ввиде викторины.

Заходим на spb.hh.ru

Запрос — результат
javascript — 370
java — 332
c++ — 366

xxx — 31

А теперь вопрос залу. Какой мертвый язык скрыт под аббревиатурой xxx? :)))
Я могу писать на Delphi драйверы, приложения Windows 32/64, CMS (да да, движок сайта).

Общетематичный? Вопрос лишь во владении предметом.
Вот и я о том же. В теории он может все, а развивается по факту лишь при продаже очередным наивным. )
Это не теория, это возможно, инфа 100% :)

Раньше были проблемы, да. После выхода 64битного компилятора я уже с трудом могу сказать, чего же мне не хватает…

Вы не думайте, что я только Delphi и знаю. Ровно также, или больше, я знаю C/C++. Разницы, если присмотреться, почти нет. Только Си синтаксис мне напоминает шаманство со своими << | & и прочими, по этому предпочитаю писать and or xor. Личное дело каждого, если конечный продкут идентичен.
Я может быть не уловил суть разговора. Вы сравниваете прикладной язык с низкоуровневым?

В таком случае предлагаю добавить к сравнению ассемблер и php.
Теперь я не понимаю. Си — низкоуровневый, Делфи — прикладной? Не соглашусь.

PHP — песня. Не знаю, как кто к нему относится, но сама его суть от меня ускользает. Сделайте ISAPI Extension для IIS или Apache — будет работать быстрее, возможности отладки шире. Если нет разницы, зачем изобретать новый язык?

Асм — бог языков. Но очень уж сложен для программиста. Слишком долго писать, чтобы просто вывести окно на экран…
Вы полностью правы, хотя суждения местами неверные.
Напишите, хотя бы в личку или скайп, чтобы флуд не разводить, что вы об этом думаете. Конструктивная критика всегда хороша.

Я вот так считаю, может, я где-то упускаю что-то.
спасибо, ребят! теперь я узнал максимальную вложенность комментариев ) после 13 все идут в столбик!
Потому что «на нем программируют мышкой». Самый распространенный миф из-за малого порога вхождения. Никто не задумывается, что Delphi ничем не уступает другим средствам разработки «в глубине», потому что не знает.
Тоже занимался таким делом, правда в Delphi7
Если кому вдруг интересно — посмотреть тут: clck.ru/d/1cYIyA8i1Ck0o

Пример создания такой красоты в динамике. Предупреждаю — нужна видеокарта с аппаратной поддержкой FBO. Исходники можно посмотреть здесь: sites.google.com/site/boxdemi/
Красиво, но ресурсов жрет…
Делал для красоты, многовато частиц просто, да и на оптимизацию времени не было.

p.s. забыл сказать: для завершения красоты — подведите курсор в верхний левый угол.
Уточнение пришло вовремя)
Меня всегда раздражают эти сплэш скрины, кто их вообще придумал?
Есть приложения, которые стартуют долго. Не 3-5 секунд, а полминуты, например. Правильный сплешскрин кроме показывания красивой картинки ещё показывает прогресс запуска.
Кроме показывания процесса запуска он еще закрывает все окна, как будто если уж я запустил такого монстра, так мне интересно смотреть на его запуск.
Ну правильно, вместо того, чтобы дизейблить все контролы в приложении, а по окончанию запуска енейблить их назад, проще показать модальный сплешскрин. Всё равно вы до окончания запуска приложения ничего с ним делать не можете, а так хоть на сплеше видно, что происходит и долго ли осталось до окончания инициализации.
До окончания запуска приложения я обычно ни с каким другим приложением делать ничего не могу ибо оно закрывает собой все.
Так это просто неправильное, плохое приложение. Сплешскрин не должен быть topmost окном, он просто должен быть application modal, этого достаточно.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации