Проблемы нет. Но есть неудобство. Если ты забыл открыть главную форму ручками и начал редактировать другую форму, то на этой форме слетают все ссылки на главную.
Например — ссылка на компонент StyleBook. Он как правило, один на приложение и размещается на главной форме. А остальные формы на него ссылаются.
Таким образом, редактируемая форма теряет стиль оформления. И это происходит тихо и незаметно, безо всяких ошибок )). Хорошо, если тестировщик заметит до того, как оно уйдет в продакшн
Замечательный пример. Но я говорил о том, что нельзя вставлять комментарии между Application.Initialize; и Application.Run; — между строчками комад создания форм.
Ваш пример в этом смысле не показателен ))
Ошибки как таковой нет. Просто при загрузке проекта в design-time не создается frmMainForm.
Если убрать комментарии — форма создается.
Delphi 10.3 Upd. 3
begin
{$IFDEF DEBUG}
// Для отображения утечек памяти, если они есть
ReportMemoryLeaksOnShutdown := True;
{$ENDIF}
Application.Initialize;
// Сначала модули данных
Application.CreateForm(TDatabaseModule, DatabaseModule);
Application.CreateForm(TMenuUpdaterModule, MenuUpdaterModule);
Application.CreateForm(TDBSettingsModule, DBSettingsModule);
// Только потом - основную форму!
Application.CreateForm(TfrmMainForm, frmMainForm);
Application.Run;
end.
Всё верно. В названии я упомянул хранимые процедуры неудачно.
Я переводил проект с MSSQL Express на SQLite (!) и пришлось переносить код хранимых процедур в обычные запросы. В процессе этой работы и написал данный класс. Оттого он у меня и ассоциируется с процедурами. Но это конечно неверно.
Это один из способов вынести код SQL-запросов в отдельное хранилище. Но никак не полноценные хранимые процедуры. Вы правы.
Здрасте, приехали! А если инет пропал, удаленный сервер перегружен? )))
Запрос удачный но выполняется долго?
По-вашему — разработчики Android от нечего делать запрещают морозить GUI всеми доступными способами?
Когда виснет GUI — это всегда некрасиво )) Тётеньки со светлым цветом волос начинают давить на все кнопки и орать в техподдержку «этавашапрограмма не работает!» :)
Это почему же не наш? ))) Очень даже наш! Встраиваемая — значит локальная. Значит с БД всегда работает только один клиент — наше приложение.
Да и в Android везде используется SQLite и обязательно все запросы к БД идут в отдельных потоках или корутинах.
Так что случай — что ни на есть наш. SQLite после некторых танцев с бубном вполне неплохо живет в потоках.
Я со STRINGTABLE почти не сталкивался. Если не ошибаюсь, его основное назначение — многоязычный интерфейс. И это — таблица строк с цифровыми идетификаторами. Большие SQL-запросы вытягивать в одну строку?!
Я до этого пользовался TFDScript для обновления БД и сами скрипты хранил в ресурсах. В таблицах строк их для этого компонента никак хранить не получится.
Тут сделал по образу и подобию.
Да и в коце-концов — чем удобнее хранение скриптов в STRINGTABLE? Я не нашел ни одного преимущества, только неудобства.
Добавить файл в ресурсы — одна строка. Извлечь оттуда — ну 10 строк (GetStringResource). Всё. И я получаю файл в том формате, в каком его наиболее удобно парсить а не мучаюсь с форматом STRINGTABLE. Вот просто получается реально меньше кода и проще. Вот и все…
В Delphi конечно ошибок немеряно. Но другие IDE грешат тем же, увы.
Меня больше всег раздражают не ошибки в IDE, а неполнота документации. Вот это — реальная беда. Я в последние пру лет активно использую в проектах Binding. Удобно. Часто вообще код писать не нужно при работе с БД — только SQL-запросы. Но он крайне плохо документирован. И на форумах про него днем с огнем ничего не найдешь… Обидно
Ну почему же? Файл dpr — служебный. IDE сама его создает и правит.
С файлом dproj — еще веселее )))
Если туда что-то добавлять НЕ в конец файла, вообще крыша у Delphi может поехать и файл перколбасит так, что не узнать.
Вот например, я вставил комментарий в dpr. Просто комментарий между " Application.Initialize;" и «Application.Run;».
И спустя какое-то время получил странное поведение проекта в design-time. Не создавалась главная форма при открытии проекта. При этом — никаких ошибок.
Но вот только ссылки свойств компонент на других формах на компоненты главной формы при сохранении стали затираться. Например — ссылка на StyleBook.
И я только через несколько месяцев понял, что виноват безобидный комментарий в файле dpr
Этот файл создает и изменяет сама IDE. Если его некорректно отредактировать ручками, получите кучу странных ошибок и форма «сломается».
Одним словам — производитель не предусматривал такой сценарий.
Безусловно, и dpr и dproj и dfm можно править руками. Но лучше делать это только в крайнем случае. Я не раз получал совершенно неожиданные и непредсказуемые разультаты от вполне безобидных правок этих файлов.
Знаете, мне не интересно ваше мнение, даже если вы мегапрофи. Вы впечатляюще невоспитаны.
И да, я не заставлял ваше величество тратить ваше бесценное время на мою недостойную статью )))
Если приложение активно работает с удаленным сервером и с БД, делать это в GUI потоке — моветон нынче. В Android, например, это вообще строжайше запрещено
К примеру, в конкретно моём приложении есть приодический опрос сервера на наличие неких изменений. И по необходимости — загрузка этих изменений. Не в главном потоке же этот цикл делать!
Например — ссылка на компонент StyleBook. Он как правило, один на приложение и размещается на главной форме. А остальные формы на него ссылаются.
Таким образом, редактируемая форма теряет стиль оформления. И это происходит тихо и незаметно, безо всяких ошибок )). Хорошо, если тестировщик заметит до того, как оно уйдет в продакшн
Ваш пример в этом смысле не показателен ))
Если убрать комментарии — форма создается.
Delphi 10.3 Upd. 3
Я переводил проект с MSSQL Express на SQLite (!) и пришлось переносить код хранимых процедур в обычные запросы. В процессе этой работы и написал данный класс. Оттого он у меня и ассоциируется с процедурами. Но это конечно неверно.
Это один из способов вынести код SQL-запросов в отдельное хранилище. Но никак не полноценные хранимые процедуры. Вы правы.
Запрос удачный но выполняется долго?
По-вашему — разработчики Android от нечего делать запрещают морозить GUI всеми доступными способами?
Да и в Android везде используется SQLite и обязательно все запросы к БД идут в отдельных потоках или корутинах.
Так что случай — что ни на есть наш. SQLite после некторых танцев с бубном вполне неплохо живет в потоках.
Я до этого пользовался TFDScript для обновления БД и сами скрипты хранил в ресурсах. В таблицах строк их для этого компонента никак хранить не получится.
Тут сделал по образу и подобию.
Да и в коце-концов — чем удобнее хранение скриптов в STRINGTABLE? Я не нашел ни одного преимущества, только неудобства.
Добавить файл в ресурсы — одна строка. Извлечь оттуда — ну 10 строк (GetStringResource). Всё. И я получаю файл в том формате, в каком его наиболее удобно парсить а не мучаюсь с форматом STRINGTABLE. Вот просто получается реально меньше кода и проще. Вот и все…
Меня больше всег раздражают не ошибки в IDE, а неполнота документации. Вот это — реальная беда. Я в последние пру лет активно использую в проектах Binding. Удобно. Часто вообще код писать не нужно при работе с БД — только SQL-запросы. Но он крайне плохо документирован. И на форумах про него днем с огнем ничего не найдешь… Обидно
С файлом dproj — еще веселее )))
Если туда что-то добавлять НЕ в конец файла, вообще крыша у Delphi может поехать и файл перколбасит так, что не узнать.
В 99% случаях не нужно лезть через окно — есть дверь. Просто я о ней не знаю :)
И спустя какое-то время получил странное поведение проекта в design-time. Не создавалась главная форма при открытии проекта. При этом — никаких ошибок.
Но вот только ссылки свойств компонент на других формах на компоненты главной формы при сохранении стали затираться. Например — ссылка на StyleBook.
И я только через несколько месяцев понял, что виноват безобидный комментарий в файле dpr
Одним словам — производитель не предусматривал такой сценарий.
Безусловно, и dpr и dproj и dfm можно править руками. Но лучше делать это только в крайнем случае. Я не раз получал совершенно неожиданные и непредсказуемые разультаты от вполне безобидных правок этих файлов.
И да, я не заставлял ваше величество тратить ваше бесценное время на мою недостойную статью )))