kami

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

Апну тему, пусть в топе повисит, может еще кто подтянется. Все-таки 5 октября уже не за горами.

Код, который привел Равиль - не самый лучший (заточен на частный конкретный случай), не стоит его использовать.

Исходный код TCustomWebBrowser.FormHandleCreated исправлен? На всякий случай - привожу сам код исправления. Файл FMX.WebBrowser.pas необходимо скопировать из исходников студии себе в проект, положив его рядом с dpr. И уже в нем сделать метод FormHandleCreated следующего вида (часть проверок 100% лишняя, но когда менял - подумал "пусть будет"): procedure TCustomWebBrowser.FormHandleCreated(const Sender: TObject; const Msg: TMessage); var WBService: IFMXWBService; begin if not Assigned(Self) then Exit; if not Assigned(Self.Root) then Exit; if Sender <> Self.Root.GetObject then Exit; if not(csDesigning in ComponentState) and TPlatformServices.Current.SupportsPlatformService(IFMXWBService, WBService) then // if not Assigned(FWeb) then begin if FWeb <> nil then WBService.DestroyWebBrowser(FWeb); FWeb := nil; // possibly, this not needed... FWeb := WBService.CreateWebBrowser; FWeb.SetWebBrowserControl(Self); FWeb.UpdateContentFromControl; FWeb.URL := FURL; FWeb.Navigate; end; end;

Программное изменение обычно используется при инициализации. Чаще всего требуется, чтобы "программное изменение" не вызывало onChange и что-либо в этом духе. Это просто не нужно, поскольку вы и так знаете, что вот в этот момент времени значение меняется. Посему - срабатывание события отключают. Например, так: var OldOnChange: TNotifyEvent; begin OldOnChange:=myContol.OnChange; try myControl.OnChange:=nil; // вырубили обработчик события myControl.чего-то-там; // делаем то, что потенциально может вызвать onChange finally myControl.OnChange:=OldOnChange; // восстановили его end; end; Если после подобных манипуляций нужно вызвать "штатный" обработчик - в коде можно это сделать, например, так: OldOnChange(myControl); // и вот здесь, если все-таки требуется что-то различать, стоит использовать, например, Nil в качестве Sender-а И в самом обработчике уже проверять Sender-а, и в зависимости от него - выполнять нужные действия.

if Self.Focused.GetObject is TEdit then траляля не?

Нет. ReturnKeyType - это всего лишь какая надпись будет на кнопке Enter. Поведение по нажатию на эту кнопку задаете именно вы. Система Андроид не знает о том, какой порядок табуляции установлен у ваших контролов, ей это глубоко симметрично. Если переход по Enter необходим - действительно используйте SetFocus, но на всякий случай - оберните его в TThread.ForceQueue

Сложно загадывать, далеко еще до этой даты. Но я за! Пы.Сы. Место нужно с вишневым пивом

а там не пришли к единому мнению. Но с учетом At present, doing so is not officially supported with Delphi. (это про высокую версию SDK) - лучше (имхо) обойтись targetSdkVersion.

Use Jedi API: https://sourceforge.net/projects/jedi-apilib/?source=navbar да, "старовато", но наиболее полно и правильно.

С учетом того, что все элементы уже в массиве (кстати, почему в массиве, а не в TObjectList<T>?) - почему бы не обратиться так: myArrayOfItems[1].Visible:=False; ?

Значит, после прочтения не были сделаны выводы из числа тех, которые я расписал. Это утверждение. Хм... даже после объяснений из (1.а) - (2) ?

Я думаю, надо посмотреть - какие параметры ожидает процедура и дать ей именно их.

Нет! Queue, будучи вызванной из главного потока, выполнится сразу же, как будто анонимная функция является частью основного кода. Только через TTask.Run или CreateAnonimousThread. А вот это из-за непонимания того, как работает Release, хотя частично я это объяснил ранее, да и по приведенным ранее ссылкам есть. Более того - Ярослав объяснял это в одной из тем на форуме, но увы - искать лень. Итак, что делает Release: 1.а Сразу же ликвидирует объект отовсюду из FMX, где он мог быть зарегистрирован. Т.е. удаляются все ссылки на этот объект, которые могли присутствовать в стандартных модулях. Естественно, что если ваш код хранит ссылку (ссылки) на этот объект - вам нужно удалить их самостоятельно. Или же изначально помечать как weak. 1.б По завершению этого действа - объект помещается в специальное хранилище, так называемую "очередь на отложенное удаление". 1.в При этом сам объект еще жив и спокойно будет произведен выход из кода всех событий и методов, внутри которых он сейчас находится. 2. Когда приложение "бездельничает", вызывается очистка этой очереди, там объекту делают DisposeOf. Вызов ProcessMessages элементарно может вызвать п.2. При этом пункт 1.в будет выполнен только после п.2, и то - с нарушениями, поскольку объект после выполнения 2 уже не жив. Так понятнее?

На самом деле без разницы, поскольку синхронизация с главным потоком (что Synchronize, что Queue) будут выполнены из вторичного потока только на Application.OnIdle (или что там есть у FMX Application). Но в общем - да, Queue звучит понятнее в данном контексте. Заменил. А вот одну ошибку, про которую Ярослав рассказывал в статье "Жизненный цикл" мы чего-то упустили... Для анонимного потока нужна глобальная переменная: var myThread: TThread; ............... begin myThread:=TThread.CreateAnonimousThread(.здесь Synchronize или Queue с удалением компонентов..); myThread.Start; end;

нет, совсем не на раз. Эта задача решается не совсем очевидным способом в том числе и на Windows (раз два три , и это так - навскидку ). То, что вы не наткнулись на грабли в Windows - это очень хорошо. Вернее, плохо, потому что теперь вы считаете, что так делать можно. И потом возможны вопросы "вот почему раньше получалось, а с вот этим вот компонентом - нет". Кросс-платформенные варианты: Item.Release; TThread.CreateAnonimousThread(... TThread.Queue(...здесь любой использованный вами ранее код удаления всех компонентов)).Start: или аналог CreateAnonimousThread - TTask.Run

Как вы считаете, удалять объект из самого этого объекта - это нормально?

Вам же дали ссылку на Conditional Defines. Это именно то, что вы спрашивали - что под какой платформой неявно задефайнено.

Для создаваемых в runtime элементов не используйте свойство name, это действительно чревато вам дубликатами. Оставляйте name пустым. Ориентируйтесь на что угодно другое, хоть различные вариации свойства tag[Object, string]

небольшой фотоотчет. Будет время - напишу еще и результаты блиц-интервью участников. Начало встречи. потом было вот это ну и эпилог: на последнем фото, слева направо (без учета z-order): @kami @Error @Nik @Brovin Yaroslav

Так, погода на завтра благоприятствует. Начиная с 12:00 вероятность дождя снижается и к началу встречи всё должно стать хорошо. Ввиду того, что предложение wamaco не встретило отклика у участников встречи - место и время встречи остаются теми же: 500 метров от метро Александра Невского, пивной ресторан Bier König Дата: 10.06.2017. Время (уже окончательно) 17:30.

В Delphi это решается явным полным указанием типа, вот так: myRect: System.Types.TRect И uses модулей нужно поставить в правильном порядке, чтобы конфликтов было как можно меньше (ну и полное явное указание типа тогда использовать того, чего меньше )

Господа! Место встречи определено: 500 метров от метро Александра Невского, пивной ресторан Bier König Дата: 10.06.2017. Время (пока - ориентировочно) 17:30. Возражения? Другие предложения? P.S. На всякий случай - адресная рассылка: @wamaco @Nik @Brovin Yaroslav @Error

Не знаю... ни в D7, ни в D2010 не сталкивался с изменением dfm-ок в плане картинок. В том числе - в ImageList.

Если я правильно понял, то таких багов уже зарепортена толпа. Начиная от того, что каждое сохранение формы со StyleManager (даже если на форме вообще ничего не трогали) приводит к практически полному изменению картинок в стиле. В любой системе контроля версий это видно великолепно. Задалбывает каждый раз выборочно ревертить изменения.