DirtyBorov

12 часов назад, Сысоев Максим сказал:

так то длл чисто виндовая(реактОс"овая) фишка. Надеюсь вы же не собираетесь плагины для всех осей делать?

Для 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

6 часов назад, POV сказал:

А мне в итоге тривью от ТМС понравился. Бери пока триал и не парься (если глюки среды из-за компоненты не сильно напрягают). Попользуешь и решишь как быть дальше.

 

Хотя с Берлином стало хуже.

Да, мне тоже в целом компонент понравился. И работает весьма шустро, даже если грузить в него десятки тысяч веток. Что особенно порадовало - виртуальный режим. 

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

Похоже надо рискнуть и купить. Альтернативы нет. Писать свой компонент - это время. Переписывать на другой язык - тоже время. Удивительно что судя по гуглу, есть большая потребность в TreeView, но до сих пор нет ни платных (за исключением TMS) ни бесплатных альтернатив. 

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

24 минуты назад, Vitaldj сказал:

Так в чем проблема, реализуй этот алгоритм (хоть основную часть) редактирования + drag&drop. Мне кажется этого будет достаточно, что бы оценить функциональность и интерфейс. 

PS что же это за железка такая золотая?

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

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

38 минут назад, Vitaldj сказал:

Так EhLib под VCL же! Причем тут FMX?

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

20 минут назад, Vitaldj сказал:

Я так понимаю, вас интересует TreeView из FMX? Вы же можете накидать на форму и триалку с другими компонентами. Прописать хоть часть исследуемого функционала, а скомпилировать попросить у кого есть TMS. Не проблема, надо - помогу.

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

41 минуту назад, POV сказал:

Косяков у них хватает. По мелочи, на что жаловался в последнее время - исправили. 

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

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

1 час назад, Vitaldj сказал:

Если честно, не ожидал такого хамства на этом замечательном форуме. В жизни никогда ничего из себя не строил и в данном случае ничего "не кричал". Так что, впредь, думайте, что пишите!

По теме, да, многие сторонние компоненты не идеальны, TMS в их числе. Года 2-а назад ставил себе триал, действительно, с триалом было глюки. На их форме почитал, что такое бывает, потому что в триал они не всё вставляют. Купил, те глюки какие были, ушли. Пользуюсь из TMS только htmltext, combobox. Там все работает как часы.

 

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

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

Не подскажете где взять свежей чем  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

подскажите как побороть это:

Похоже 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 

на

UPD2: оказывается это уже известный баг, но я об этом не знал

А что в uses писать? он показывает  Undeclared identifier: 'TCreateParams'

Вообще то пример был для VCL. В чистом виде он не будет работать в FMX. Нужно использовать CreateHandle как минимум или задать стиль окна через SetWindowLong например.

http://www.firststeps.ru/mfc/winapi/win/r.php?94  А лучше почитать умную книжку по WinAPI.  

Вот, вот, у муня tsizegrip стоит, и форма может уменьшаться меньше параметра, заданных этим ограничениям

Видимо 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

Это пожалуй единственное место куда я не догадался проверить. Спасибо.