Перейти к содержанию
Fire Monkey от А до Я

Камышев Александр

Пользователи
  • Постов

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

  • Посещение

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

    9

Весь контент Камышев Александр

  1. String fn; String path = System::Ioutils::TPath::GetSharedDownloadsPath(); #ifdef __ANDROID__ TSearchRec sr; if ( !FindFirst( path + "/*", faAnyFile, sr) ) { do { if ( sr.Name=="." || sr.Name==".." ) {} else if ( (sr.Attr & faDirectory) == faDirectory ) {} // dir else {} // file // отрисовать в список sr.Name sr.Name; } while ( !FindNext(sr) ); FindClose(sr); // по клику в списке получить fn = path + "/" + name; } #else OpenDialog->InitialDir = System::Ioutils::TPath::GetSharedDocumentsPath(); if ( !OpenDialog->Execute() ) return; fn = OpenDialog->FileName; #endif вот так сделал, кому понадобится, на паскале тоже работает, только синтаксис другой
  2. разрыв соединения - все корректно обрабатывается void __fastcall TMyDBClient::ConnectionError( TObject *ASender, TObject *AInitiator, Exception *&AException ) { status = dbcError; #ifdef AUX_MODE error_string = AException->Message; #endif if ( FOnError ) FOnError( (TObject*)this ); Abort(); } //--------------------------------------------------------------------------- void __fastcall TMyDBClient::QueryError(TObject *ASender, TObject *AInitiator, Exception *&AException) { status = dbcError; #ifdef AUX_MODE error_string = AException->Message; error_string += "\r\nsql: " + fquery->SQL->Text; #endif if ( FOnError ) FOnError( (TObject*)this ); Abort(); } //--------------------------------------------------------------------------- void __fastcall TMyDBClient::AfterDisconnect(TObject *Sender) { status = dbcNotConn; #ifdef AUX_MODE log_string = "db - disconnect"; if ( FOnLog ) FOnLog( (TObject*)this ); #endif } Abort() - чтобы не было исключения в Application так тишина и только логи шелестят переподключениями
  3. Раньше тоже пользовался продуктами devart, хоть и недорогие, удобные, надежные, но все же они платные, плюс вообще не люблю подключать сторонние компоненты. На oldschool теплом ламповом CBuilder приходилось много всего подключать: скины, компоненты доступа к бд, инди последних версий, компоненты для отчетов, png и т.п. С тех пор стараюсь избегать всего не родного. FireDAC понравился, хорош CmdExecMode amAsync - The calling thread and GUI are not blocked. The called method will return immediately. Позволяет работать с базой из основного потока без завешивания, отправил запрос и занимайся другими задачами пока callback не придет.
  4. видимо не судьба им быть вместе... приложению и galaxy tab
  5. печалька ошибка та же? если сборке не указать APP_ABI := x86 собирается четыре папки: arm64-v8a, mips64, x86 и x86-64 arm и x86-64 вот libs.zip попробовать библиотеки 86-64 и для чистоты эксперимента arm из этой сборки, mips думаю не нужен
  6. THttpApiServer kernel-mode server от мелко-мягких, надо будет почитать, спасибо
  7. Транспортный уровень в любом случае tcp, а заголовки http, при необходимости, можно врукопашную парсить.
  8. вот, отсюда поподробней, как реализовать пул потоков? indy tcp и http серверы не имеют свойства ServerType как у старого TServerSocket и метода OnGetThread у embarcadero кроме indy больше ничего и нет по tcp что ж мне врукопашную создавать слушающий сокет и т.п.? пора видимо соскакивать на qt
  9. паралич перфекциониста, есть такое понятие хотелось бы обрабатывать несколько тысяч запросов в секунду, оптимизация оптимизации
  10. Размер пула - четыре std::map размером до 10000 с различными структурами, которые описывают оборудование, задания, прошивки, ссылки в файловое хранилище и связи между ними, плюс кэш файлов. Это сервер обновлений. Имеется к примеру 5 запросов за 10мс, инди сервер создает 5 потоков, один из них захватывает CrititcalSection и работает с пулом - остальные четыре будут ждать. Далее, второй работает - еще три ждут, и т.д. Сейчас так и реализовано. Очередь - std::deque в основном потоке, в ней задачи для асинхронной записи в бд в несколько коннектов, о том что к примеру девайс выходил на связь, имеет номер такой-то прошивки и получил задачу номер такой-то. Потоки запросов после отправки response оставляют в очереди запись. Так как к очереди могут обратиться несколько потоков - она тоже должна быть в критической секции.
  11. Windows, FMX Возможно не совсем в тему форума, вопрос по архитектуре серверных служб, хотелось бы услышать мнения. Ситуация: IdHTTTPServer на каждый запрос создает поток, в этом потоке не обойтись без обращения к пулу данных в памяти. Пул - несколько наборов актуальных данных. Наборы данных асинхронно получаются из БД, имеют связи многие ко многим, один ко многим и периодически кэшируются в память в основном потоке. Т.к. обращение к пулу из потока - соответственно пул должен быть потокозащищенным. После обработки запроса, данные также отправляются в основном потоке в очередь БД. 1. Если весь пул закрыть в TCriticalSection - то на время использования его одним потоком все остальные будут ожидать. Обращение к очереди БД из потока получается также должно быть потокозащищенным. Не изящно. 2. Можно задачу обработки положить в некую потокозащищенную очередь и остановить поток c помощью TSimpleEvent->WaitFor( INFINITE ). Далее в основном потоке работать с пулом данных и очередью БД без критических сессий и, после получения результата, запустить поток SetEvent(). Код будет проще и понятней, однако задачи будут выполняться синхронно, последовательно как и в первом случае. 3. Можно закрывать TCriticalSection отдельные наборы данных, это возможно несколько увеличит быстродействие (не факт!), усложнит код и увеличит вероятность deadlock, т.к. для обработки одного запроса используется несколько наборов данных. Deadlock не будет, если перед обращением к следующему набору ( critical_section->Enter() ) копировать что необходимо из предыдущего и отпускать его ( critical_section->Leave() ) - тут становится важна стоимость операторов копирования.При больших объемах, стоимость копирования может перекрыть весь профит от частного обращения к наборам. TThread полезно использовать при длительных операциях ввода вывода и ресурсоемких операциях, т.е. когда нужно подождать, не останавливая основной поток. Выигрыша в производительности полагаю нет, к тому же переключения критических секций также имеют стоимость. Вопросы: 1. Какой вариант предпочтительней? Есть стандартные схемы? 2. Как влияет количество ядер, процессоров, на быстродействие во втором и третьем случае?
  12. чем плох стандартный TLang? свойство AutoSelect=True - автоматическое определение языка и StoreInForm=True - хранить в ресурсах использую TLang для статичных строк и вот такой код для статусов и сообщений: String LangString( unsigned int code, AnsiString lang ) { if ( lang == "RU" ) switch( code ) { case 0: return (AnsiString)"Ожидание"; case 60: return (AnsiString)" не выполнено"; case 61: return (AnsiString)" выполнено успешно"; } else if ( lang == "EN" ) switch( code ) { case 0: return "Waiting"; case 60: return " not completed"; case 61: return " completed successfully"; } return "";
  13. android, Seattle Надо пользователю дать возможность выбирать файлы, к примеру из downloads. OpenDialog на моб. пл. не работает. Может есть у кого наработки? спс.
  14. попробуй Project->Options->Version Info->persistent = True и будет тебе счастье
  15. Да с гридами беда, у меня вот тоже http://fire-monkey.ru/topic/2017-медленная-дерганая-прокрутка-таблицы/
  16. begin //сюда запись 1 в файл> Application.Initialize; //сюда запись 2 в файл> Application.CreateForm(TForm1, Form1); //сюда запись 3 в файл> Application.Run; end. для начала так, будет понятно на инициализации или при создании формы или после run не верю что движок FMX падает, да и нет его, движка
  17. была такая же ситуация, падала служба на виндовс сервер 2012, ставить туда ничего нельзя, злой админ, удаленка и т.д. пришлось в коде раскидывать запись лога в файл, и в несколько итераций вышел на проблемный код, можно так
  18. приложение на всех w7 падает? у меня w7 64, могу потестить
  19. так что там с x86 планшетом? чем закончилось?
  20. что показал дебаг? возможно это разные случаи с w7 и vista и да результат пжлс
  21. Странно, казалось бы команда GlobalUseDXInDX9Mode := True; указывает приложению работать с DirectX9 - на нем довольно шустро бегают игрушки, почему этот так кардинально сказывается на быстродействии?
  22. program Project1; uses System.StartUpCopy, FMX.Forms, FMX.Types, Unit1 in 'Unit1.pas' {Form1}; {$R *.res} begin GlobalUseDXInDX9Mode := True; Application.Initialize; Application.CreateForm(TForm1, Form1); Application.Run; end.
×
×
  • Создать...