Anyone out there using TFireMonkeyContainer? How stable it is on lastest releases of Delphi? Are there any limitations/restrictions? David Millington
Anyone out there using TFireMonkeyContainer? How stable it is on lastest releases of Delphi? Are there any limitations/restrictions? David Millington
https://parnassus.co/open-source/tfiremonkeycontainer/
https://parnassus.co/open-source/tfiremonkeycontainer/
/sub
ReplyDelete/sub
ReplyDeleteI found something :)
ReplyDeleteBe careful when using TFireMonkeyContainer + FireDAC
When using FireDAC, you are requested to add a TFDGUIxWaitCursor
On VCL, you set the property Provider to Forms, and on FMX you set it to FMX
Alternatively, you can include in the uses clause of one of your units the specific provider for each framework
FireDAC.VCLUI.Wait or FireDAC.FMXUI.Wait
I prefer doing so because I encapsulate Data Access in plain units rather than DataModules
BUT, when using TFireMonkeyContainer on my VCL App with VCL FireDAC Cursor Provider, I got a crash when trying to open the connection: The crash propmted me to add the FMX provider to the project aswell :)
I did simple test and it seems to run fine with only (!) the FMX provider and with both VCL and FMX. Im leaving both of them for now
You've been warned
As long as both frameworks have their own windows message loop it cannot be 100% safe and all kinds of strange effects might happen because messages could be processed in the wrong one.
ReplyDeleteAgustin Ortu Interesting. You're welcome to file a bug report (please :))
ReplyDeleteTFireMonkeyContainer is completely unsupported. That said, it seems to work well and I know of quite a few people using it. Stefan Glienke, the FMX application's message loop does not run. The library replaces the application service with one that uses the VCL app for message processing.
ReplyDeleteThere are some odd bugs. Sometimes you have to click twice in a FMX edit or memo for the cursor to appear, for example. Generally though it works well.
David Millington will do, maybe I'll do a little research on why it happens. I'm sure that it's because of initialization code from both TFmxContainer and FireDAC. Somehow it recognises the app as a FMX one rather than a Vcl and that's why it needs the fmx cursor
ReplyDeleteI just was interested if someone maybe send you an e-mail/pmed you with something
It seems to work fine ATM, I'm definitively giving it a try. There are some amazing components out there for FMX that always wanted to use on Vcl (both standard and 3rd partys, thinking on ksComponents right now)
When I wrote it, I viewed it as a migration helper - something so that people could start using FMX in their app, and slowly convert. I thought it would help speed up FMX usage (and I think it has.) But most people I know of using it are using it in order to add FMX to their existing app, to use the new effect or graphics library, rather than to assist step-by-step conversion.
ReplyDeleteI'd love to see official support for FMX and VCL in the one Windows app. There'd be a lot of work to do that though: perhaps with the FMX TApplication and VCL TApplication being one and the same; maybe an ancestor abstract class or interface for both VCL and FMX forms; message handling being unified (FMX's message handling is very different.)
David Millington done https://github.com/vintagedave/firemonkey-container/issues/9
ReplyDeleteIf I found something odd on my app I'll surely update the issue with feedback. I'm not really doing database stuff inside the FMX Form; its just pure visual controls that looks nicer than VCL :)