FMX Flexcel macOS 64-bit?

Does the Flexcel component also work with macOS 64-bit target platform (Delphi 10.3.2)?

...and does it allow to create xlsx files without any grid involved (like OExport)?

Hi,

We haven't released yet the version that works in macOS64, it will be released in the following weeks. Macos64 is working fine, but we need to fix other unrelated stuff before we can make a release.

About the grid, FlexCel doesn't have any grid, and everything you do with it is with code.

Ok, thanks. It seems to be exactly what I need, except "weeks" makes me headache, I cant put my product for weeks on ice :(

If you are not exporting charts to pdf/html/etc, we have a version right now that you can use and will work in OSX64. If you have a FlexCel license, just email me at adrian@tmssoftware.com  and I'll send you a link for that version.


We can't unfortunately rush FlexCel 7 more: I'd love of course to have it released yesterday, but quality is for us the most important thing. We will release it when it is working as expected.

I did not purchase a license yet, but will now do. After that, I will email you. I dont need to export charts etc. to pdf and so on, all I need to so is writing some array content to xlsx files.

I've sent you the link by email, let me know if you have any issues.

Thank you, I am installing it at the moment. I will report back any issue I encounter. Again, thanks for the quick help with this!

Hm I encounter a huge slowdown in the IDE when I add the unit to the uses clause.

When adding FMX.FlexCel.Core and FlexCel.XlsAdapter to the uses clause, compiling takes 3-4 times longer, also code completion cause the IDE to go non responding (but continue after a while).
When I remove the 2 units, all is normal again.
Thats with Delphi 10.3.2 and firemonkey (Win64 target).

FlexCel is a big a complex library (it is a mini-embeded-Excel without the UI - more than 1 million lines of code). And most of that code can't be removed by the linker if you don't use it, because Delphi doesn't know if you will use it. For example, the calculation engine can calculate more than 400 functions: You are likely not using them all, maybe you aren't even using formulas, but we can't know which functions you will use, and you might open any arbitrary file, so all formulas must be included, and some are quite complex. Same goes for conditional formats, tables, charts, you name it. As they say, everybody uses a 10% of Excel, but everybody uses a different 10%, so we have no much option than to implement it all. I've been working almost 20 years in FlexCel almost daily (first native version is from 2001), and there is still a lot of stuff to add.


So sadly in Delphi FlexCel does add some size and compilation time, and it is worse in LLVM-based compilers like the macOS64 one.

But this all being said, the time shouldn't be that much, at least if you leave the files as the installer sets them, and don't add .pas to the library path. If you add the .pas to the library path the time will indeed grow up a lot: Right now you compile FlexCel once when you install it, and then link it. That's why the install takes a long time, but once installed, every rebuild of your project should only add a little of linking time.

I've tried here with a simple app using FlexCel to create a file and set a cell value. All numbers here are from a VM inside a 5-year old skylake i7 (16 gb of ram, but the VM has 6GB assigned to it). Not a bad machine, but not cutting edge either.

msbuild Project1.dproj /target:Build

First run: Time Elapsed 00:00:46.80
Second run: Time Elapsed 00:00:16.53
Third run: Time Elapsed 00:00:15.07
Fourth run: Time Elapsed 00:00:14.65

Note that we are building the full thing every time, but probably due to some warmup, the first time was much slower than the rest.  

Now the numbers by commenting all FlexCel code and units:
First run: Time Elapsed 00:00:07.90  
Second run: Time Elapsed 00:00:07.79

So we are speaking of about 8 seconds without FlexCel (basically an empty app), and 15 secs with it (discarding the first compile which would have also probably have been slower for the empty app).

We could speak about twice the time, but that would make no sense, because it is a fixed time added, not a proportion (double). I mean, if you add code to your app and now it takes 30 seconds to compile without FlexCel, it will take 37 seconds to compile with it, not 60. It is a fixed increase of 7 seconds, in linking time. (the linkers in macos/android/ios are quite slow, in win32 this should be much less). I wish it could be made lower, and we've worked a lot optimizing the code to reduce size (a lot of the size comes from generics, so we even have our own TLists and TDictionaries optimized to add less size to the executable). But there is always a limit on what we can do.

About the slowdown in code completion, I haven't seen much in Delphi 10.3.2, but I am aware that in other machines you can see more. It normally can be higher the first time, but after symbols have been cached, it shouldn't be that slow. And the good part is that it only should affect the unit using FlexCel, not your whole project.

Just to give you an idea of how I see it here, I recorded a small video of coding in OSX64, first in the simple app used for timing above, the in a more complex app like the custom preview demo, just in case that a bigger app could make times much slower:

  http://www.tmssoftware.biz/flexcel/img/codeinsight.mp4

It is indeed a little slower than without FlexCel, but at least here, not that much to be noticeable. If you are seeing slower times, could something else in Delphi be causing it?

Note: As we were speaking about osx64 in previous emails, my mind played me a trick and I did all of this stuff in OSX64, just to realize now that you were mentioning Win64. 
In win64 I actually get better results: 2 secs for empty app and 4 for app+ FlexCel. Again, this is double, but it isn't proportional. It is always a fixed 2 second delay. One thing that is different in Win64 is that the times seem to vary a lot. 4secs is the time to compile with FlexCel in average, but it can go up to 15 seconds in some cases, I am not sure why.

Another note: One way to speed up the linking might be to build with runtime packages, at least when developing. You can always disable the runtime packages when shipping your app.

All right, that explains it for me. I am using a 64GB Windows 10 PC, with an i) 9900K processor, so it should not do that, but code insight always cause the code insight to go non-responding. My project is way above 1mio. lines of code, plus FlexCel, but without FlexCel, code insight is instantly, with FlexCel, always non-responding. But thats minor, because I noticed that all other TMS components are also not yet updated to compile under macOS 64, so I will have to wait anyway.

macos64 support is added & ready in all TMS FNC products.

TMS FMX UI Pack has a beta with macos64 support.
We plan to complete support for all FMX products next week.

Is there a beta of the FMX UI pack available? Currently, I cant use the grid at all. A beta where at least the grid is working would already solve some problems.

@Bruno Fierens: You mentioned FNC pack. If I get the FNC UI pack, I would not need to use any longer the vlc grid and fmx grid and could use the grid from the fnc pack for both, Windows vlc and macos 64 bit FMX apps, right?