DirtyBorov

Для Android и iOS конечно сомнительно. А вот в MacOS существуют - .dylib, .so. По сути это аналог dll, которые так же используют для plugin-ов. Попробую перефразировать вопрос - не совсем корректно его задал: под Windows я могу написать приложение на FMX и в качестве plugin использовать dll. При этом, dll-plugin могут быть написаны вообще не на Delphi. При этом, для обмена данными используются interface (в том числе IStream), т.к. напрямую объекты передавать нельзя. Могу ли я написать dylib или so на Delphi? Если нет, то могу ли я использовать so, написанную на другом языке и каков в таком случае будет подход по обмену данными между программой и плагином? Ну или возможно ли использовать BPL под MacOS (по сути это тоже dll)? Допустим стоит задача, написать программу для Windows и MacOS, с поддержкой plugin. Получается что для windows мне нужно отдельно написать кучу dll + механизм обмена данными. И для MacOS сделать тоже самое. По сути, две разные программы!!! Из этого и вытекает моей вопрос: могу ли я сделать универсальное решение? Что бы под windows компилировалась dll, а для MacOS - so. При этом для обмена использовался бы какой то общий механизм передачи данных (плюнем на совместимость с другими языками). Надеюсь так понятней. Сейчас у меня не стоит задачи делать плагины под MacOS. Но в дальнейшем весьма не исключена.

В VCL для передачи TStream из dll, обычно использую IStream, через пару TStreamAdapter/TOleStream. Но в FMX я что то не нашел им замену. Конечно, можно пойти путем что бы написать обертки для каждой OS. Но может есть какой то универсальный подход?

У меня аналогичная проблема (и не у меня только, судя сколько вопросов с этой бедой на разных форумах). Я так же не нашел причину. Оказалось что тот же код, но с формой VCL прекрасно работает и ничего не падает. Потому для себя я сделал связку: программа на FMX, а dll содержат формы VCL. Благо то, что это не критично (хотя и выглядит не стилизовано).

На ХЕ7 тоже падает. Прога на FMX, в dll форма тоже FMX. Но тоже все виснет или падает. Для себя решил проблему просто - в dll поместил форму VCL (мне не критично). После этого все начало работать.

Вот тут все разжевано http://www.gunsmoker.ru/2011/12/delphi.html

Посмотри у GunSmoker, но только для Delphi. Там довольно хорошо разжевано. И есть рабочий пример. Однако на XE7, он не пошел (как всегда уже все поменяли). Но по крайней мере ты поймешь как и что надо делать. http://www.gunsmoker.ru/2011/12/delphi.html

Да, мне тоже в целом компонент понравился. И работает весьма шустро, даже если грузить в него десятки тысяч веток. Что особенно порадовало - виртуальный режим. В том то и дело что напрягает. В самой среде, его лучше не трогать - любая попытка изменить свойства приводит к краху IDE. Все свойства нужно менять программно. Это не большая проблема и ее вполне можно было пережить, однако в runtime проблем не меньше. Я интенсивно использую D&D и компонент постоянно валится. Всем известный exception - AccessViolation. Естественно, первым делом я смотрю свой код в поисках обращения к несуществующему объекту. Но увы, с кодом все в порядке. Если я правильно понял, то триальные компоненты не только наг-скрином снабжены, но еще и по времени ограничены (!). Возможно причина в этом. Похоже надо рискнуть и купить. Альтернативы нет. Писать свой компонент - это время. Переписывать на другой язык - тоже время. Удивительно что судя по гуглу, есть большая потребность в TreeView, но до сих пор нет ни платных (за исключением TMS) ни бесплатных альтернатив.

Дался вам этот акутест. Лучше посоветуйте на счет TreeView

Железка - медицинский прибор. Нужна интерактивная работа с ним при навигации в дереве. Редактирование дерева - это по сути задание параметров прибора (если говорить техническими терминами). Грубо говоря, листья в дереве - это параметр. Их можно задавать несколько (checkbox), комбинировать в различные алгоритмы (D&D). Связь двухсторонняя - прибор так же передает данные, которые нужно принимать и отображать ( в том числе в дереве). Но проблема даже не в этом (в конце концов можно эмулировать), глючит в том числе D&D (рандомно вылетает AV, пропадают узлы, страдает отрисовка). Сейчас попробую изменить интерфейс, в пользу отказа от дерева вообще. Если не удастся сделать что то вменяемое, не перегрузив его не нужными элементами, то буду мигрировать на другой язык.

Так я и не говорил про EhLib для FMX. Тогда я писал на VCL, и пользовался TMS AdvGrid. А потом стал использовать EhLib. Если выйдет EhLib под FMX - обязательно куплю. Наверное. Скорее всего я просто уйду с Delphi. Слишком дорого и проблемно.

Да, именно он и интересует. Но вариант с компиляцией сильно сомнителен. Дело в том что нужно не просто отображение дерева как такового, но реализовать достаточно мудреный алгоритм редактирование, drag&drop с другим деревом. Более того, дерево завязано на спецефической железке, которую просто так в магазине не купишь (да и стоит она порядка 80к.) К тому же есть такая штука - NDA. Я просто не могу давать код на лево.

TMS сколько помню всегда славились глюками. Возможно сейчас стало лучше. Когда то пользовался их гридами - то еще удовольствие. В конечном итоге, не смотря на купленную лицензию пришлось от них отказаться и перейти на EhLib. О чем ни разу не пожалел. К сожалению, альтернативы TreeView под FMX найти не получилось. Видимо придется писать самому, что чревато приличным увеличением времени проекта и конечно же бюджета.

Даже не думал хамить. Вы не сдержались - я тоже. Не стоит винить кого то не зная причины. Я не ищу халявы. Как я уже пояснил - нужна только лишь оценка, т.к. на триальных оценить не получается. Ловлю глупейшие, но очень критичные ошибки. Естественно, в случае если компоненты зарекомендуют себя - они будут куплены. Софт делается не "штучный под заказ", а широко распространяемый. Кто же в здравом уме будет использовать ворованное в таком случае?

Не подскажете где взять свежей чем TMS Pack for FireMonkey v.3.1.1.2 Надо TreeView под FMX, а он в более старших версиях

Не смотря на заверения Я.Бровина о том что проблемы с D&D в ХЕ7 будут исправлены, не работает в ХЕ8. По крайней мере для TTreeView. События просто не происходят. Может я что то делаю не так? Поясните, знающие. procedure TFrameVRT.AlgorithmTreeDragDrop(Sender: TObject; const Data: TDragObject; const Point: TPointF); begin if Data.Source is TFmxObject then TFmxObject(Data.Source).Parent := AlgorithmTree; end; procedure TFrameVRT.AlgorithmTreeDragOver(Sender: TObject; const Data: TDragObject; const Point: TPointF; var Operation: TDragOperation); begin inherited; Operation := TDragOperation.Copy;// или Move end;

Счастье := REST + JSON API

подскажите как побороть это: [dcc32 Fatal Error] FGX.Asserts.pas(100): F2039 Could not create output file 'c:\program files (x86)\embarcadero\studio\16.0\lib\Win32\Debug\FGX.Asserts.dcu' Только что поставил чистую windows 8.1, установил в нее XE8. А компоненты не ставятся. В настройках пакета, изменил путь: $(BDSLIB)\$(PLATFORM)\$(CONFIG) на стандартный .\$(Platform)\$(Config) Это помогло, но только для fgx220.bpl - он скомпилировался, а вот dclfgx220.bpl все равно не ставится, т.к. не находит первый пакет. Смешно, то что в другой виртуальной машине стоить точно такая же комбинация Win8 + XE8 (другие сборки) - там все прекрасно встало.

Похоже FireDAC плохо дружит с LiveBinding. Я тоже напоролся на проблему - не обновляются данные. Есть 3 три таблицы, связанных внешними ключами через Master/Detail, по цепочке 1>2>3. Если перейти по записям в первой таблице - во второй данные обновятся, а в третьей - нет. Обновляются только если нет связанных данных. Самое интересное то, что точно такой же проект, с теме же таблицами на VCL отлично работает. Из чего складывается вывод - косячит биндинг. Точнее TBindSourceDB.

На самом деле ваш эксперимент не верен. Само TThread.Synchronize говорит о том, что мой код выполняется в потоке. Я просто удалил лишнее - моя ошибка. Надо было показать детали. В потоке не получится использовать глобальные переменные для цикла. По крайней мере в коде ниже, компилятор будет ругаться что для цикла надо использовать локальные. Код этот я давно переписал - нет смысла бороться с багами компилятора. Примерно он выглядел так: procedure RunTask; var LTask: ITask; begin LTask := TTаsk.Create( procedure var i, j: integer; begin /// Тут был проблемный код end); LTask.Start; end;

Уже несколько раз в ХЕ8 сталкиваюсь с проблемой. Наконец созрел спросить. Имею вот такой код : procedure LoadGroups; begin for i := 1 to Groups.Count do begin if Assigned(OnGroup) then TThread.Synchronize(nil, procedure begin OnGroup(Self, Groups, Groups.Item[i]); end); for j := 1 to Groups.Item[i].Users.Count do if Assigned(OnGroupUser) then TThread.Synchronize(nil, procedure begin OnGroupUser(Self, Groups.Item[i], Groups.Item[i].Users.Item[j]); end); end; end; При компиляции получается вот такая ошибка: [dcc32 Fatal Error] Engine.pas(159): F2084 Internal Error: URW1175 Что это за загадочная ошибка URW1175? Компилятор не может переварить сложную конструкцию? Возникает она из-за TThread.Synchronize. Если эту конструкцию убрать - все нормально компилируется. Так же ошибка исчезает если закоментировать цикл. UPD: нашел как обойти проблему. Оказывается компилятор почему то не может переварить цикл for. Что бы он не ругался, достаточно заменить цикл на while. for i := 1 to Groups.Count do на i := 1; while (i <> LSkype.Groups.Count) do После этого загадочная ошибка исчезает, и проект нормально компилируется. UPD2: оказывается это уже известный баг, но я об этом не знал http://qc.embarcadero.com/Wc/qcmain.aspx?d=131319

Вообще то пример был для VCL. В чистом виде он не будет работать в FMX. Нужно использовать CreateHandle как минимум или задать стиль окна через SetWindowLong например. http://www.firststeps.ru/mfc/winapi/win/r.php?94 А лучше почитать умную книжку по WinAPI.

Видимо TSizeGrip работает в обход, в силу кросплатформы. Могу посоветовать еще попробовать задать окно без заголовка но с рамкой. Через задание стиля окна: http://www.delphisources.ru/pages/faq/base/window_without_caption.html

Вы проблемы создаете на ровном месте. А как вы хотели то? Бордюрчик и служит той самой штукой за которую его таскают при изменении размера. Если его нет - таскать нечего. Значит ее надо сделать самому. Убираем рамку Form1.BorderStyle = None. Теперь кидаем на форму TStatusBar. Форма прекрасно изменяет размер. Если TStatusBar не подходит, используем TLayout + TSizeGrip. При этом можно растягивать только за TSizGrip в углу. Если сильно захотеть и хорошо подумать, то можно TSizeGrip накидать на все стороны формы и тогда можно тянуть в разные стороны.

Вот вам шаблон приложения, не мучайтесь так сердешный (XE7, XE8). MinFormSize.zip В чем проблема? Допишите нужную. У меня в setmaxsize необходимости до сих пор не было.