Лидеры

Вот патч от @Brovin Yaroslav iOSapi.CoreTelephony.pas.patch.zip

такой возможности пока нет, потому что нативные компоненты всегда располагаются выше стилизованных. ждать нужно будущих версии студии, там будут нативные компоненты под андроид и ZOrder

Добавьте, пожалуйста, в список подсветки синтаксиса кода пункт Pascal/Delphi. Вроде самая необходимая на данном форуме подсветка, а её до сих пор нет Спасибо!

Эх, попкорн закончился) Доброго вечера всем. Вот вы тут развели ср..., прям диву даешься. Неужели тут кто то всерьез верит, что Rad Studio похоронят - вы чего? СМена кадровой политики - абсолютно нормальное явление в любой организации, которая не сидит на месте. Другой вопрос - что послужило толчком? Но не суть. Тут прочитал - вот мол никто на FMX не пишет - вы судите по тому, сколько информации (удивленный смайл). Неужто кто то всерьез думает, что солидные компании, которые базируются на Rad Studio, будет трубить на каждом углу - смотрите, у нас софт написан на Rad Studio? (если быть точным, то с использованием, не придирайтесь)) ЗАЧЕМ оно им? С такой ценовой политикой, достаточно нескольких сотен пользователей для безбедной жизни, хотя думаю их в разы больше. А вот про баги и тд - улыбнуло. Есть у меня опыт небольшой работы и с FMX под ANdroid, и куда больший по десктоп, естественно под VCL. Есть опыт с плюсами и шарпом на Visual Studio тоже под десктоп. Ну и Qt немного. И судя по своему скромному опыту, еще вопрос - где больше багов, когда начинаешь копать глубже. Тута вон галку снял, и софт с 99% уверенностью запустится у всех, а Visual Studio - без опыта, один процесс настройки зависимостей проекта в новых версиях - тот еще гемморой. А потом начинаешь пользователям долбить - скачайте рантайм, а вот еще ддлку эту, а у вас версия Фреймворка не та))) Адекватно собрать статически слинкованный Qt мне так и не удалось, точнее удалось под MinGW - не впечатлило. Похоже многие забыли - FMX, Rad, Visual, pascal, c++, c#, и тд, и тп - это только инструмент, все зависит от того, кто его держит. Kitty - мне очень интересно - отчего такая потребность - закопают или нет? А кто мешает перебраться, в случае необходимости в другую среду - знания то лишними не будут. Напоминает покупку первой машины - месяцами выбирают (количество критериев зашкаливает - и чтоб то не сломалось, и не устарело, и тд), в итоге покупается что то непотребное, просто из-за подхода, при этом количество нервов потраченных...) вы же не на всю жизнь покупаете) Так и тут - ну случится беда, закопают - так правильно сказали: может через пару лет и Андроид гавкнет - что теперь не писать под него. В крайнем случае можно на время перебирания в другую среду остаться на старой версии. Хотя, вынужден извиниться, возможно у вас действительно вперед смотрящие, долгосрочные проекты, тогда стоит думать сейчас (ни в коем случае не сарказм). Но положа руку на сердце, поверьте - выбор то не велик, к сожалению, когда дело доходит до чего - то большего, чем Hello World. P.S. не первый год пытаюсь переползти в Visual Studio - именно написание кода там куда более комфортное, но увы - так и не смог) сошелся на Dll-ках, из Visual Studio, и основе в Rad Studio - довольно удобно и комфортно.

Глобальная оптимизация: друзья, в новой версии FastReport FMX изменения коснулись всего: от ядра отчетов до вывода текста на экран. Подробнее обо всех изменениях можно почитать на сайте. Если вы еще не обновились, скорее же обновляйтесь! Напоминаю, что если вы испытываете трудности в работе с нашими компонентами - мы будем рады помочь вам на страницах форума!

Первый набросок компонента, позволяющего организовать централизованное хранение графических ресурсов для всех платформ. Основные особенности: Спроектирован для использования одного экземпляра изображения во многих компонентах. Позволяет хранить все графические ресурсы любых размеров. В будущем не будет грузить картинки в память, если они не используются. А будет подгружать их из файла по мере необходимости. Тем самым будет значительно экономиться память. Хранение именованных графических ресурсов, а не по индексу. Это позволяет отразить в названии назначение картинки. Использование папок. Группировка изображений по смыслу для удобства работы с ними. Возможность загрузки разных картинок для разных устройств, или же загрузить один набор картинок для всех устройств. Удобная и быстрая загрузка изображений путем перетаскивания Хранение отступов изображения. Наглядное отображение картинки в свойствах компонентах. При изменении имени картинки, в компонентах используемых картинку идет автоматическое обновление имени картинки. В стандартном TImageList, из-за индексной структуру все картинки съезжают и при удалении картинки, компонент начинает отображать уже другую картинку.

Windows, FMX Возможно не совсем в тему форума, вопрос по архитектуре серверных служб, хотелось бы услышать мнения. Ситуация: IdHTTTPServer на каждый запрос создает поток, в этом потоке не обойтись без обращения к пулу данных в памяти. Пул - несколько наборов актуальных данных. Наборы данных асинхронно получаются из БД, имеют связи многие ко многим, один ко многим и периодически кэшируются в память в основном потоке. Т.к. обращение к пулу из потока - соответственно пул должен быть потокозащищенным. После обработки запроса, данные также отправляются в основном потоке в очередь БД. 1. Если весь пул закрыть в TCriticalSection - то на время использования его одним потоком все остальные будут ожидать. Обращение к очереди БД из потока получается также должно быть потокозащищенным. Не изящно. 2. Можно задачу обработки положить в некую потокозащищенную очередь и остановить поток c помощью TSimpleEvent->WaitFor( INFINITE ). Далее в основном потоке работать с пулом данных и очередью БД без критических сессий и, после получения результата, запустить поток SetEvent(). Код будет проще и понятней, однако задачи будут выполняться синхронно, последовательно как и в первом случае. 3. Можно закрывать TCriticalSection отдельные наборы данных, это возможно несколько увеличит быстродействие (не факт!), усложнит код и увеличит вероятность deadlock, т.к. для обработки одного запроса используется несколько наборов данных. Deadlock не будет, если перед обращением к следующему набору ( critical_section->Enter() ) копировать что необходимо из предыдущего и отпускать его ( critical_section->Leave() ) - тут становится важна стоимость операторов копирования.При больших объемах, стоимость копирования может перекрыть весь профит от частного обращения к наборам. TThread полезно использовать при длительных операциях ввода вывода и ресурсоемких операциях, т.е. когда нужно подождать, не останавливая основной поток. Выигрыша в производительности полагаю нет, к тому же переключения критических секций также имеют стоимость. Вопросы: 1. Какой вариант предпочтительней? Есть стандартные схемы? 2. Как влияет количество ядер, процессоров, на быстродействие во втором и третьем случае?

des80, с такой позицией помощи можно не ждать. хамству тут не место

Delphi умеет наследование форм. Делаете основную форму с общим поведением для всех форм и все формы проекта наследуете от этой формы.

Нет. Если только писать на Delphi и на симуляторе

ребята ну вы чего? http://docwiki.embarcadero.com/RADStudio/Berlin/en/Running_Your_iOS_Application_on_the_iOS_Simulator

Есть примитивы синхронизации блокирующие только запись. Запись делают потокобезопасным. В этом случае не будет лока данных на чтение из других потоков, если запись не залочена. В отличии от критической секции, которая всегда лочит данные. Еще есть LockFree концепция, которая сводит почти к минимому использование блокировок. Главная идея - это использование атомарных функций и специальных флагов помечающих актуальность данных.

We've got a lot of exciting webinars coming in the first quarter of 2017. All these global webinars are offers 3 times a day to accommodate your busy schedule and timezones: 6 AM, 11 AM, 6 PM PDT. Replays will be available after the webinar completes, but be sure to attend for the live Q&A. Thu, January 19, 2017 - Maximize IDE Productivity with 10.1.2 Berlin Are you using all the latest productivity enhancements? Berlin 10.1 Update 2 Anniversary edition introduces more productivity enhancements than ever. This webinar will bring you up to speed on some of the top productivity boosts provided by your favorite IDE. Tue, January 24, 2017 - Migrating to RAD Server "Moving existing Delphi VCL ""Fat Client"" database applications to scalable client/server architectures with RAD Server. Five distinct phases: analyze, plan, refactor, build and deploy The key is building a layered architecture" Thu, January 26, 2017 - Web Front End Frameworks Delphi and C++Builder are amazing at building native multi-platform apps. There are also a great collection for Frameworks for building GUI web applications. This webinar will look at building high performance, feature rich web GUIs with your favorite development tool. Tue, January 31, 2017 - Migration Delphi - Case Studies "This webinar focuses on three areas for migrating legacy Delphi to the current Delphi version: Migrating 3rd Party Components / Libraries Migrating Unicode Migrations of Database and Middleware Includes resources, examples and practical advice" Thu, February 2, 2017 - Internet of Things Integration with RAD Server Overview of the Internet of Things components, libraries and support in RAD Studio. Including Beacons, Bluetooth LE, the GetIt IoT Components, Beacon Fencing and more. Week of Mon, February 6, 2017 - Arduino IoT Bootcamp Integrating Arduino and open hardware into your IoT Solution Week long boot camp More details to come Tue, February 14, 2017 - Modernize or Become Extinct Now is the time to move forward. Technology is moving faster and faster. If you were waiting for the right time to integrate with new technology, it is now. Thu, February 16, 2017 - LiveBinding for VCL Developers A guide to using LiveBindings in existing VCL applications Master detail relationships Creating LiveBindings in Code LiveBinding DataSets Tue, February 21, 2017 - Using TMS Cloud Pack to Integrate Your Apps with the Cloud REST services are everywhere, and using them is the key to accessing the cloud. The TMS Cloud Pack components simplify working with common web services including: PayPal, Flickr, Dropbox, Google, Microsoft, Amazon, Twillo and more. Learn the easiest way to integrate the cloud into your mobile and desktop apps. Thu, February 23, 2017 - CaseStudy: Delphi Minifig Mobile App Success Join Delphi Product Manager Marco Cantu for a case study of his successful mini-figure collectors app Available on mobile, using many Delphi and RAD Studio technologies Tue, February 28, 2017 - C++ the C++Builder Way Thu, March 2, 2017 - DevExpress Migration Tue, March 7, 2017 - Beyond Firebird Thu, March 9, 2017 - Building a Microservices Architecture with RAD Server Tue, March 14, 2017 - From Really "Old Delphi" to the Future Thu, March 16, 2017 - Using RiverSoft AVG Components Tue, March 21, 2017 - Advanced HTTP Protocol Hacking Thu, March 23, 2017 - Using JVESoft Components Schedule subject to change, more details to come! Просмотр полной статьи

Можно. Используйте события не OnClick или OnItemClick и т.д., а событие OnMouseUp у самого TListBox. Типа так: procedure TfmMain.lbxMouseUp(Sender: TObject; Button: TMouseButton; Shift: TShiftState; X, Y: Single); var LI : TListBoxItem; p : TPointF; begin if Assigned(Sender as TListBox) then begin LI := TListBox(Sender).ItemByPoint(X, Y); if Assigned(LI as TListBoxItem) then begin LI.IsSelected := True; TTask.Run(procedure begin if Button = TMouseButton.mbLeft then Do_какая-то_процедура(LI.Index) // просто пример else if Button = TMouseButton.mbRight then TThread.Synchronize(nil, procedure begin p := MessageEvent.GetMousePos; PopupMenu1.Popup(p.X, p.Y); // для вызова контекстного меню выделенного ListBoxItem end); end); end; end; end; P.S. Отмечу, что использовал TTask и TThread.Synchronize далеко не случайно! Во-первых TTask.Run запустит ваш обработчик нажатия на выделенный элемент в отдельном потоке, что не будет "тормозить" "выделение" самого ListBoxItem и вообще), а во-вторых - "внутри" вызванного потока сделал синхронизацию с основным потоком, при выводе контекстного меню для ListBoxItem, так как это гарантирует корректную работу с GUI в FMX.

Я пенек, проблему решил: Platform был Win 10....нужно было Default ставить.

Тут еще совет дали: Возможно пакет йос симулятора отключился. надо лезть в настройки реестра. И проверить, что нужные пакеты включены. Названия не помню, но точно в названии были слова ios simulator

@Brovin Yaroslav, [11.01.17 15:42] Возможно пакет йос симулятора отключился @Brovin Yaroslav, [11.01.17 15:42] надо лезть в настройки реестра @Brovin Yaroslav, [11.01.17 15:42] И проверить, что нужные пакеты включены. @Brovin Yaroslav, [11.01.17 15:42] Я названия не помню @Brovin Yaroslav, [11.01.17 15:43] но точно в названии были слова ios simulator

Вот из майки, в смысле Maya файл (первый попавшийся) .obj. Даже текстурку подхватило по умолчанию. НО навигация во вьюпорте - нет слов, одни эмоции Хотя, возможно я чего то не понял. Текстурка .tif - тут еще разбираться нужно, мне не охота, скорее всего далеко не все расширения прокатят. Это и есть ответ на ваш вопрос - в 90% случаев .obj хватит за глаза, а его поддерживают при экспорте все адекватные редакторы)

System.IOUtils в uses поставить после модуля, в котором описан компонент TPath (делфи не под рукой, не скажу в каком конкретно).

Да сколько можно говорить!!!! Забудьте грид на мобилах!!! Привыкли писать под десктоп и пытаются тут эти знания прикрутить. Много, врать не буду, но многие и не только из за мобильности. Тоже очень много! Особенно хорош последний релиз берлин 10.1 с up2. У меня так даже на win XP заработало стабильно!

Кто-то ждет что делфи "оживет", а кто-то пишет на ней и радуется жизни.

Как уж так с Api Yandex разобрались, а с TMapView нет? TMapsEngine точно смотрели?

Мое решение, все тоже - жду год, смотрю что происходит. Сейчас я стараюсь "доводить" свои наработки в OpenSource и выкладывать в бесплатном или нет варианте, делиться опытом, который есть в виде статей и заметок, чтобы оно не сгинуло если что...

Решил так: procedure TForm1.FormKeyUp(Sender: TObject; var Key: Word; var KeyChar: Char; Shift: TShiftState); begin if Key = vkMenu then ... end;

Toast message.Можно пользоваться с помощью библиотеки FGX - TfgToast

Так не устраивает? procedure TFormMain.sbSelectFolderClick(Sender: TObject); var PathFolder: string; begin if SelectDirectory('Выбор папки...', '', PathFolder) then ePathFolder.Text := PathFolder; end; SelectDirectory

Менеджер отправился к Великому Программисту и показал ему техзадание для новой программы. Менеджер спросил Мастера: «Сколько времени займёт у вас разработка этой системы, если я назначу вам пять программистов?» «Один год» — быстро ответил Мастер. «Но нам она нужна вчера! Как долго вы будете её разрабатывать, если я вам дам десять программистов?» Мастер нахмурился, и сказал: «тогда два года». «А если я назначу вам сотню программистов?» Мастер пожал плечами: «В таком случае, она никогда не будет завершена»

Коллеги, всем привет! Сначала хочу всех немного успокоить. Часто бывает, что в команде (а то и в сборной) по футболу меняют тренера, ведущих игроков, стратегию игры и т.д. Для футбола это - нормально. Нормально ли это для разработки софта? Отвечу комплексно. Сначала скажу, что я - MVP Embarcadero, но работаю я в www.workspad.ru - компании, организованной Сергеем Орликом. Во многом моя работа в Embarcadero до Samsung-а повлияло на то, что Сергей меня взял себе сотрудником - сейчас я занимаюсь развитием международного бизнеса www.workspad.com. Delphi остаётся моим любимым инструментом, недавно я начал писать что-то на блоге, просто жизнь позволила заниматься этим активно. Также мы начали проект TurboCocoa, где мне доверили роль frontman-а. Это такая тулза поверх Delphi, чтобы можно было писать 100% нативные по UI/UX приложения (Mac OS, iOS, Android). Но это - отдельный разговор. Конкретно про IT-бизнес, разработку ПО, зрелость продукта и кадровую политику Embarcadero. Я могу себе позволить её комментировать, т.к. я НЕ сотрудник Embarcadero (that's really impossible from inside). Разработка современного ПО - не вся, а определённого класса - стала настолько зрелой, что может быть правильным образом формализована с точки зрения требований и разбита на изолированный класс задач. Первый небольшой софт писался человеком, который "всё-в-одном", мы знаем, что первые версии Pascal писались одним человеком. Теперь это - большой коллектив. Как только Delphi как продукт стала большой и (!) зрелой, то стало возможным оптимизировать вовлечение специалистов. Это нормально для строительства - каждый новый дом - отдельный релиз. Вот наняли архитекторов, вот - проектантов, вот - бригаду бетонщиков, вот - электриков. А вот - систему кондиционирования взяли у другой компании с их проектом и их монтажом, которые тоже сами кондиционеры не производят. А обслуживать здание будет вообще другая компания (багфиксинг). Поймите правильно - я связан тесными личными отношениями с Егвением Крюковым, Ярославом Бровиным и другими разработчиками Embarcadero. Но есть и объективные процессы, которые лично меня по жизни двигали часто не туда, куда я хотел двигаться сам - есть обстоятельства непреодолимой силы. Т.е. мой анализ - безличностный. Если мы побьём задачи развития Дельфи на составные компоненты, то - да - есть совсем изолированные задачи: - компоненты - компиляторы - надстройки над IDE Возможно, именно такая организация Delphi как открытой среды и явилось причиной модульности не только её самой, но и команды специалистов, её развивающей. Т.е. я бы не стал сейчас резко негативно высказываться (опять же, несмотря на дружбу с разработчиками-Эмбаркадеровцами). Вопрос контрактной схемы развития продукта существует. Например, есть такая компания - SoftServe. Я её знаю ещё со времён Samsung. Потому как эта компания выполняет заказные разработки для крупнейших вендоров в мире, что совсем не вредит продукту. Какие минусы. Конечно, если в основе продукта не стоит узкая команда эксклюзивных архитекторов, то могут быть проблемы. Но, положа руку на сердце, даже FMX уже стала зрелой платформой, архитектурно созданной и отработанной Евгением Крюковым. Вспомним Андерса Хейлсберга. Да и даже Вирта - совсем не обязательно, чтобы он работал в Embarcadero для развития языка Object Pascal. Компоненты - ну тут мы вообще видели, что многие компоненты (наш же всеми любимый FireDAC) как раз и создавался вне Borland/Embarcadero. Компилятор - вообще отдельная песня. Какие плюсы. Плюсы - возможность оптимизировать затраты на разработку. Всякий из нас знает, можно нанять строителей на оклад и на "объем - сделал/получил" - дают существенную разницу в результатах. Более того, это - мировой тренд. Если свой разработчик может "пудрить мозг", то сдельный - не сделал, не получил. Наняли другого. А ещё с внешней рабочей силой можно поддержать любой релизный темп. Нужно упереться и выполнить обещание перед пользователями - до-няняли ещё 10 разработчиков и уложились. Стегать своих сотрудников, работающих на постоянке - бесполезно. Что можно ждать в будущем. В будущем нужно ждать следующего релиза. Не секрет, что у Embarcadero roadmap существенно расходится с релизами. В случае с сторонней разработкой это будет невозможно. Всё будет выполняться точнее. Что по деньгам? Не думаю, что это - вопрос денег. Можно больше вложить и "резче" сделать релиз, чем "растягивать удовольствие годами" (то же Linux-компилятор, я ещё до-Embarcadero это слышал). И получить больше продаж. И более сильные рыночные позиции. В любом случае, контроля над разработкой у Embarcadero теперь больше, а средства - гибче. Нужно посмотреть на следующий релиз.