kami

Пользователи
  • Публикаций

    602
  • Зарегистрирован

  • Посещение

  • Победитель дней

    40

kami стал победителем дня 17 сентября

kami имел наиболее популярный контент!

4 Подписчика

Информация о kami

  • Звание
    Продвинутый пользователь
  • День рождения 16.06.1981

Контакты

  • StackOverflow
    http://ru.stackoverflow.com/users/192901/kami

Информация

  • Пол
    Не определился
  • Город
    Санкт-Петербург

Посетители профиля

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

    Плавный Swipe вниз

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

    Download FGX Nativo

    Это робкое выражение надежды
  4. За сим дискуссию предлагаю считать законченной К сожалению, не вы один используете подобные грабли. Но не надо агитировать на подобное и других.
  5. Я вас удивлю, но GetMem / FreeMem внутри инстанса можно использовать без ограничений, не задействуя ShareMem. Совершенно спокойно. И не только их. Динамические, статические массивы, объекты и их списки, переменные идущие в анонимные методы - абсолютно всё требует выделения памяти. И это всё разруливается встроенным в инстанс менеджером. ShareMem нужен, если вы решаете что-либо подобное экспортировать из своего инстанса. Или принять извне. Но в этом случае - автор интерфейса длл и/или exe сам себе злобный Буратино.
  6. Каким образом соотносятся выделение памяти в модуле и использование borlndmm.dll ? Опять-таки, любой ShareMem никак не позволит скрестить модули, написанные в разных средах разработки. Да даже в рамках Delphi, но разных версий это может быть чревато https://stackoverflow.com/a/26900922/4908529
  7. Не используйте дельфовые типы (в частности - строки как отдельно так и в составе record-ов) при передаче параметров в / из длл и не надо будет никаких костылей в виде borlndmm.dll и т.п. Представьте, что ваша длл будет вызываться из приложения на C++ и используйте только совместимые типы для экспортируемых функций. Я думаю, не надо говорить, что экземпляры классов 100% не стоит передавать между длл и exe.
  8. Это случайность (с) Мастер Шифу.
  9. Использовать вторую форму StrToDate, явно указывая FormatSettings. Свои, а не общесистемные.
  10. kami

    Хук на клавиатуру

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

    Хук на клавиатуру

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

    Хук на клавиатуру

    Мало. 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.
  13. kami

    Хук на клавиатуру

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

    Хук на клавиатуру

    Но результат функции хука нужно присвоить обязательно, вне зависимости от вызова следующего!
  15. kami

    Хук на клавиатуру

    не вызывать следующий хук