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'.
Showing posts with label problem. Show all posts
Showing posts with label problem. Show all posts
Friday, 14 September 2018
Thursday, 23 February 2017
Strict Private Problem with Code Completion
Some time ago I noticed something annoying in Delphi XE with 'Strict Private' and code completion.
Here is an example:
TMyClass = class(TObject)
strict private
public
property Test: string read FTest write FTest;
end;
When I do CTRL + Shift + C to add the private member to the class it does the following:
TMyClass = class(TObject)
strict private
private
FTest: string;
published
public
property Test: string read FTest write FTest;
end;
It adds FTest to the private section of the class and also adds the published section, which is not what I want, but if I remove 'strict' it does not add the 'published' section. Because of this I develop my classes as 'private' and then once I have added all the require properties then I add 'strict' if required. I am not sure if this behaviour is some setting somewhere that I am not aware of, or whether this is something that might have changed in more recent versions of Delphi. Is there a valid reason to have a 'published' section when there is a 'strict private' section?
Here is an example:
TMyClass = class(TObject)
strict private
public
property Test: string read FTest write FTest;
end;
When I do CTRL + Shift + C to add the private member to the class it does the following:
TMyClass = class(TObject)
strict private
private
FTest: string;
published
public
property Test: string read FTest write FTest;
end;
It adds FTest to the private section of the class and also adds the published section, which is not what I want, but if I remove 'strict' it does not add the 'published' section. Because of this I develop my classes as 'private' and then once I have added all the require properties then I add 'strict' if required. I am not sure if this behaviour is some setting somewhere that I am not aware of, or whether this is something that might have changed in more recent versions of Delphi. Is there a valid reason to have a 'published' section when there is a 'strict private' section?
Sunday, 27 July 2014
Delphi XE Android App Emulator Problem
I have recently been using Delphi XE5 do produce an Android mobile app. All was looking good until I wanted to run the app, the Android SDK comes with an Android emulator, but when I tried running the App from Delphi with the emulator running I just got a blank screen. When I plugged an Android device in it ran fine, so I thought it must be an issue with the emulator. After a few days of using the device I thought I would look into how to fix the emulator issue. All you need to do to fix this problem is to turn on the 'Use host GPU' option when setting up the device in the emulator, after that it will run, however there is another annoying issue, it is very slow.
Thursday, 22 November 2012
Screen flicker with gradient background
Recently I had a problem with flickering when resizing a screen due to a gradient background. The problem was mainly noticeable with control on top of the background. Below are a couple of snippets that might help.
First I tried this:
// Interface
procedure WMEraseBackground(var _message:TMessage); message WM_ERASEBKGND;
// Implementation
procedure TForm.WMEraseBackground(var _message: TMessage);
begin
_message.Result := 1;
end;
This helped with the flicker on the gradient panel, but I noticed other issues with some other controls not painting correctly and a panel having a thicker border. Then I tried this:
// Interface
procedure WMEnterSizeMove(var Message:TWMMove); message WM_ENTERSIZEMOVE;
procedure WMExitSizeMove(var Message:TWMMove); message WM_EXITSIZEMOVE;
procedure TfrmMain.WMEnterSizeMove(var Message: TWMMove);
begin
// Set controls to visible = false
end;
procedure TfrmMain.WMExitSizeMove(var Message: TWMMove);
begin
// Set controls to visible = true
end;
Doing this really helped the other controls from flicking, when the user resizes the window the controls disappear and then reappear once the resize is complete.
First I tried this:
// Interface
procedure WMEraseBackground(var _message:TMessage); message WM_ERASEBKGND;
// Implementation
procedure TForm.WMEraseBackground(var _message: TMessage);
begin
_message.Result := 1;
end;
This helped with the flicker on the gradient panel, but I noticed other issues with some other controls not painting correctly and a panel having a thicker border. Then I tried this:
// Interface
procedure WMEnterSizeMove(var Message:TWMMove); message WM_ENTERSIZEMOVE;
procedure WMExitSizeMove(var Message:TWMMove); message WM_EXITSIZEMOVE;
procedure TfrmMain.WMEnterSizeMove(var Message: TWMMove);
begin
// Set controls to visible = false
end;
procedure TfrmMain.WMExitSizeMove(var Message: TWMMove);
begin
// Set controls to visible = true
end;
Doing this really helped the other controls from flicking, when the user resizes the window the controls disappear and then reappear once the resize is complete.
Labels:
background,
Delphi,
flicker,
flickering,
gradient,
move,
problem,
refresh,
resize,
screen,
solution,
wm_entersizemove,
wm_erasebkgnd,
wm_exitsizemove
Subscribe to:
Posts (Atom)