Akad

Как-то у меня большие опасения в этом. Останется какая-нибудь ссылка в недрах FMX и к вечеру у пользователя out of memory. P.S. Вот интересно стало: а рабочие стили для 10.2 fmx для win существуют в открытом доступе? Ну что бы не глючили чудовищно сдвигая объекты со своих мест, и что бы кнопка минимизации работала.

Я на Delphi 1 написал экзаменационную программу, и с тех пор щупал почти все версии. Но вопрос не в этом. Вопрос в Если я вырубаю поточность, все работает идеально. Как только её врубаю обратно - падает в CheckSynchronize. Происходит следующее: я закрываю форму и уничтожаю её, в родительской форме я после этого запускаю несколько потоков, которые забирают данные с сервера и заполняют свои таблицы через Synchronize. В общем-то ничего необычного, кроме того, что одновременно с этим форма уничтожается. Все привыкли их просто hide делать, разрабы когда тестировали, похоже этот момент вообще не учли. Сейчас вижу 2 варианта: либо в основной поток выходить через таймер (блин, ещё тот изврат будет...) либо создавать все формы при старте, и не разрушать их. Но тоже очень костыльное решение, так как у меня все формы описаны в скрипте, и создаются полностью динамически.

Проверил эту гипотезу. На предмет глюков RAD Studio 10.1 Berlin Update 2 с TThread.Synchronize. Эта проблема меня больше всего волнует из всех под win, остальные я уже почти все обошёл так или иначе. Для чистоты эксперимента взял виртуальную машину, образ скаченный с сайта эмбы и всё. Ничего стороннего не ставилось. Результат печален. Один и тот-же проект, под 10.2 стандартные падения в стандартных местах, где-то 1 раз из 4-х, может чуть реже. Берлин падает каждый раз при выходе, после использования синхронайза, плюс в процессе работы падения 1 из 3 или даже 1 из 2. В общем Токио ГОРАЗДО стабильнее работает с много поточностью. P.S. Запускалось естественно всё на одной машине, под одним пользователем.

Вот я приводил пример как я с ним работаю:

Все вьюхи в fmx работают через одно место. Меня спас TGrid с кастомной отрисовкой. Не полная замена, но штука работает и не тормозит.

Ага. И потом текстовый редактор, написанный на яве 2-3 Гига ОЗУ отжирать начинает, и тормозит на SSD безбожно. Это подход неумех, которым сложно после выделения памяти её освободить. Отсюда и получаются диезы, котлины и прочие явы. А сберовские банкоматы тормозят даже при вводе пин кода. Но это подход неумех. Дельфи даёт возможность писать нормальный, нативный код, но при этом не требовать компьютер за $500. Но это только VCL+ограничение 32битных приложений. Вот если когда-нибудь FMX начнёт работать стабильно - это будет бомба. А что касается сравнения с хамариным - проект купило майкрософт. Так что на 95% можно быть уверенным, что проекту хана. Он так и не взлетит. В других программах это как-то делается, значит как-то это сделать можно. ИМХО. Но спорить не буду, свечку не держал. Я, когда решал схожую задачу, эту часть в ява скрипт вынес и ловил колл-беки с браузера, так как мне было проще воспользоваться готовым апи яндекса. Не получится такого. Нанимается в фирму курьер, таксист, прочий франчайзя. Хозяину надо каждому телефон, на котором софтина не глючит подарить? У них у половины последние яфоны (при том, что ездят на классиках убитых), а у другой половины как раз эти китайские андроиды. А текучка там ого-го.

TMS Web Browser под андроидом по крайней мере закрывается вместе с окном, на котором он расположен. И кучи других проблем отсутствует. Может и контроллы поверх класть можно (не проверял, надобности не было). Но как навигацию использовать реально. У меня курьеры ездили.

Со времён Xe2 работал под каждой кроме XE6-7. И как в сказке, чем дальше, тем... глючнее. На Берлине те-же глюки+кой-какие, которые в Токио всё-таки поправили. Согласен среда стабильнее, даже IDE fix не накатывал. Но fmx там ещё хуже. У меня сейчас сервер+win клиент+android клиент (ios был на подходе, но из-за обилия проблем проект был заморожен) на дельфи. Из них нормально болемешно работает только сервер, и то так как VCL. Я тупо не могу под виндой из главного потока в TGrid информацию под курсором обновить. Никак, даже через SetFocus не каждый раз срабатывает. Про то, что андроид приложение плюётся эксепшенами ещё даже до 1 моей строчки на некоторых телефонах, и помогает только удаление данных я вообще молчу. Хотя у меня сейчас инсталяшка в мелкой конторе: 5 филиалов, 2-5 рабочих мест. Мне очень нравилась архитектура, пока я не начал внедрять, что бы работало у заказчика. Сейчас примерно 2 мес. внедрения, и проблем всё больше. Причём проблем на ровном месте типа что вообще нельзя использовать синхронайз. Про андроид приложение я вообще не говорю. У меня сейчас переписано, что почти всё напрямую к апи обращается, и то куча проблем. В общем в таком виде как сейчас есть ни какого смысла в FMX я не вижу.

Между версиями 10.2-10.2.2 прошло более полугода. Ни одного известного ДАЖЕ на форуме бага не поправлено. Динамики не вижу в упор. На следующей неделе у нас будет приниматься окончательное решение: скорее всего будем уходить с FMX на VCL обратно, причём на какую-нибудь XE2, там хоть текстовый редактор рабочий. Так как то, что сейчас получается - оно вообще не рабочее, а ждать устали. 10.2.3 скорее всего снова перенесут какие-нибудь кнопки в новое место, и ещё что-нибудь важное сломают, как в 10.2.2 не работающий в половине случаев ctrl+пробел и всё, главное денег заносите. Ставишь 3-ю студию, выбираешь котлин (это +~50тыр к зарплате) и пишешь что-нибудь. За месяц основные фишки типа XML разметки и всех вьюшек изучишь. Ещё 2-3 недели - это Dagger2, Relam и MVP . После того можно спокойно пройти любое собеседование. Главное демо-проект(ы) придумать по интереснее.

TWebBrowser в fmx не работает ни под одной из платформ хоть как-то стабильно. Надо использовать сторонние компоненты.

Попробую выразить свою позицию ещё яснее: сам принцип FMX - очень классный. Компилируемый язык, кроссплатформенность без извратов с QT. Доступ к SDK всех поддерживаемых OS из коробки и так далее. Если поправить глюки и пересмотреть ценовую политику - будет очень востребованный продукт. Но сейчас, в таком виде... Слишком всё сыро. Причём всё- это ДАЖЕ винда, которую они 12 версий уже пилят. Почему? Куча библиотек это умеет. 7z тот же.

В главном потоке, после удаления всех элементов на ней. В общем точно проблема в Synchronize, который я использую на той форме, которая в текущий момент активна, а не той, которая разрушена (после закрытия дочерней формы стразу стартует от 3 до 5 потоков, которые лезут в интернет и заполняют результатом этого действия таблицу). Вопрос что с этим делать. Фактически мне надо оказаться в главном потоке для TGrid.BeginUpdate/TGrid.EndUpdate. Всему остальному работать в GUI не обязательно.

Вопрос не в том, что можно или не можно принципиально сделать, а в том на сколько это потом будет работать у пользователя. Так вот например в текущей версии (10.2.2) можно добиться, что установленное с помощью шнура и adb приложение будет работать стабильно. Но потом берём удаляем это приложение через диспетчер, ставим этот же apk и получаем крэш на старте в дебрях fmx. Очищаем данные с помощью кнопки в диспетчере приложений, и прога (о чудо!) работает без сбоев. Вот подобные проблемы сводят на нет все старания. Когда у вас на отладочных телефонах всё работает нормально, а в плей марките вам единицы ставят да ещё и в отзывах ругают.

Кстати если стоит задача определения IP локального компьютера-сервера, то это легко узнается через броткаст на .255 адрес. В ответе сервера должен содержаться его IP, и остальные действия обращения должны быть уже на этот IP. Лично я всегда так делаю. Много лет и разных инсталляций полёт нормальный. Если мы говорим про интернет, то проще всего DNS.

Это для винды. Линуховский аналог по мере сил называется Samba. Через самбу общаться особо извращённый секс. Но если мы говорим конкретно про андроид, то там кроме самбы есть куча других вариантов, начиная с MTP. Касательно изначального вопроса - проблема или в настройки DNS сетёвки, или что просто надо сначала выяснить IP по имени, а потом что-то с ним (IP) делать.

Очень похоже, что дело в синхронайзе. Для системы окон он неожидаднен. Чуть позже отпишусь, что TThreadedQueue, или какой ещё вариант лечит косяк с возвращением потока в GUI.

Ха-ха. Я, имея достаточно большой опыт копания с дельфёй простой (наверно) глюк уже месяц отловить не могу. Слишком запутано написано. Слишком много ветвлений, не явно связанных потоков и т.д. Лишний раз лезть в эти дебри - бррр. Проще за 5 минут хук поднять. ))))

Я сразу сказал про пул запросов. Про асинхронные запросы я ничего не говорил вообще. Ну могу сказать, что это не стабильно, и привязано в wnd и пр, что намекает. Но зачем? Надо сразу всё делать правильно.Т.е. когда ответ на запрос станет доступен заказчик может быть уже давно мёртв. Я с самого начала это повторяю. По крайней мере HTTPServer это вообще не рабочая вещь. Под хоть какой-то нагрузкой (5-6 обращений в секунду) он начинает пропускать подключения (тестил на 10.2.0). Над клиентом после этого свечку вообще держать не захотелось. Indy везде стабильно себя ведут. Это каким образом можно от indy отказаться???? На что перейти? Кто ещё умеет https, и другие требующие ssl подключения типа почтовых. Или UDP, или ftp. Не представляю.

5 баллов! Нам пофиг что реально происходит, главное, что мы это не видим. Значит этого нет. Мне здесь выложить исходники System.Net.HttpClient+ссылки на мсдн как работают сокеты в асинхронном режиме? И опять-же приходим к пулу. И опять-же развивая мысль нужно использовать не THTTPClient, а TIdHTTP и так далее.

Вообще-то Вы сами себе противоречите. Называете создание нового потока очень затратным, и в следующем же абзаце говорите, что это лучшее из возможного, с минимальными затратами. Или думаете в каком потоке будет происходить обращение к серверу? Это во-первых. А во-вторых это такой-же не контролируемый поток. Слушатель может быть давно уже мёртв, когда придёт ответ от сервера. Короче в любой более или менее сложной задаче (больше одного запроса и/или больше одной формы) ни куда от пула запросов не деться. Дальше думайте сами как говорится.

Проще всего повесить хук на клавиатуру и самому контролировать всё, что приходит в приложение, чем искать что там куда приходит раньше/позже.

Для начала под linux нет VCL. Есть только FMX. VCL - это исключительно win-приложения. Под linux они запускаются по средствам wine, и все проблемы работы приложения на плечах этих ребят. Тут вам ни чем не помогут. Так же не совсем понятны скриншоты окна к консольному приложению. С sgc я не работал, но если интересуют причины не работы - надо под отладником на целевой платформе копаться в их коде копаться в их коде.

Эти вещи ни как не связаны. Т.е. НИЧЕГО, работает дальше. Поэтому нужен менеджер потоков, и нужно убийство не нужного (уже) потока при закрытии формы, или нажатии пользователем на esc и т.д.

Именно то, что написано. И ничего более. А присина причины - уже надо выяснять под отладчиком или по логам.

Может быть всё таки что-то не устраивает, просто продукт не имеет аналога на рынке, поэтому приходится мириться "со сложностями"?