Search options (Page 47 of 60)

Как показали мои наблюдения, задержку вызывает не создание форм, а выгребание данных для компонентов на форме.
И, если для таблиц данные выгребаются в момент открытия формы, то для комбиков - при подключении к БД. Для MySQL это можно регулировать, выполняя команду UpdateDatabase() в нужное время (например, после отображения формы-заставки).

      // вызываем автозаполение ComboBox-ов, но по отдельности для каждой таблицы
      tmpFileName := ExtractFileDir(ParamStr(0))+'\tables.ini';
      tmpTablesIni := TMemIniFile.Create( tmpFileName ); // для работы с этим файлом использовать TMemIniFile - он нормально работает с Unicode
      tmpList := TStringList.Create;
      try
        tmpTablesIni.ReadSections( tmpList );
        for i := 0 to tmpList.Count - 1 do
        begin
          ConnectionProgress( i/tmpList.Count, tmpList.Strings[i] ); // отобразить название таблицы
          Application.ProcessMessages;
          Sleep(100); // задержка, чтобы видно было ))
          UpdateDatabase(tmpList.Strings[i]);
        end;
      finally
        tmpList.Free;
        tmpTablesIni.Free;
        ConnectionProgress(-1,' ');
        // звуковое подтверждение окончания загрузки
        tmpSoundFileName := copy(ParamStr(0),1,length(ParamStr(0))-4)+'.wav';
        // можно ставить любой файл, а если надоест, то удалить его совсем
        if FileExists(tmpSoundFileName) then
          PlaySound( tmpSoundFileName );
      end;

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

P.S. Долгое время создания именно формы бывает, если на ней находится много графических элементов. Для себя я эту проблему решил созданием и загрузкой графического контента из базы после запуска программы, в момент отображения заставки. Это позволяет реализовать богатый UI: в примере форма содержит больше сотни графических элементов (кнопки с тремя состояниям на базе TdbImage)

А зачем вы проверяете Parent у Sender?  Или вы используете обработчик MouseDown  не только для этих меток, но и для других?
Да и проверка

 if (TLabel) then

какая-то странная.То есть она ничего не проверяет )))  Для чего она нужна?

Если procedure MouseDown() используется только у меток, созданных программно, то никакие проверки не нужны:

procedure MouseDown(Sender: Tobject);
begin
    ShowMessage(TLabel(sender).Caption);
end;

Если вам нужно, чтобы клик срабатывал только для меток на панели (при условии, что обработчик назначен ещё каким-то меткам и другим компонентам), то так:

procedure MouseDown(Sender: Tobject);
var
  LPanel: TPanel;
begin
  LPanel := nil;
  if sender is TLabel then
  begin
    if TLabel(sender).Parent is TPanel then
      LPanel := TPanel(TLabel(sender).Parent);
      if  LPanel <> nil  then
      begin
        ShowMessage(TLabel(sender).Caption);
      end;
  end;
end;

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

const
  DATA_COL = 1;
...
frmMain.tgrData.Cells[ DATA_COL, y ]

Set property HeaderStyle = hsFlatBorder and use this code:

procedure frmMain_TableGrid1_OnChange (Sender: TObject);
begin
  frmMain.TableGrid1.Columns[0].Header.Color := clRed;
end;

You can change only header background color, header font color = table font color

Было бы логично, если бы function DayOfWeek() зависела от системных настроек:

к сожалению, сейчас это не так

Так и я за то, чтобы проект был лучше, и в обновления попадали в первую очередь нужные фичи. Но вами был задан риторический вопрос, на который последовал такой же риторический ответ.

Теперь по существу заданного вами вопроса. Добавление пользовательских иконок для кнопок на уровне конструктора во первых не такая уж тривиальная задача, а во вторых её реализация имеет множество вариантов. Поясню, что я имею в виду. Сейчас весь пользовательский  графический контент собирается в файл graphics.dll. Однако в некоторых проектах я предпочитаю хранить весь графический контент в базе данных и подгружать его программно после отображения окна-заставки. А вот большинству пользователей наличие нескольких файлов с картинками в папке проекта вообще не мешает. Таким образом, скрипты дают нужную гибкость в выборе решения, где хранить графические ресурсы и как и когда их загружать в программу.

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

P.S. Я вот радиочекер жду второй год )))

Пример нужный, но я бы рекомендовал делать всё через функции, чтобы проще было использовать в других проектах, например, функция, которая возвращает имя месяца:

function MonthName(ADate:TDate):string;
begin
  case MonthOf(ADate) of
  1: result := 'январь';
  2: result := 'февраль';
  3: result := 'март';
  4: result := 'апрель';
  5: result := 'май';
  6: result := 'июнь';
  7: result := 'июль';
  8: result := 'август';
  9: result := 'сентябрь';
  10: result := 'октябрь';
  11: result := 'ноябрь';
  12: result := 'декабрь';
  end;
end;

Пример вызова функции:

Form1.Label8.Caption := MonthName(Date());

Сочувствую вашему горю... Однако, если вы хотите помощи, то нужно приложить ваш проект и указать, о каком поле идёт речь.

Еще один вариант, это свои процедуры импорта/экспорта. После обновления программы (включая файл sqlite,db) программа импорта должна корректно загрузить в новую структуру экспортированные данные из старой версии. В зависимости от вида изменений структуры БД  это может быть тривиальной задачей, но бывают случаи, когда скрипт импорта получается довольно мудреным.

Проверил ваш код, все печатает. Ищите причину в принтере/настройках системы.

P.S. Спасибо за рабочий пример печати ))))

В настоящий момент я для упорядочивания скриптов в больших проектах использую имеющийся механизм USES (https://vk.com/@createmyvisualdatabasea … m-poryadok) , однако у него есть существенный недостаток: редактирование .PAS файлов, отличных от SCRIPT.PAS, приходится делать в сторонней программе, а при компиляции при обнаружение ошибки не указывается, в каком именно модуле она обнаружена. Если добавить возможность редактирования всех программных модулей и правильное отображение места ошибки, то это могло бы быть хорошим решением, которое успешно применяется в IDE Delphi.  А вот добавление автоматического создания .PAS файлов с именем формы считаю нецелесообразным - для простых проектов это ненужное усложнение. Ведь одно из главных преимуществ MVD - возможность создания простых проектов без написания кода.

Что же касается хэштегов, то это скорее из области механизмов автоматического документирования.

А вот группировка таблиц - идея неплохая.  Например, двухуровневое дерево: первый уровень - группа, второй - таблицы группы. По умолчанию все таблицы в одной группе, но чтобы была возможность создавать свои группы.  И хорошо бы комментарии добавлять к группам, таблицам и полям

Да, такая-же группировка и для форм пригодится: когда их несколько десятков, прокрутка списка начинает утомлять

Попробуйте так:

Это для поиска по полям "Контакт", "email", "Городской", "Сотовый".  Если нужно сюда же добавить поля из связанных таблиц, то придется учить SQL и добавить нужные поля через запрос SELECT 

Я не собирался давать вам наставления или нравоучения, это привилегия для моих учеников. Вам - только советы:

1. Не используйте в названии полей кириллицу - это усложнит вам составление SQL-запросов.
2. Прочитайте книгу автора этой системы, там есть много из того, что вы ищите: http://myvisualdatabase.com/forum/viewtopic.php?id=2554