kami

Друже! Ты прекратил мои мучения. Ибо всякие извращения с обращением 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. Свои, а не общесистемные.

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

Что может быть непонятно во фразе non-zero value из первоисточника? Скорее всего, возвращаемый результат интерпретируется как BOOL. У любого булеан-типа есть два значения: 0 = False, не 0 = True. Что там присваивают конкретные компиляторы для значения True - это их проблемы. Сравнение всегда ведется с нулем. Может да, а может и нет. Откуда вы знаете, какую логику заложили другие разработчики в свои хуки? Это исключительно их дело - считают ли они нужным

Мало. If the hook procedure processed the message, it may return a nonzero value to prevent the system from passing the message to the rest of the hook chain or the target window procedure. Не вижу ничего запутанного. В штатной ситуации - вызываете следующий хук. А когда нужно, чтобы клавиша не добралась до адресата - не вызываете. Или же - вызываете, но Result возвращаете <>0. Я не знаю, какой из двух вариантов лучше - я давно уже не работал с WinAPI в этом ракурсе. Эксперименты вам всё покажут, там делов на 20 минут. Разные механизмы работы. Оба - system-wide.

Нет, не убрать. В целях нормального функционирования в подавляющем большинстве случаев вы должны вызвать следующий хук. И только в исключительных ситуациях (в данном случае - когда клавишу нельзя "пропустить" дальше) - не вызывать. А вы считаете, что единственный на всю систему установили хук на клавиатуру ? :))) Их десятки, если не сотни. Тот же WH_KEYBOARD: система будет вызывать последовательно все KeyboardProc в порядке (емнип), обратном времени установки хука. Естественно, если вы скажете системе "можно отдать на обработку следующему хуку". Внимательно читаем раздел Result в https://msdn.microsoft.com/ru-ru/library/windows/desktop/ms644984(v=vs.85).aspx Там, оказывается, уже всё предусмотрено и потенциально не надо даже пропускать вызов последующего хука. Хотя - лучше пропустить.