Does Delphi have a future?

I've been using Delphi for almost 20 years now, I have worked in various industries and have also used other languages and IDEs like C#, Xcode, VB.Net, but while developing in other languages I have always been doing something with Delphi and I am a big fan of it. There are many reasons why I enjoy and have a preference to develop some applications in Delphi, but recently I have one problem with it.

The problem I have with Delphi is its future and the question that gets raised 'how easy is it to employ new developers?'. In the UK it is almost impossible to employ a good Delphi developer and can take years to find one. The other option is to employ a developer with good OOP skills and knowledge of a similar language like C# and for them to learn the language (currently no Pluralsight courses). The problem with employing a developer who does not know Delphi is they do not want to learn Delphi, it is not a big enough carrot on the stick and salaries in the UK are less than other languages.

What I would like to know are the selling points of Delphi to a young person who knows OOP and has some experience in software development. I asked myself the question, 'if I was young and needed to choose a language and development environment, would I invest my future in Delphi?' The short and current answer is 'No'.

Delphi features that I was not aware of

The other day I came across a feature of Delphi that in my 18+ years of using Delphi have never used, it is the 'Hide Non-Visual Components' (Ctrl+H) when design a form. I came across this because another Developer pointed out to me that he could not see the menu controls on a form. I thought there might be an option somewhere and on the right click menu was the option.

I have never used this feature and it got me thinking what other features are there that I am not aware of (Delphi Berlin) and are there any that I might use. Here are 2 lists of features I have since discovered, one list is for ones that I think are pointless and I would never use and the other for features that I believe are useful.

Features I've found that I think I will never use:

1. Quick Icon - right click menu option in the form designer.
2. Quick Edit - right click menu option in the form designer.
3. Flip Children - right click menu option in the form designer. I think I'v seen this before, but have never used it and cannot think of when I would.
4. Lock Controls - main menu > edit. This feature locks some controls on forms from resizing and moving. This feature has strange behaviour as it sometimes locks the resize, but not the ability to move the control, try locking the controls, closing the form and opening it again and the size of the controls cannot be changed but the positions can. Clearly never been through QA.
5. Scale - main menu option > edit. This gives the developer the feature to scale a form and it's controls be a percentage. 

Features I've found that could be useful:

1. Surround > Region - right click menu option in the code editor. 
2. Search for Usages - right click menu option in the code editor.  

This is just a brief list of features that I have found over the last couple of day that I was not aware of, most of which I will never use. There are most likely other features in Delphi I have yet to discover that are of some use. 

Why does TSpinEdit not enforce the MaxValue property?

With a TSpinEdit there is a property called 'MaxValue', from the name it implies that the maximum value for the control is what value you set for the property, but this is not the case. The property sets the maximum value for using the spin edit buttons, a user can enter a value exceeding the maximum value by using the keyboard up to the value of an Int64 (9,223,372,036,854,775,807).

This seems to have been done by design, but I cannot see a valid reason for this and it could be a little dangerous when being used to control the valid values entered.  

By putting the following in the OnChange event I've managed to get around the problem. Not sure if there is a better solution. 

if (Sender is TSpinEdit) then

begin

    if (Sender as TSpinEdit).Value > (Sender as TSpinEdit).MaxValue then

    begin

        (Sender as TSpinEdit).Value := (Sender as TSpinEdit).MaxValue;

    end;

end;

Why is there no Delphi error provider?

Recently I've been looking at the best solution for displaying a data entry validation error, for example when a user needs to enter a description that is not a duplicate and they enter a duplicate the user is informed of the error. Many web sites will display an error below the text box highlighting an error, or displaying an error icon next to the text box. In C# (Visual Studio 2017) when developing a forms application there is a 'ErrorProvider' component that is easy to use and displays an icon on the right (exclamation mark by default) with a hint that can contain the error text.

What I am looking for is something similar in Delphi (I am currently using Berlin), and I am surprised there is no 'out of the box' standard component that ships with Delphi that can do this.

I have looked at using a TButtonedEdit control with a right button visible with an exclamation mark as the icon when there is an error, but this does not work well.

I imagine that how software informs a user of a data entry validation error is subjective and some developers will have different ideas, but I am interested in what other developers think and are there any decent 3rd party products that have a single error component.       

Animate opening and closing a panel

Thought I would share an example of how I animate the opening and closing of a panel that can contain various controls and how each control can also be animated.

Here is the example code:

unit AnimatePanelFrm;

interface

uses
    Winapi.Windows, Winapi.Messages, System.SysUtils, System.Variants, System.Classes, Vcl.Graphics,
    Vcl.Controls, Vcl.Forms, Vcl.Dialogs, Vcl.StdCtrls, Vcl.Buttons, Vcl.ExtCtrls;

type
    TForm1 = class(TForm)
        Panel1 : TPanel;
        Shape1 : TShape;
        Label1 : TLabel;
        BitBtn1 : TBitBtn;
        BitBtn2 : TBitBtn;
        BitBtn3 : TBitBtn;
        BitBtn4 : TBitBtn;
        procedure Label1Click(Sender : TObject);
    private
        {Private declarations}
    public
        {Public declarations}
    end;

var
    Form1 : TForm1;

implementation

{$R *.dfm}

procedure TForm1.Label1Click(Sender : TObject);

const
    Expanded_Height = 106;
    Collapse_Height = 44;
    Speed           = 100;
    Speed2          = 200;
begin

    AnimateWindow(BitBtn1.Handle, Speed, AW_HOR_NEGATIVE OR AW_SLIDE OR AW_HIDE);
    AnimateWindow(BitBtn2.Handle, Speed, AW_HOR_NEGATIVE OR AW_SLIDE OR AW_HIDE);
    AnimateWindow(BitBtn3.Handle, Speed, AW_HOR_NEGATIVE OR AW_SLIDE OR AW_HIDE);
    AnimateWindow(BitBtn4.Handle, Speed, AW_HOR_NEGATIVE OR AW_SLIDE OR AW_HIDE);

    AnimateWindow(Panel1.Handle, Speed2, AW_VER_NEGATIVE OR AW_SLIDE OR AW_HIDE);
    if Panel1.Height = Expanded_Height then
        Panel1.Height := Collapse_Height
    else
        Panel1.Height := Expanded_Height;
    AnimateWindow(Panel1.Handle, Speed2, AW_VER_POSITIVE OR AW_SLIDE OR AW_ACTIVATE);

    AnimateWindow(BitBtn4.Handle, Speed, AW_VER_POSITIVE OR AW_SLIDE OR AW_ACTIVATE);
    AnimateWindow(BitBtn3.Handle, Speed, AW_HOR_POSITIVE OR AW_SLIDE OR AW_ACTIVATE);
    AnimateWindow(BitBtn2.Handle, Speed, AW_HOR_POSITIVE OR AW_SLIDE OR AW_ACTIVATE);
    AnimateWindow(BitBtn1.Handle, Speed, AW_HOR_POSITIVE OR AW_SLIDE OR AW_ACTIVATE);

end;

end.

Project setting for absolute paths

I've noticed that with the current version of Delphi (Berlin) the project file (.dpr) uses relative paths and when you manually change the paths to absolute paths and then add a something to the project (e.g. a .pas file) it converts them back to relative paths.

I prefer to use relative paths, however the problem I have is that both the MD and the Development Manager at the company insist on using absolute paths, the MD seems to think and apparently has heard that using relative paths can causes problems. I cannot find any project or environmental setting to force the paths for the project files in the .dpr file to be absolute. Does anyone know of such a setting or why relative paths in the .dpr file cause problems? 

Can and should user access permissions be stored in Active Directory?

I am currently looking at various designs of how to store user permissions, it is most likely I will choose on a Role Based Access Control (RBAC) and my original thought was to store the various role permissions in the database and in the application there would be an area that would allow an administrator to control the various user roles and role permissions. But some developers have mentioned to me not to do this and allow 'Active Directory' to control the various user permissions. This would mean that the access definitions (rules) would not need to be in the database and the control of these permissions do not need to be done in an application. I imagine the access enforcement to the various areas of the software e.g. Purchase Orders would still need to be controlled by the application and how the application interrogates the active directory permissions I still do not know.

The developers who have suggested doing this give the impression that it is possible and easier (saving time) than doing the access control using the database and application, although they have never done it themselves. Before I journey into how to develop for Active Directory, does anyone have experience of using it for access control for multiple areas of a Delphi application, and is this the direction access control is going for applications?