kami

В обработке сообщения производить действия, которые способны генерировать кучу сообщений, которые приведут к обработке того же сообщения, в котором... , имхо, не есть хорошо. Вместо вот такого экранирования я бы попробовал использовать TThread.ForceQueue(procedure begin код, завязанный на IME end);

Это FMX. Оконная процедура устанавливается на конкретный хендл окна. А FMX раз по 100 пересоздает хендл. В результате установка NewWindowProc в качестве WndProc уходит в небытие.

Нужно перехватывать в рамках своего окна / приложения / системы вцелом ?

А в чем загвоздка? Достать поле из JSON - вроде просто, обычная работа с JSON далеко не самой сложной структуры. Раскодировать из Base64 - uses System.NetEncoding; TNetEncoding.Base64.DecodeStringToBytes и сохранить их в файл Потом открыть файл через интент.

Друже! Ты прекратил мои мучения. Ибо всякие извращения с обращением Query.Fields('lalala').AsBytes и тому подобное приводили к AV на закрытии Query. При этом тип поля - TVarBytesField (почему-то именно так распознается VARBINARY в SQLite...).

У меня большая просьба: вместо кучи маленьких сообщений, которые вы пишете буквально одно за другим, составьте одно, в которое напишите всё то, что хотели сказать. Это не чат, где "кто в онлайне - прочитали, остальным пофиг". Это форум. И искать зерна истины в этой портянке из мимолетных мыслей как минимум неудобно.

А можно тогда запушить последнее изменение на гитхабе в Readme.md, чтобы всем было видно "ПРОЕКТ ПЕРЕЕХАЛ" ?

Не здесь надо писать. А на гитхабе заводить issue. Это будет правильнее и нагляднее: сам проект лежит на гитхабе, там же значительно проще работать с багами / неудобствами. Да и всем видеть как развивается проект - гораздо лучше. А здесь в толпе ваших сообщений я,к примеру, уже потерялся.

https://github.com/ms301/TelegaPi

Стандартная практика при работе с WinAPI - после выделения памяти под структуру заполнить ее нулями.

Постараюсь. Но всю неделю очень насыщенная программа...

Значит глобальная настройка , выставленная в "All configurations - All platforms" перекрыта в наследниках, например в "Debug-Win32" Но не в этом дело. Попробуйте методом последовательного исключения, вернее - включения. Сперва избавьтесь от автолинковки "своих" dll, к примеру - видна загрузка какой-то NSI.dll. Если проблема пропала - постепенно включаем их. Не пропала - можно начать с чистого листа и постепенно дополнять новый проект своим кодом. На худой конец - просто пересоздать dpr и dproj, или что там аналогичное в билдере. Ну и не забываем про Build проекту. Есть смутное подозрение, что собрали-то без рантайм-пакетов, но что-то не подхватилось и до сих пор приложение их хочет. А может - не приложение, а dll??? Свалиться при инициализации ImageList, даже не доходя до своего кода - ну, это я не знаю :))) Может, винду переустановить? (шутка).

Нажать Break и посмотреть по стеку вызовов - где начинается ваш код.

Вы используете передачу небезопасных параметров между exe и dll? Зря.

Действительно (сам не могу проверить - сужу по StackOverflow). Там же, на SO, кстати, советуют в качестве костылятора использовать онлайн-читалку pdf от Google ( например ). Ну или - воспользоваться сторонним компонентом. Которые, увы, платные (насколько я прошерстил гугл)

TWebBrowser

Даже более того - если с сервера приходит с указанием правильной кодировки (не обязательно UTF-8), то всё работает замечательно без всяких переделок. Ибо перекодирование автоматически производится во внутренностях http-клиента.

Или возьмите TListView, у него есть PullToRefresh... или смотрите, как оно в нем сделано (в TListViewBase)

Это робкое выражение надежды

За сим дискуссию предлагаю считать законченной К сожалению, не вы один используете подобные грабли. Но не надо агитировать на подобное и других.

Я вас удивлю, но GetMem / FreeMem внутри инстанса можно использовать без ограничений, не задействуя ShareMem. Совершенно спокойно. И не только их. Динамические, статические массивы, объекты и их списки, переменные идущие в анонимные методы - абсолютно всё требует выделения памяти. И это всё разруливается встроенным в инстанс менеджером. ShareMem нужен, если вы решаете что-либо подобное экспортировать из своего инстанса. Или принять извне. Но в этом случае - автор интерфейса длл и/или exe сам себе злобный Буратино.

Каким образом соотносятся выделение памяти в модуле и использование borlndmm.dll ? Опять-таки, любой ShareMem никак не позволит скрестить модули, написанные в разных средах разработки. Да даже в рамках Delphi, но разных версий это может быть чревато https://stackoverflow.com/a/26900922/4908529

Не используйте дельфовые типы (в частности - строки как отдельно так и в составе record-ов) при передаче параметров в / из длл и не надо будет никаких костылей в виде borlndmm.dll и т.п. Представьте, что ваша длл будет вызываться из приложения на C++ и используйте только совместимые типы для экспортируемых функций. Я думаю, не надо говорить, что экземпляры классов 100% не стоит передавать между длл и exe.

Это случайность (с) Мастер Шифу.

Использовать вторую форму StrToDate, явно указывая FormatSettings. Свои, а не общесистемные.