Rollo62

Probably you have old and new units in the search path. Maybe you check your search paths and cleanup a little. I usually also clean all compiled project *.DCU, and re-build them all, which helps to avoid such strange linking error.

@Daniel I already made such proposal of a "CanIUse" page for Delphi and the most important 3rd party components. Maybe thats worth to think about, and to add in DelphiPraxis ? I would vote for this

It was not a new warning, aside the already known ones, but in my case it took much longer to process until it appears in the PlayStore (about some hours now). Usually when I published an app, I could see immediately a note "its available in the play store now", but this time not. Probably this was only because of bad timing of my update 31.07. (one day before the 01.08. break), I haven't checked whats happening now, after 01.08., but I soon will check that (if it takes any longer with the confirmation letter from Google).

Yes, that is true. I didn't made any benchmarks, but regarding compile-time my gut feeling tells me that Macos64 right now compiles significantly slower than Macos32. So I hope that this is only an effect of the initial version, and that optimization as well as compile-speed will be enhanced to normal in the next update(s).

I was trying to prepare new versions until yesterday, so I had hope that until 31.07.19 app still were processing normally. Unfortunately it seems not the case for me, at least for some apps I got a note. In parallel I asked for the Delphi extensions of various apps, but I got no direct, automatic "email received" message from Google, which is somewhat strange. Instead I received only a very simple "be patient" site after filling out the form. Does anybody else have this experience, and how long should I wait until Googles reply (3 days, 4 days, ...) ? I'm afraid they are a little bit busy now, checking a lot of extensions. Would be good to know how long this process might need, and how many pitfalls it might have, please share if you have some tipps and experiences. Edit: Oh, sorry. I just doublechecked, the app seems online in the store, although yesterday it didn't proceed as normally. The "processing" seems to take much longer as usual (seems to getting a little closer to Apple procedures now )

@Dave Nottage Well thanks, perfect tip again. I was alrerady diving deep in other tasked, but I just doublechecked this. There was a well hidden reference in OSX-specific code (typical copy-paste problem ) This reference was nicely separated in its own OSX unit uses {$IF Defined(IOS)} Sys.Power.WakeLock.Impl.iOS {$ELSEIF Defined(ANDROID)} Sys.Power.WakeLock.Impl.Android {$ELSEIF Defined(MSWINDOWS)} Sys.Power.WakeLock.Impl.Win {$ELSEIF Defined(MACOS)} Sys.Power.WakeLock.Impl.OSX {$ELSE} {$MESSAGE Error 'IWakeLock not supported on this platform'} {$ENDIF} ; but unfortunately the hidden reference resides in a region unit Sys.Power.WakeLock.Impl.OSX; .... {$REGION 'Windows helper functions'} function SetThreadExecutionState(esFlags: EXECUTION_STATE): EXECUTION_STATE; stdcall; external 'kernel32.dll'; {$ENDREGION} So this was hardly visible, if region was not expanded. Anyway, it was just this line, never used in the unit at all. Thats a good reason why I tend to avoid regions usually, and here I had one of the few places where I still used it by accident. I wonder why this never got any message/warning/hint/ under Macos32 ? Maybe Macos can make use of Windows kernel32.dll somehow Thanks for pointing me in the right direction. App is running now normally under Macos64 ( w/o any changes), even with the dirty Spring4D fix, and more important for me with Bluetooth LE support running at same code under Macos32/64 Bit (which was my biggest worry for me). Looks very good, need more time to test, but so far all is running out of the box. At compiletime I still get a warning: So maybe one day I find where this reference is, but for now I will check and test the more important parts. @Fritzew Thanks for the info, then I will be able re-test all my Spring4D related code soon. Since I already postponed this to the latest possible moment, and just started with the first project.

Not that it helps you here, but I try to separate code into separate units, as much as possible. So that I can bind the right routines like here: {$DEFINE ___USE_VERSION1} {$DEFINE _X_USE_VERSION2} {$DEFINE ___USE_VERSION3} uses ... {$IF DEFINED _X_USE_VERSION1} Feature.Version1 {$ELSEIF DEFINED _X_USE_VERSION2} Feature.Version2 {$ELSEIF DEFINED _X_USE_VERSION3} Feature.Version3 {$ENDIF} Which makes matters much more clear and readable. And YES: I also would like to see if I'm in the active part of an IFDEF, good feature. Wouldn't like to see it as comment, but as a kind of comment with slightly different color (maybe darker green), that would be OK for me.

I agree to what was said before, but maybe this and this info helps for additional tests.

Dear all, I'm still intensively testing all my projects under Rx10.3.2, and I reach now the following error in my Macos test machine: This happens when trying to load and debug an app on Macos, I already could debug other apps successfully in same setup. PAServer loads some files, but then stops with above message. The only difference is that I upgraded this project as described here, while other projects still just opened from 10.3.1 .dproj versions. Anyway, this app is running well on Android, iOS still to be tested. Compiling possible on all platforms without errors. The error message leads to some kind of linking error, missing file for sqlite3 distribution. In the web I found some solutions, like "upgrade OS" or "add missing libs", but hard to say whats missing in my setup ... My current setup is - RadStudio 10.3.2 Enterprise, running in VM under Win10 - iMac 2017 - Macos 10.12.6 Sierra ! Please don't recommend to upgrade the iMac to latest OS, since I use this specific iMac hardware to debug Bluetooth LE fastly, and this is the last OS version running BLE without problems for me. So usually all libs should be included in the deployment automatically, but mayxbe the libs used are too modern to be running on older OS. So either I could doengrade my libSqlite3, or I upgrade my iMac somehow. Maybe there is somebody who could help me out of this ugly situation ? Edit: I've used SDK 10.14 before, and now tried again with the SDK 10.14 Updated from the iMac, with same error message.

Hello @Dave Nottage, thank you very much for the clarification, I already thought into that direction. From where did you get that note about the "featured file" ? Since I was a little concerned about from where to pick the right build that doesn't crash somewhere else, but those thoughts turns out to be a no-brainer: Its available under Bds\Studio\20.0\binosx or binosx64. Again Delphi brings everything needed for the job with it Thanks much your help, so I can further focus on porting and testing now.

Do you know this nice tutorial from Craig Chapman ?

"By regedit" you mean like this ?

I even have to deal with Scratch these days, which is close to what I would call "non-programming language", but surely I'm wrong.

No no no, this topic is a highly armed war zone. Never trust a Java developer (C++ you can trust, its a COMPILER) @David Heffernan (Oh man, of coarse you're right )

Would be probably too much, I just checked the diff files only of Delhi sources: 235 files. Better to make such analysis with your own git/diff tool, and search for certain areas of interest.

The separate constant doesn'T make much sense, but is also not bothering me. In the TStringHelper together with this in the link below, it could be getting more useful though: http://docwiki.embarcadero.com/Libraries/Tokyo/en/System.SysUtils.TStringHelper.IsNullOrEmpty Depending if the strings would be nullable. The description hier doesn't really give a clue what null should really mean: This will be maybe useful in a later version

Better risky than out of business

I like the general idea, but mostly the ARM side I see as problematic. Are there even ways in Delphi to embed ARM assemler code, I'm afraid not ? Never checked how that can be possible, so the libraries probably have to be written with 3rd party tools.

Yes indeed, I didn't tried that.

@edwinyzh Thanks for the info, Nice project, but Gitee seems impossible to register for download. Any hints ?

https://www.cdata.com/drivers/csv/firedac/ Good questions, these are basically FireDac componenets, so they should be cross-platform. Not checked if they have any visual components too, but I don't think so. If the Enterprise connectors wouldn't be only available bundled as 80+, 160+ components, but available single or more granular, I would have tested them already.

Components visible:= false, true; may reorder components.

@Dalija Prasnikar Yes and no. Youre right on the align issue, but I see that the whole align system has big advantages over VCL. It all depends on the point of view maybe. To solve many issues like you described, I simple can pack sub-components in another level with TLayout. Each control can parent any other, and alignment and margins usually work well. This works suprisingly stabile to me, even if I have several levels and complex TFrames inside. Im not yet convinced, also because I cant see any clear alternative to existing FMX design. I still believe thats some parts maybe worth to be reworked, but not the whole System. Encaptulations of different platforms via TPresentationProxy seems a quite reasonable approach to me, to use Styles with possibility of same Basic controls for encapsulation of UI and even animations is a clever move. Maybe there are plenty ways to solve things different, but the FMX way is clearly one possible way indeed, with all pros and cons. Is anything elsa the golden way (Native, Xamarin, Phonegap, Remobjects, CastleGameEngine, Flutter, Unity, Html5, etc.,)? I dont really think that there can be a clear winner in this game, in all disciplins.

@Dalija Prasnikar Ok, good to get your opinion. Maybe it is the wrong question that I'm asking to the framework, since it already works quite well for my purposes. My goal is to have a good abstraction of the underlying OS details, to reach the "one source, all platforms" behaviour. Another goal of mine is to be as close to known VCL as possible, for compatibility and code-reuse reasons. If my goal would be the "most performant framework", I'm clearly better off with C++, native IDE's or others. I only can say that FMX serves its purpose well for my goals right now, only the current maintaining of all platform services is still behind what it could do (many platform services are still missing or faulty or half implemented). Saying that, I must also confess that I work only with quite well tested, reliable primitve objects, like TRectangle, TPath, TLayout, TLabel, TButton, TTabControl, TListView, TFrame, etc., and avoid to touch the more "superior" components in the first place. Maybe only after a lot of practical tests I would consider to use a new component like TMultiView, which I already trried some years ago, but I cancelled that since it caused too many practical issues for me. There are many advanced controls which still show too many issues, so they likely act as practical show stoppers. I'm able to wait until more and more controls may get mature, and also I really don't miss any controls right now. With the abstractions of such "reduced component set" philosopy I can manage my projects well and reliable. Maybe the helpful hint to new FMX users is: Better lower your expectations, not all components keep what they are promising.

Yes thats always an option. But I still think that FMX is not that far from perfect with some tweaks here and there. Btw. That 'burn' would also hit FmxLinux and GlScene in same way since they are close related.