kami

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

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

  • Посещение

  • Days Won

    22

Все публикации пользователя kami

  1. а там не пришли к единому мнению. Но с учетом At present, doing so is not officially supported with Delphi. (это про высокую версию SDK) - лучше (имхо) обойтись targetSdkVersion.
  2. Use Jedi API: https://sourceforge.net/projects/jedi-apilib/?source=navbar да, "старовато", но наиболее полно и правильно.
  3. С учетом того, что все элементы уже в массиве (кстати, почему в массиве, а не в TObjectList<T>?) - почему бы не обратиться так: myArrayOfItems[1].Visible:=False; ?
  4. Значит, после прочтения не были сделаны выводы из числа тех, которые я расписал. Это утверждение. Хм... даже после объяснений из (1.а) - (2) ?
  5. Я думаю, надо посмотреть - какие параметры ожидает процедура и дать ей именно их.
  6. Нет! Queue, будучи вызванной из главного потока, выполнится сразу же, как будто анонимная функция является частью основного кода. Только через TTask.Run или CreateAnonimousThread. А вот это из-за непонимания того, как работает Release, хотя частично я это объяснил ранее, да и по приведенным ранее ссылкам есть. Более того - Ярослав объяснял это в одной из тем на форуме, но увы - искать лень. Итак, что делает Release: 1.а Сразу же ликвидирует объект отовсюду из FMX, где он мог быть зарегистрирован. Т.е. удаляются все ссылки на этот объект, которые могли присутствовать в стандартных модулях. Естественно, что если ваш код хранит ссылку (ссылки) на этот объект - вам нужно удалить их самостоятельно. Или же изначально помечать как weak. 1.б По завершению этого действа - объект помещается в специальное хранилище, так называемую "очередь на отложенное удаление". 1.в При этом сам объект еще жив и спокойно будет произведен выход из кода всех событий и методов, внутри которых он сейчас находится. 2. Когда приложение "бездельничает", вызывается очистка этой очереди, там объекту делают DisposeOf. Вызов ProcessMessages элементарно может вызвать п.2. При этом пункт 1.в будет выполнен только после п.2, и то - с нарушениями, поскольку объект после выполнения 2 уже не жив. Так понятнее?
  7. На самом деле без разницы, поскольку синхронизация с главным потоком (что Synchronize, что Queue) будут выполнены из вторичного потока только на Application.OnIdle (или что там есть у FMX Application). Но в общем - да, Queue звучит понятнее в данном контексте. Заменил. А вот одну ошибку, про которую Ярослав рассказывал в статье "Жизненный цикл" мы чего-то упустили... Для анонимного потока нужна глобальная переменная: var myThread: TThread; ............... begin myThread:=TThread.CreateAnonimousThread(.здесь Synchronize или Queue с удалением компонентов..); myThread.Start; end;
  8. нет, совсем не на раз. Эта задача решается не совсем очевидным способом в том числе и на Windows (раз два три , и это так - навскидку ). То, что вы не наткнулись на грабли в Windows - это очень хорошо. Вернее, плохо, потому что теперь вы считаете, что так делать можно. И потом возможны вопросы "вот почему раньше получалось, а с вот этим вот компонентом - нет". Кросс-платформенные варианты: Item.Release; TThread.CreateAnonimousThread(... TThread.Queue(...здесь любой использованный вами ранее код удаления всех компонентов)).Start: или аналог CreateAnonimousThread - TTask.Run
  9. Как вы считаете, удалять объект из самого этого объекта - это нормально?
  10. Вам же дали ссылку на Conditional Defines. Это именно то, что вы спрашивали - что под какой платформой неявно задефайнено.
  11. Для создаваемых в runtime элементов не используйте свойство name, это действительно чревато вам дубликатами. Оставляйте name пустым. Ориентируйтесь на что угодно другое, хоть различные вариации свойства tag[Object, string]
  12. небольшой фотоотчет. Будет время - напишу еще и результаты блиц-интервью участников. Начало встречи. потом было вот это ну и эпилог: на последнем фото, слева направо (без учета z-order): @kami @Error @Nik @Brovin Yaroslav
  13. Коллеги! Во флудильне в Телеграме Ярославом была озвучена великолепнейшая мысль - устроить сборище в начале июня в Питере. Возможные даты встречи (формат даты - dd.mm, всё - 2017 год): 03.06, 04.06, 10.06, 11.06. Предпочтительные даты выделены жирным. Прошу откликнуться, кто хочет и кто может присоединиться к встрече, уточнить предпочтительные для вас дату и время сбора. Место сбора по традиции выбирает Ярослав!
  14. Так, погода на завтра благоприятствует. Начиная с 12:00 вероятность дождя снижается и к началу встречи всё должно стать хорошо. Ввиду того, что предложение wamaco не встретило отклика у участников встречи - место и время встречи остаются теми же: 500 метров от метро Александра Невского, пивной ресторан Bier König Дата: 10.06.2017. Время (уже окончательно) 17:30.
  15. В Delphi это решается явным полным указанием типа, вот так: myRect: System.Types.TRect И uses модулей нужно поставить в правильном порядке, чтобы конфликтов было как можно меньше (ну и полное явное указание типа тогда использовать того, чего меньше )
  16. Господа! Место встречи определено: 500 метров от метро Александра Невского, пивной ресторан Bier König Дата: 10.06.2017. Время (пока - ориентировочно) 17:30. Возражения? Другие предложения? P.S. На всякий случай - адресная рассылка: @wamaco @Nik @Brovin Yaroslav @Error
  17. Не знаю... ни в D7, ни в D2010 не сталкивался с изменением dfm-ок в плане картинок. В том числе - в ImageList.
  18. Если я правильно понял, то таких багов уже зарепортена толпа. Начиная от того, что каждое сохранение формы со StyleManager (даже если на форме вообще ничего не трогали) приводит к практически полному изменению картинок в стиле. В любой системе контроля версий это видно великолепно. Задалбывает каждый раз выборочно ревертить изменения.
  19. Перевесило Главнокомандующий сказал, что 3 и 4 никак, посему - рассчитываем на 10.06.
  20. Так, если гора не идет к Магомету, то мы пойдем к горе. Взываю к @Brovin Yaroslav @RoschinSpb @Error Скажите свое веское слово, особенно - Ярослав, за которым еще и выбор места встречи
  21. Ну, создание - это еще пол беды. Основная беда - это запуск потока, переключение на него менеджером потоков. Кстати, судя по коду System.Threading - там как раз используется пул потоков. Они висят в ожидании "когда же нас озадачат" и после озадачивания - с радостным повизгиванием выполняют. Это к вопросу о
  22. А точно нужно дожидаться, пока все потоки отработают? Это не асинхронные задачи? В качестве еще одного варианта - воспользуйтесь interlocked-функциями. Главный поток определяет, сколько вторичных потоков он запустит. И выставляет нужное значение в integer-переменной. Каждый поток, завершив виток просчета вызывает InterlockedDecrement(ThreadCounter); При достижении нуля - из последнего вторичного потока вызывается TThread.Queue для сообщения главному потоку "все просчеты завершены". Ну и - потоки входят в спячку, например - на ожидании TEvent. А получив очередную порцию данных для просчета - выходят из ожидания события. Даже лучше не так: каждый поток при запуске делает InterlockedIncrement(ThreadCounter), не стоит главному потоку выставлять начальное значение, хватит с него и запуска вторичных потоков. А вот всё остальное - да, остается в силе.
  23. Если Windows - то это WaitForMultipleObjects в остальных случаях - см. TTask.WaitForAll