corneliusdavid

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!

@Remy Lebeau Thanks for the correction and explanation.

Got it. Thanks!

Yes: https://docwiki.embarcadero.com/RADStudio/Sydney/en/Using_Classic_Bluetooth#Discovering_and_Pairing_with_Remote_Devices

This should be reported to Embarcadero. Until it's fixed, restart the IDE every couple of hours, perhaps (I know, lame work-around). I pulled up Delphi XE to compare, turned on Auto Invoke (I had it unchecked) and the first time I started typing a method, I had to hit Ctrl+Space but after that it did come up automatically. Back to Delphi 10.4/11... you're right, it doesn't work. Found it's already reported in QC: RSP-29827. This one, I don't understand. If you use code completion, the method name and its parameters are placed in the code before you type it, so how could they already be there? In your example, let's say you type "say" and hit Ctrl+Space for code completion, you wouldn't have typed ('') yet so I would expect code completion to put in "SayThis()" for you; how did the extra set of parenthesis with quotes get there?

Delphi has the TBeacon component that can be configured to listen to BLE devices without pairing: https://docwiki.embarcadero.com/RADStudio/Sydney/en/Using_Beacons

No, there are many free or inexpensive places to get icons and packs of standard images for small and simple use. Here are some: Glyfx has been around a while. Icons8 is on GetIt. The Noun Project. All of these have free samples or restricted plans along with a variety of pricing plans for heavier use or higher resolution images.

I don't see any of the Object Inspector or Structure Pane problems you mention. I tried everything in both a FireMonkey and VCL project. I don't totally get the last two items, I always hit Ctrl+Space when I want a suggestion for code completion or parenthesis--didn't even think about it. I haven't seen the double-parenthesis unless I type them. Can you tell us about your environment: Windows OS version Memory Hard disk space free Monitor resolution Project size Maybe if you're using a 32-bit OS (unsupported) or have very little memory free or something else, it could be affecting this. Also check Tools > Options > User Interface > Editor > Language and look at each of the tabs under Delphi to make sure you haven't missed a checkbox to get the Code Completion working for you. Delphi 11 has some problems and it was probably released too early but it certainly is not unusable.

So you don't actually want to "convert" the website into a mobile app, you want to write a mobile app to access the content of a website built with WordPress, right?

FireMonkey is for both Delphi and C++Builder. Start here to learn about FireMonkey: https://docwiki.embarcadero.com/RADStudio/Alexandria/en/FireMonkey Then find examples here: https://github.com/FMXExpress/Firemonkey

It's been a while since I used C++ but I think you might need to use a StringBuilder class and call methods to concatenate string.

This sounds really slick at first but would this actually work? The base filenames are the same but if you switch the View in the designer and make any change, the Delphi IDE creates a copy of the .fmx file with a different filename for that view in the same folder, so you'd have to constantly be moving those files to their platform folders. Or only looking at certain units in certain views. I agree putting {$IFDEF}s in the .dpr is not only a bad idea but difficult to manage as adding/removing units to the project rewrites it. If sub-forms are loaded and managed from the main form (or somewhere else other than the project) then using {$IFDEF}s in uses clauses isn't so bad--but then you don't have all of the used units listed in the project--which are used by some external tools.

Yes, for database and other non-GUI and platform-agnostic stuff, keep it simple and write a VCL app to build out and test those features, keeping them completely separate. This is an excellent use case for writing event handlers. This is a nice approach--keeps the code cleaner. That's a great idea--use the best controls for each platform. Grids are a lot easier to work with than ListViews but ListViews are better for small devices. The only thing is that as soon as you view a form in the designer using a different platform view, it creates another .fmx file (e.g. .iPhone.fmx, iPhone47in.fmx, iPhone55in.fmx, .LgXhdpiPh.fmx, .Macintosh.fmx, etc.) so then you have to manage those but still, I like the approach.

@mvanrijnen, no worries, take care of yourself.

Oh, so you send the username/password in the first API call, get back a session id, then use that for subsequent API calls. And THAT is where the problem occurs, when doing the same thing from a different device and it returns a different session id but you can't use a different session id for the same login.

That uses the TBackendAuth component, different than simply accessing a custom API endpoint. I've accessed API endpoints using the same login from multiple computers nearly simultaneously. But the authentication component logs in, then you do your user management, then logout--that's a very different scenario, isn't it?

Admittedly, I've only used it for simple apps to test and understand RAD Server. What you're saying is that each connection must be logged in with a separate user, right? For a per-user license of RAD Server, I guess it's ensuring the license fee won't be abused.

It's not a web server. It's a REST server that can run stand-alone or through a web server such as IIS or Apache. It provides a framework with user management on a robust and encrypted database onto which you can easily add custom-written API endpoints for REST clients.

If I was starting a new application targeting multiple platforms, I would develop for all platforms simultaneously while building the app. The reason is that different platforms will have slightly different ways of doing things and if you build the app to work well on one platform then address needs of others, it may affect some screen design decisions you would've made differently earlier. For example, iPhones and iPads don't have a back button but Android devices usually do so if you write the app with the assumption of an Android device first and assume everyone will have a back button, your screen may be too cluttered to add a back button later when you add the iOS platform. That's just one simple example and of course you should be aware of platform differences up front (and never make assumptions, etc.). There are many other considerations such as screen size and orientation, which style will you apply for the different platforms and how do all the different edit controls look and feel. All these things have subtle influences on your screen design. It's much easier to make those decisions in the early stages than to then try to morph a feature-complete app for another platform.