corneliusdavid

Firebird is awesome--works well as either embedded or server, so it can scale with your app. SQLite is small and nimble and available on every single platform. If you have a choice, do not use Access--you will have many problems down the road.

I use this a lot and it works well for a variety of use cases. You can create the component in code pretty easily. GExperts has a nifty tool to do this for you. The TTaskDialog component can be placed on a data module; it can also be called from another unit (or form or data module) to keep your form clean.

I clicked on the link and it can't be found; searched for the title and couldn't be found either.

I have the following: Delphi 11 on Windows 10 and Windows 11 Mac Mini with macOS Monterey 12.0.1 on a 3 GHz Intel Core i5 Platform Assistant Server vr. 13.0.12.0 iPad and iPhone both running iOS 15.1 I've had problems in the linker process trying to get even the simplest bare-bones app to build for iOS. I have no problem with Android or MacOS--it's just iOS. At first, I had an error finding the /System/Library/PrivateFrameworks directory. Looking through the SDK Manager for iPhoneOS 15.0, I found a the Remote Path with that entry and removed it--since it didn't exist on the mace where I found other framework folders. Now I get the following error: [DCC Error] E2597 ld: file not found: /System/Library/PrivateFrameworks/DocumentManager.framework/DocumentManager for architecture arm64 I cannot figure out why it tries to link that file and why, if it expects it, that directory does not exist on the Mac--like I mentioned, other "framework" folders exist. I've removed and re-added the iOS platform looked through the .dproj, and refreshed cached SDK files. I've got this problem on two different computers and have run out of ideas--and patience. Anyone have any suggestions?

A few other pieces of information might be handy to make a good decision. If there are just a few of these corporate customers and the only branding is the logo, getting the logo and building a custom install from your compiled application would be relatively simple to manage--I've done something similar to this. And yes, like @Vandrovnik mentioned, InnoSetup is great for this--either for you embedding a custom logo or with them supplying a logo with the right name and size in the right location so the installer can find it. But if your customers want to do a lot more than just the logo, like customize some labels or options or set colors and distribute a whole "themed" application, then I would suggest building a theme packager (could be as simple as zipping some files) and making it simple for them to create a theme and package it for their own distribution. Your installer would have to look for a theme package and apply it and you'd deploy a basic theme. My experience with any sort of theme or customization is that there will always be little changes here and there after it's "done" and you don't want manage all those for all the customers, so giving your customers the ability to mange those for themselves would be highly preferable. In any case, you want your base application the same between paid and free if at all possible, and some sort of long, encrypted license key or something that unlocks the full power for the paid version.

It's called "Coding in Delphi and Beyond". I changed it to "Just Another Developer Blog" a few months ago because I didn't want people to think it was connected to the books by Nick Hodges. Last night, I found it listed in "begin end" with the original name so just changed my blog's name back to that. Now I gotta go change my signature line here again.

You're welcome. I didn't even know my blog was listed in there! Cool!

This seems a little harsh. I use a lot of code that others have written and which I cannot see (or haven't looked at). I sleep just fine at night. I don't have time to personally look at and test everyone else's code but trust that it works as described. Of course, it's wise to test the finished product that uses unseen code modules to make sure the end result is what you're after. In this case, there's a specific problem for which an answer is being sought and being able to see what the components do by looking at the code could help but will it actually take less time tracing through thousands of lines of unfamiliar classes than it would to post a question on a forum?

I haven't tried this and am just thinking out loud but couldn't you use a FDBatchMove component and save yourself some code? It seems like you could set up a Dataset Reader and Writer and then just tell it to go.

Like Attila said. Here's a recent blog of mine about it: https://corneliusconcepts.tech/delphi-productivity-tips-navigation-toolbar

This is a great feature--I've used it both for proof-reading and for simple keyboard macro expansion (before Live Templates). Using GExpert's Code Proofreader or Delphi's Live Templates, you can either auto-correct your most common misspellings or set up small keyboard macros to do the typing for you. For example, instead of typing "length" you could type "lg" and it would be expanded to "length" for you. I misspell "string" a lot and so set up "sg" to type it out for me. This productivity trick saves a lot of time--I blogged about it a few months ago: https://corneliusconcepts.tech/delphi-productivity-tips-live-templates

True. Somewhere back in time, I thought I had heard or read this and well, it made sense (to me) and a quick test of this one particular case in one particular version of Delphi confirmed my thinking but you're right, it certainly does not prove a rule. The much, MUCH better way is to just avoid writing obscure code in the first place.

Here's the one for Delphi Does Low Code Cross Platform REST Client under 30 Minutes!: https://github.com/corneliusdavid/Wordnik4Delphi

Uh, both the subject of this thread and your original question specifically asked for async dialogs: So I guess I'll let someone else try and answer your question.

uses FMX.DialogService.Async; procedure TestAsyncDlg; begin TDialogServiceAsync.MessageDialog('Hello Android!', TMsgDlgType.mtInformation, [TMsgDlgBtn.mbOK], TMsgDlgBtn.mbOK, 0); end;

Yes, for simple variables but I'm pretty sure that functions have to be evaluated first. I ran a simple test of OP's code and verified before I answered. I ran it in Delphi 10.4; perhaps an earlier version of Delphi (or a compiler directive?) would change that. I totally agree with this.

Yes. Order is not important here because the function must be run before the expression can be evaluated.

I'm going to take a guess that it's easier because you're used to writing the code to do that. I'll bet, with a bit of research and experimentation, you could save yourself a lot of code using a "fancy flowgrid/panel/etc". These components make laying things out not only very quick and easy but also work with fluid form sizes (like mobile devices) a breeze when things change at runtime. Of course, desktop apps often have a rigid layout so it's not critical, but since this discussion is based on FireMonkey, we can't assume it isn't mobile.

Whether to build the controls dynamically depends on your project--if you have a lot of buttons or want them added dynamically based on configuration or options or something, then that's very doable. It's a little easier to see how everything will fit and look if you do it at design-time, though. For activating when you hover over a button, use the MouseEnter and MouseLeave events.

For a "grid" of buttons, you don't need to use a grid control--the first thing I thought you meant when I was reading this. Instead just place the buttons in a grid-like manner on a form or panel. I would highly recommend using a FlowLayout to provide automatic arrangement of the buttons to accommodate both landscape and portrait views of the app (if you're aiming to put this on small devices). Watch this Embarcadero video that demonstrates the concept.

This is why I use the constant sLineBreak as defined in the System unit.

Excellent!

I agree. Since I discovered TStopWatch (in the RTL's Diagnostics unit), I use it exclusively for any timing as it's so simple. It's been in Delphi at least back to XE if not before. No use writing your own timing routines anymore.

There could be a whole bunch of reasons but we'd just be shooting in the dark unless you show some code (and possibly surrounding contextual code). Did you do a build/compile without debugging and then look to see if there's a little dot to the left of the code line in the editor which indicates it's a line that will be executed? Have you tried breaking at other points in the code? Does the app actually run?

FYI.. Andreas released an update to DDevExtensions for Delphi 10.4 in July, 2021. However, it's really nice that we have two places to get this feature. Thanks @dummzeuch!