Rollo62

@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.

My favorite is always current version + 1 since Embt was getting so eager in evolving new features and fixing bugs. There were other days were this was not always the case.

What would be your suggestion to "modernize" it, would this be they way like Alcinoe framework ? Or maybe some reworks in the internal structures would be enough ? I hope you have looked more deeper into the FMX structures, and have located the big showstoppers in concept, please let me know. I work with what I have in hand, but of coarse it may be allowed to make some proposals or feature requests if they will increase the cross-platform ability a lot. In my opinion there are a lot of good things in the kind of how FMX does its platform encapsulation, same for the basic idea of separation the UI from logic by Styles (which could have a huge potential, if it would be really finetuned and simplified). The ability to provide styled and platform controls is also a big advantage over other solutions, of coarse it would be perfect if each platform control and other classes would be "always 100%" be ported to Delphi, not only a minimum functionality to get the basic demos running. My first wish would be that Styles would be enhanced to be more flexible and vector-based (or primitive based), beside the huge PNG wallpapers. To simplify tweaks of existing designs (re-color, re-shape), instead of creating complete new, large PNG wallpapers by external designers for simple style re-designs.

Maybe Delphi 5, because still so many people are using this. (And this is the biggest problem with Delphi probably).

There was an old (very interesting) product from Embarcadero around: HTLM5Builder. http://www.drdobbs.com/web-development/embarcadero-html5-builder-actually-quite/240006712 Unfortunately this is quite dead and unsupported, but its still there. The efficieny was not good enough, at that time, so the PHP crowd preferred the traditional PHP Ide's for a good reason. I would also hope that in one (long distant) future, maybe PHP will be integrated in the IDE as platform too Ok, ok, lets stop dreaming Maybe this is what you're looking for ?

Right, I hope that too. Its important that KSDev (same as everybody else) can make a good living from their products, otherwise the support may starve. Better to long-term cooperate with external, good companies than to buy out technology completely and filleting out only the good parts without further support and understanding the concepts behind. So I hope that Eugene is suprising us with new ideas and amazing technology many more years in the future

This looks like beautiful pointer and math magic to me. If this works as expected, it would be worth to figure out why, you're right. I never looked into crypto algorithms too deeply, but probably this could be a common practice to safe some computing power and/or memory by fractioning or grouping the memory access somehow. Maybe you can find similar structure in C++ or somewhere else too, with a little more description.

Do you really need that feature still to avoid out-of-memory ? In recent versions of the IDE this was much improved, and I haven't used it anymore since the last versions.

@Remy Yes, thanks for pushing me in the right direction. I already tried a "file unlocker" tools, but I found re-boot more clean, also to prevent IDE to get same damage. Most like this happens in my case during debugging, that some files were not freed from the IDE. Step 1. close/open IDE fixes this in 50% of the cases Step 2- reboot fixes the lasat 50% So my rough guess who is blocking the file: 1. IDE, 2. ADB Unfortunately always when this happens: I am deeply in some urgent, development, debugging tasks, etc., so that searching such remote issue is not my top priority. But I promise to look after this issue more eager next time when it happens, and to get a note here if I have some findings

No, i have seldom time for deeper investigations. Usually closing open Apps might help in 80% of the time, Only sometimes need to Reboot OS. Since this happens not quite offen indeed, I can live with it. I only have a feeling that these issues happened in later Win10 versions more offen.

Upwork Freelancer site could be an option too.

Would be good to understand the real cause of this behaviour, since I noticed this since Win10 only, and I doubt that AntiVir is the real reason. I still hope this can be fixed once and forever for any software.

Would be a very useful option. Unfortunately I have never noticed this in my keychain.

You better check the link, and check your Apple MemberCenter first, if you don't have access probably Apple won't let you in w/o permission from the original developer account.

From your explanation I'm unsure if the project already has been registered in the Apple Developer Membercenter at all. Was the app distributed once before, or not, ? Then you should have followed all these steps. Have you checked if there is a provisioning certificate for distribution ? The apps BundleID shall match the former settings 1:1.

@Hans♫ Have you tried this with a complete new, empty project from the scratch ? if not I would recommend so.

@Schokohase I do write untit tests, and I know about the problems that globals and threads can create. Still I think in many cases, like above data storage which are seldomly accessed, the risk may be acceptable. Also not many Singleton implementations out there seems to care about thread safety. So does your post mean that you would generally recommend to make the global singletons threadsafe ?

@PeterBelow I prefer the same, and use it in many places like that. But not all the time (usually these classes are called seldomly), but there is always a tiny chance that these singletons might crash because they are not threadsafe. I never had such case, but its always on my mind that it could in some cases, where those failures would be hard to find. Would you recommend or not recommend to make such simple data storage classes generally threadsafe ?

Same what I think. If missing clarity would have been a problem, then it would take only a few hours to correct that, before loosing hundrets of loyal customers. Such a big damage to Embarcaderos trust and reputation (again and again) should not left open with two eyes closed by the management.

Debugging works for me (most of the time). Generally I have ony the tip to keep apps as modular as posssible, so to be able to test each module functinaly separately. Best of all try to develop single modules under Win or if special mobile behaviour: test under Android/iOS, so to reach reasonable turnaround cycles. Smaller, separated test apps compile usually fine and also deployment is much faster. Only when the app is close to final testing the complete final app, by putting all single modules together, is slower and then hopefully works as expected. Also I wonder where the bottlenecks really lay and howto improve, but this is probably by a lot of files shuffling around for signing, deployment, packaging, etc. So a fast hardware and SSD and enough RAM capacity is of coarse a must.