VCL and VCL styles - bugs and future

[Dalija Prasnikar 1396]

To avoid flooding another thread with unrelated posts about VCL quality and bugs, I have opened this topic for discussion about VCL in general and VCL Styles.

 

First, I would like to respond to comment made by @Attila Kovacs

 

Quote

I'm chanting since ages that VCL is practically abandoned by Emba.

 

VCL is not abandoned, not even close. Maybe it is not receiving too many new features as people would hope so, but it has more to do with its maturity than anything else. FMX (is) was in frenzy development cycle, only because it didn't have the needed features VCL already had, and it still does not have all. So it may have seemed that FMX is getting all the love and attention, but that was not the case.

 

Many new Windows related features introduced since FMX has come to play, are still VCL only. 

Keep in mind that IDE is based on VCL, and I don't see that changing in foreseeable future. VCL is evolving and it will continue to evolve. It is not that FMX is new better, improved framework mean to replace VCL for all purposes, it is framework with completely different architecture and it covers different use cases. While some functionality certainly overlaps, and there are (Windows only) applications where both VCL and FMX can be chosen, there are also applications where VCL is far better (and sometimes, even only viable) choice.

VCL Styles are buggy, they have been buggy since they were introduced in XE2. But, they are now part of the IDE. That means two things. First, IDE is now suffering from some bugs, but it also means that those bugs will get fixed sooner rather than later.

Unfortunately, not all bugs can be solved overnight, and the more specific, reproducible bug reports there are, the higher are chances that those bugs will get a fix.

If you have any filed VCL bug reports you might want to share, please do so. 

Edited March 8, 2021 by Dalija Prasnikar

[Attila Kovacs 629]

So you just gave the things an indian name "not receiving too many new features as people would hope so", and telling us that its evolving but only things getting fixed which are part of the IDE, and mentioning "overnight" fixes and "mature" but buggy since XE2. That was a rollercoaster to read.

[Dalija Prasnikar 1396]

1 hour ago, Attila Kovacs said:

So you just gave the things an indian name "not receiving too many new features as people would hope so", and telling us that its evolving but only things getting fixed which are part of the IDE, and mentioning "overnight" fixes and "mature" but buggy since XE2. That was a rollercoaster to read.

There are two separate things here. VCL and VCL Styles. You said that VCL is being abandoned by Embarcadero and that is simply not true as there is a huge difference between "not receiving too many features" and being abandoned.  Also by "not receiving too many features" I definitely didn't want to say it barely received any. There were numerous features introduced in VCL since XE2, some were VCL only, some were both VCL and FMX. 

 

The part with bugs and IDE and "overnight fixing" is strictly related to VCL Styles. Only introducing styles to IDE exposed how buggy they really are and how much fixing they need. And that amount of fixes cannot be made overnight.

 

VCL is mature framework. I never said that for VCL Styles. VCL Styles were never mature, they are just feature that was never properly finished in the first place.

 

I hope this is more clear now.

[pyscripter 689]

43 minutes ago, Dalija Prasnikar said:

VCL Styles were never mature, they are just feature that was never properly finished in the first place.

Although Vcl.Styles is not mature.  I would say it is usable.   The Delphi IDE is a proof of that.   I have been producing PyScripter with Vcl.Styles for the last five years, and I had no issues that could not be overcome.   And now you can have per monitor aware, styled Delphi applications.

And since this this discussion started about flicker, there are ways of working around that.  The Delphi IDE and PyScripter have minimal flicker.

 

The great thing about Vcl is that applications developed almost 20 years ago, can still work well and look modern,  just by recompiling pretty much the same old code.  I have mentioned this before, just compare to the Microsoft Desktop application landscape.  A new framework is introduced every 3-4 years, mostly incompatible with the others:

- Visual Basic with ActiveX controls

- C++ with Windows API

- WinForms

- WPF

- Silverlight

- Xamarin

- UWP

- WinUI

- MAUI

- Project Reunion

- etc.

 

Where would you be if you invested in Visual Basic and ActiveX controls for example?  Ironically, you can still use ActiveX controls in Delphi if you so wish.

 

 

Edited March 8, 2021 by pyscripter

[Attila Kovacs 629]

Exactly that's why we wish VCL would be threaten a bit better. We don't need fancy calendar components every year, just a solid base where the developer doesn't have to invest hundreds of hours to track down bugs, creating workarounds and hoping the fix proposal will be taken over.

 

For example, if you have theming, and one single bug makes it look dumb, you don't have anything.

If you have HDPI support, but then you have to patch it for yourself and keep syncing the changes with the new releases, you won't be happy.

If you have Raise, you are very angry right now.

 

God bless the 3rd party developers for making professional components and making possible to live the RAD feeling.

 

[aehimself 396]

I just would like to add one more thing to the list, VCL styles renders TRichView.CreateParented unusable.

Microsoft advises to create a rich text editor for RTF manipulation. Imagine that you have a thread:

  TTransformatorThread = Class(TThread)
  strict private
    _document: TStream;
  protected
    Procedure Execute; Override;
  public
    Constructor Create(Const inDocument: TStream); ReIntroduce;
  End;

constructor TTransformatorThread.Create(const inDocument: TStream);
begin
  inherited Create(False);

  _document := inDocument;
end;

procedure TTransformatorThread.Execute;
Var
  rtf: TRichEdit;
  wnd: HWND;
  a, max: Integer;
begin
  inherited;

  _document.Position := 0;

  wnd := AllocateHwnd(nil);
  Try
    rtf := TRichEdit.CreateParented(wnd);
    Try
      rtf.Lines.LoadFromStream(_document);

      rtf.SelStart := Integer.MaxValue;

      max := rtf.SelStart;

      a := 0;

      While a < max Do
      Begin
        rtf.SelStart := a;
        rtf.SelLength := 1;

        rtf.SelAttributes.Color := clRed;

        a := rtf.SelStart + rtf.SelLength;
      End;

      _document.Size := 0;

      rtf.Lines.SaveToStream(_document);

      _document.Position := 0;
    Finally
      FreeAndNil(rtf);
    End;
  Finally
    DeAllocateHwnd(wnd);
  End;
end;

It recolors all sections text to red, but it's only for demonstration. Now, have the following code:

  TForm1 = class(TForm)
    ThreadWatchTimer: TTimer;
    RichEdit1: TRichEdit;
    procedure FormCreate(Sender: TObject);
    procedure ThreadWatchTimerTimer(Sender: TObject);
  strict private
    _doc: TMemoryStream;
    _thd: TTransformatorThread;
  end;

procedure TForm1.FormCreate(Sender: TObject);
begin
  _doc := TMemoryStream.Create;
  _doc.LoadFromFile('C:\Temp\MyDocument.rtf');

  _thd := TTransformatorThread.Create(_doc);

  ThreadWatchTimer.Enabled := True;
end;

procedure TForm1.ThreadWatchTimerTimer(Sender: TObject);
begin
  ThreadWatchTImer.Enabled := Assigned(_thd) And Not _thd.Finished;

  If Not Assigned(_thd) Then
    Exit;

  If _thd.Finished Then
  Begin
    RichEdit1.Lines.LoadFromStream(_doc);
  End;
end;

The theory is easy. You load the document in a stream, pass it to the thread to process and modify it, and when the thread finishes you load the modified content in the rich edit on the form. I know, passing a TStream screams of thread safety but it's simple enough for this demonstration.

 

If you run this without any VCL style active, all works fine. If you set any style... it will load the document but the program will freeze. I suppose the StyleHook is attempting to stylize the hidden rich editor in a background thread, thus causing the lockup.

 

Tested with D11.3, so I suppose previous installations are also affected.

 

Edit: Added test project

richeditstyle.7z

Edited March 17, 2023 by aehimself

[FPiette 382]

Try giving your thread a message pump, and pumping messages while processing the document.

[David Schwartz 426]

On 3/8/2021 at 7:51 AM, Attila Kovacs said:

Exactly that's why we wish VCL would be threaten a bit better.

I'm sorry, but I really don't know what you're going on about. Historically speaking, Borland/Inprise/Codegear/Embt have always maintained a POV where they provide basic components and leave the door open for 3rd-parties to add fancier and more embellished components to the landscape. 

 

The thing you're pointing at really is that the Delphi landscape has been abandoned by most 3rd-party providers. Many of them just closed their doors, and many are making components for C#/.NET instead because the market is two or three orders of magnitude larger than for Delphi components. Follow the money and you'll see where the investments are being made.

 

All of this needs to be taken against a backdrop where the entire industry has become far too fragmented, supporting too many different and incompatible platforms: Windows, MacOS, iOS, Android, Linux, and a bunch of smaller ones. VCL itself ONLY works in Windows while the entire world has shifted to a "mobile-first" development imperative, meaning iOS and/or Android. VCL doesn't get you there. So the MARKET has gone in a different direction entirely!

 

Delphi has FMX to address this, but ... IntraWeb was introduced well over a decade ago and it's still hardly being used. I played with FMX in Windows, and I didn't like it. Everywhere I worked was 100% Windows, so I saw no need to waste my time with FMX.

 

Microsoft creates standards mostly by buying up companies and then announcing their solution is the Next Big Thing. They do that pretty much every year or two, and as a developer who lives and breathes what Microsoft says, you'll need to keep shelling out more and more money to buy the SDK for their Next Big Thing, helping fund their ability to buy something else next year.

 

You also have to abandon the time you've invested learning the last umpteen platforms they bought and shoved down everybody's throats, and learn yet another one that's not compatible with any of the previous ones. And don't forget that every 5-7 years they introduce a new version of Windows that deprecates older features that cause older software to break. (Apple has been doing that a lot more lately as well, and it's very expensive to keep up with all of the software they keep breaking.)

 

From my catbird's seat, the future ahead is WEB APPS. And, sorry to say, neither VCL nor FMX will be useful on those shores.

 

Honestly, I can pound stuff out in VCL incredibly fast. But it's really at the end of its life. There are tons of companies maintaining old Delphi apps written in D7 using VCL and fancy components like DevEx grids and whatnot. They're loathe to upgrade them at all, except on the fringes and where changes in laws require them to fix some things. 

 

Over the last decade, I can't think of anything that has been added to the Delphi language or the VCL that would add any real value to these old apps build in the D7 era. At least the newer versions of Delphi let you continue matintaining them without anything breaking, unlike most Microsoft tools that pay very little heed to backward compatibility. 

Give it up! Your comments make me think if the image of the guy standing in Tianamin Square in China trying to stop a brigade of tanks. 

 

While I totally agree with your general sentiments, this isn't about the VCL or Embt -- Windows Desktop apps are simply not where companies are investing in new software development efforts, and they haven't been for years. Like I said, follow the money and you'll see where the market is heading. Windows apps ain't it.

 

Whether the future is being driven by mobile apps or web apps or AR/VR or AI or thought control ... NONE of that is reachable by VCL!  The VCL is for WINDOWS DESKTOP APPS ONLY! And that is NEVER going to change.

 

The VCL the last general store on a once vibrant Route 66 that has been bypassed by a bigger, faster freeway taking people to other places.

[Attila Kovacs 629]

are you gonna start replying on 2 years old comments? could you please leave me out of this?

[programmerdelphi2k 237]

I said that a book is better than a post.

[PeterBelow 238]

18 hours ago, aehimself said:

I just would like to add one more thing to the list, VCL styles renders TRichView.CreateParented unusable.

Microsoft advises to create a rich text editor for RTF manipulation. Imagine that you have a thread:

The VCL is not thread-safe and has been documented to not be thread-safe since Delphi 1. If you need to create Windows controls in a secondary thread you have to do it on the naked API level, and the thread probably needs a message loop (API style, not ProcessMessages) as well for the control to work properly.

[dummzeuch 1505]

35 minutes ago, PeterBelow said:

If you need to create Windows controls in a secondary thread you have to do it on the naked API level, and the thread probably needs a message loop (API style, not ProcessMessages) as well for the control to work properly.

Has anybody ever implemented something like this in a Delphi program? Or did we all just sit there and tell everybody that this is not possible because the VCL is not thread safe?

Sometimes it would be really nice to be able to create additional (VCL) controls in a background thread and then somehow pass these on to the main thread to add to a form. I never came around spending any time on this though.

[Dalija Prasnikar 1396]

20 minutes ago, dummzeuch said:

Has anybody ever implemented something like this in a Delphi program? Or did we all just sit there and tell everybody that this is not possible because the VCL is not thread safe?

Sometimes it would be really nice to be able to create additional (VCL) controls in a background thread and then somehow pass these on to the main thread to add to a form. I never came around spending any time on this though.

Implemented what? If you mean full thread-safe UI, then no. For one thing Windows API has thread-affinity, meaning that you cannot create windows in one thread and use it in other. 

 

There is currently another thread that talks about FMX and VCL thread safety as well as Windows API thread safety and what can and cannot be done any why. 

 

[PeterBelow 238]

On 3/18/2023 at 4:36 PM, dummzeuch said:

Has anybody ever implemented something like this in a Delphi program? Or did we all just sit there and tell everybody that this is not possible because the VCL is not thread safe?

Sometimes it would be really nice to be able to create additional (VCL) controls in a background thread and then somehow pass these on to the main thread to add to a form. I never came around spending any time on this though.

In theory you can create a VCL control (not forms or datamodules since they add themselves to the global Screen object's collection) in a background thread but you cannot do anything with it that causes its window handle to be created, since that would bind it to the background thread. Things like TBitmap or TGraphicControl descendents (the latter only as long as they have no Parent assigned) should work, and I have worked with TBitmap in background threads successfully. To show them you have to pass them to the main thread, though.

[Fr0sT.Brutal 900]

On 3/17/2023 at 11:13 PM, aehimself said:

I just would like to add one more thing to the list, VCL styles renders TRichView.CreateParented unusable.

Microsoft advises to create a rich text editor for RTF manipulation.

Well, MS had a good bicycle but when someone needed to cross a river they advised to swim on it. No surprise things gone bad.

[Alex7691 7]

On 3/19/2023 at 1:24 AM, David Schwartz said:

 IntraWeb was introduced well over a decade ago and it's still hardly being used

That's an old post but since I don't come here often, here it goes:

 

David, 

 

you are wrong.

 

IntraWeb is not one decade old. IntraWeb was introduced in 1994, as a product, before Delphi 1.0. In the Delphi world it is as "old" as Delphi itself. And IntraWeb's doing fine, for 30 years, thank you.  I dare you to name another product/framework that started before IntraWeb and is still around. And, no, DevExpress and TMS were both founded *after* Atozed and IntraWeb.

 

The same argument that you use against IntraWeb is the one that a Python developer uses against your application that you wrote in Delphi: "Hey, nobody uses Delphi anymore!". The Python developer will never get it, simply because he doesn't know it.

 

Cheers

 

 

 

Edited January 9 by Alex7691

[David Schwartz 426]

11 minutes ago, Alex7691 said:

 

IntraWeb was introduced in 1994

 

As I said, " IntraWeb was introduced well over a decade ago". Meaning, it's MORE than a decade old. So you're saying it was introduced a year before Delphi ... ok.

 

I still don't know of anybody using IW. So what does that tell you? Nothing. I've also never worked for a company that licensed anything but Delphi Pro for their workers, and they never used anything in the Enterprise Edition either. That's just been my personal experience. Nonetheless, all of these things are still being sold, which means SOME PEOPLE ARE USING THEM SOMEWHERE. I apologize for not finding places to work as a Delphi dev since 2000 that use any of them. 

 

As you say ... cheers.