Вадим Смоленский

Ха! Вот, в самом деле, и разгадка. Я ведь забыл упомянуть, что не просто поменял компьютер, а перешел с Windows 7 на Windows 10. В комбо-боксе вижу два варианта: Default (был выбран по умолчанию) и Windows 7. Переключил на Windows 7, и все мои стили стали видны. Но будьте любезны разъяснить, как эти две установки связаны. Могу ли я, например, находясь под Windows 10, присвоить своим компонентам стили, созданные для Windows 7, чтобы любой пользовательский компьютер их нормально показывал? Или нужно как-то исхитриться и специфицировать стиль отдельно для Windows 7 и 10?

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

Он и есть у меня на форме, как и раньше был. Но теперь он девственно пуст. Загадка...

Работая в Berlin, подправил стиль для одного компонента посредством вызова "Edit Custom Style" во всплывающем меню. Потом перешел на Tokyo; потом поменял компьютер и установил на него Tokyo заново. Сейчас вижу, что компонент отображается в стиле по умолчанию. Никаких сообщений по поводу пропавшего стиля не припомню. Где мне найти и как опять подключить мой отредактированный стиль?

Попробовал бы, но уж слишком много кода придется менять ради 5-7% юзеров. Предполагаю, что качество вывода при этом все равно упадет, разве что меньше. Скорее всего, придется этим небольшим и уходящим сегментом рынка пожертвовать.

Изменение шрифтов вручную у меня предусмотрено, и Tahoma - не тот шрифт, который идет по умолчанию. Но я пока не понимаю, как добиться нормального вида при FMX.Types.GlobalUseDirect2D:=False.

В своем проекте (это японско-русский словарь) я часто вывожу текст на TImage методом TCanvas.FillText, и результат выглядит так: Один из тестеров, у которого установлена Windows XP, прислал скриншот того, что выводится у него: Ровно такую же безобразную картину я видел у себя, когда, экспериментируя с быстродействием, вставлял в файл dpr операторы FMX.Types.GlobalUseDX:=False или FMX.Types.GlobalUseDirect2D:=False То ли в XP эти установки приняты по умолчанию, то ли так сконфигурирована система у тестера. Первое, что приходит в голову - вставить в код присвоение обеим упомянутым переменным значения True. Но прежде, чем предпринять такую попытку, хотелось бы услышать мнение экспертов. В чем здесь корень зла?

Оказалось проще некуда: Q:=TStringList.Create; Q.Add('Русский текст'); Q.SaveToFile('FileName',TEncoding.UTF8); Низкий поклон людям из нового века!

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

Записываю русский текст в файл: procedure WriteToFile; var F: TextFile; S: string; begin S:='Русский текст'; AssignFile(F,MyFile.txt'); ReWrite(F); WriteLn(F,S); CloseFile(F); end; Тип данных string - по идее, то же, что WideString. То бишь, в строку S записан юникод. Тем не менее, открывая потом файл, вижу, что русский текст сохранен в ANSI. Как добиться его сохранения в юникоде?

Для моих задач быстродействия FireDAC вполне хватает. А работать с этими компонентами гораздо удобнее, чем с базой напрямую.

Вопрос снят! Второй моей ошибкой оказалось неправильное значение TFDConnection.Params.Database. Программа искала файл БД по этому адресу, не находила - и создавала новый, пустой, с таким же именем. А я пребывал в уверенности, что если ничего не валится, значит связь с базой установлена. Век живи, век учись. Всех сердечно благодарю! Узнал сегодня много нового.

Ровно это в моем коде и написано. Вот, целиком: TheDataModule.FDConnection.Connected:=True; TheDataModule.ElementsTable.Open; Edit1.Text:=TheDataModule.ElementsTable.Fields[1].AsString; TheDataModule.ElementsTable.Close; Однако ж, "no such table".

Уже читал. Не обижусь, если вы меня ткнете носом во что-нибудь более конкретное.

Идея сделать тестовое приложение оказалась плодотворной, ибо я сразу же нашел свою ошибку: TFDConnection.Connected было почему-то установлено в True уже на этапе дизайна. Соответственно, программа пыталась открыть базу, когда еще не знала, где эта база лежит. Теперь база открывается, но не работает с отдельными таблицами. В тестовом приложении таблица одна, называется Elements, там два поля и три записи. За нее отвечает компонент TFDTable. Опять же, у меня на компьютере все хорошо, а у тестера программа падает с сообщением "no such table: ELEMENTS". Что следует проверить?

Еще два вопроса. 1. У компонента FDGUIxWaitCursor1 есть свойство Provider. Значение по умолчанию: Forms. Не нужно ли поменять на FMX? 2. У тестера, как выяснилось, x64. Требуется ли другая sqlite3.dll?

Сделал, не помогло. Тестеры сообщают, что всё ровно так же.

Ну, хорошо, поставил я и этот компонент рядом с TFDConnection. Что дальше? Приведенные ссылки ничего не проясняют. В теме "Самый простой способ работы с SQLite" лишь одно упоминание об этих компонентах. Alex Bozhko пишет: "Ну, FDGUIxWaitCursor1, FDPhysSQLiteDriverLink1 - один раз повесили рядом с FDConnection, настроили и забыли - не особая и проблема (за универсальность чем-то платить всегда приходится)." НАСТРОИЛИ! В чем должна заключаться эта настройка?

Строчки про FDGUIxWaitCursor1 не наблюдаю. А зачем нам еще и этот компонент? Это ж, вроде, просто песочные часы в качестве курсора.

> Не упаковывайте в InnoSetup, скиньте просто portable, возможно у Вас нет прав у приложения на папку, где БД лежит.... > Или тестеры криво ставят... пусть сначала удалят старую версию.. Э, нет. Мне нужно сделать нормальный, упакованный дистрибутив, который работал бы у всех. Пользователей тысячи, я каждому не стану объяснять, что удалять и какие куда выставлять права. А права на папку с БД есть заведомо, это точно. Откуда вообще взялась тема с компонентом FDPhysSQLiteDriverLink? Кроме как в ваших постах, я упоминаний о нем нигде не видел. В хелпах написано, что этот компонент нужен для поддержки Advantage Database Server - насколько я понимаю, это клиент-серверная архитектура, которую я не использую. У меня автономная база, которая лежит у юзера на компе - при чем здесь сервер?

> Возможно не видит тот компонент, который я указал выше. Куда они его положили или может создавали в коде? Мои тестеры ничего в коде не создавали и с компонентами не работали, они просто запускали готовое приложение. Компонент FDPhysSQLiteDriverLink я положил по вашей инструкции на DataModule, рядом с TFDConnection, после чего скомпилировал исполнимый файл, создал в Inno Setup дистрибутив, куда приложил sqlite3.dll и файл БД, после чего отправил дистрибутив тестерам. Если это неправильно, то как правильно?

Который из вариантов вызвал ваш сарказм: процитированный в исходном посте или доступный по ссылке в последнем комментарии?

Delphi у меня нормально работает с sqlite, безо всякого dll. Не работает только собранное приложение на пользовательских компьютерах без Delphi. Если ваш совет относится к этой ситуации, я бы вас просил его развернуть, ибо пока плохо понимаю, что именно вы предлагаете.

Тестеры сообщают, что не помогло. Кстати, разве это не про клиент-сервер? У меня-то база вполне автономная...

Вопрос снят! Я попробовал еще один вариант, тоже порекомендованный мне одним экспертом 13 лет назад, и он отлично работает - по крайней мере, под Windows. При попытке повторного запуска приложение выводится на передний план. Там много кода, я не буду его здесь воспроизводить. Если кому-то интересно, то вот ссылка на обсуждение (советует эксперт SaLz): https://www.experts-exchange.com/questions/21225893/Disabling-second-run.html#a12728730