corneliusdavid

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!

LOL! Yeah, I like to eat and keep a roof over my head, so I swallow my pride once in a while. This is good insight. I like to give the benefit of the doubt, perhaps too much so. After writing a book that covered all the aspects of the IDE and supporting tools and various platforms, I have a greater appreciation for how much there really is to keep up; that's reinforced when I hear webinars about all the things being worked on and bugs addressed. (But then again, why are there so many bugs?) So hearing these stories do place this thread in better perspective. But I read so many complaints in these forums and well, I guess I feel there's just too much whining sometimes. All too often, employee programmers are caught in the middle between business people only concerned about the bottom line and the plight of the end user that has to use sub-par products. That's why I'm working for myself now--I got sick of not being allowed to upgrade products or redesign a library for better use, even if it has to push out other projects for a few weeks. And if a tool isn't working right for me, I switch tools. I guess that's kind of along the same principle of quitting if a job doesn't work out--but again, it's not feasible when you have thousands or millions of lines of code to deal with.

You make it sound so simple but that's seldom reality. I've had jobs where I've worked on fascinating projects and with great people but there will be one manager that promises things to too many customers and then has to make excuses for why stuff isn't done. When we get on the phone with customers, we're not allowed to talk about internal priorities or other reasons why something isn't done. It's quite frustrating but just walking out isn't always the best choice if there are no other jobs in the area or if other parts of the employment are good enough to keep you there. I was eventually able to leave that company but it took me a while to line up something else.

You mention passwords (and then serial numbers). Instead of encrypting, do you just want to hash it and store the hash, which can't be decrypted? This is often done with passwords (or a serial number that is entered for verification) where you don't ever need to decrypt the stored value, just generate a hash each time it's entered and compare the entered hash to the stored hash.

Yes, I've implemented this technique many times over the years. For example, in a plugin where I don't have easy access to the main application form's handle or when I don't want a global form variable laying around for inadvertent use and just have a quick dialog form to show and destroy. Someone may correct me but as far as I know, it doesn't do any more than set the Owner property; then when the owner is being freed, its destructor checks to see if the Owner is nil and if not, frees it. So, if you assign it, then free it yourself, it'll try to be freed twice unless you set the Owner := nil manually. Conversely, if you don't assign it and don't free it, you'll create a memory leak. (I only mention these as things NOT to do to give more insight into what's happening.)

Since it was created like this from Form1: you don't need to explicitly free it--it will be freed when the owner form, Form1, is freed. Sometimes, however, you want/need to manage it yourself. For example: var Form3: TForm; begin Form3 := TForm3.Create(nil); try // do stuff... finally Form3.Free; end; This may be the case if you don't have a current form available.

Excellent! There's a whole chapter devoted to Bluetooth (class & low-energy). BLE builds on Classic and Beacons build on BLE. It was a hard chapter to research. I hope it helps!