Uwe Raabe

Try setting FetchOptions.LiveWindowParanoic to True.

5 hours ago, luciano_f said:

If all users here on the forum voted

The voting system is to give priority to some issues over others. Priority may be different for all users here. It is counter productive to vote for an issue that has less priority to oneself, as that reduces the chance for issues you prioritize to be implemented.

Why not https://quality.embarcadero.com/browse/RSP-33115 ?

That one already has 17 votes (which is not very much either and lies in the ranks at about 180)

Can you list the following settings for the TFDTable instance:

• CachedUpdates
• FetchOptions.Unidirectional
• FetchOptions.CursorKind
• FetchOptions.LiveWindowParanoic

Also, is KeyIdx a primary or unique key?

55 minutes ago, Anders Melander said:

that's exactly the syntax I want to avoid

I have difficulties to understand your intention here. Why would you want to enter a multiline string literal to declare a single line string literal? The whole purpose of the new multiline string literal is to get line breaks into a string literal. There is no need to have line breaks when they are later ignored anyway.

On 9/19/2023 at 5:14 PM, Anders Melander said:

By Ignore newline I meant from this:

  Lorem

  ipsum

  dolor

produce this:

  lorem ipsum dolor

There already exists a syntax to achieve this:

const
  blub = 'Lorem' +
         ' ipsum' +
         ' dolor';

1 hour ago, dummzeuch said:

the pain in the lower back any new language features poses for third party tools that parse the source code

That is exactly my own experience with MMX. When I took over the project it already was way behind the current language and it needs quite some time to catch up.

4 hours ago, Darian Miller said:

to develop the IDE support with the new language feature at the same time so they are released

While that may be possible for the IDE itself, as the owner has at least some control over the release date, this fails completely for 3rd party tools even if their maintainers participate in the beta (at least everyone willing can opt for that). A lot of enhancements are not ready early in the beta and often changed in between due to the ongoing discussion. Usually there is only a small time left before release where a feature is stable enough to support it in ones tool. Unfortunately the effort to design and implement that while staying compatible with older Delphi versions needs way more time as is left.

@dummzeuch I haven't had a look at it for quite some time, but is the formatter free/open source or are there any restrictions to it?

18 minutes ago, Stefan Glienke said:

The closing quotes dictate the alignment

BTW, I like the fact that it is the closing quotes instead of the starting one. Imagine you need to adjust the indentation of the whole literal just because you decide to change the name from blub to something with not the same length.

4 minutes ago, Lajos Juhász said:

In my opinion it would be better to use:

 

blub:= "line1
   line2, indented
line3
;

What if you want a line with a single semi-colon inside the string literal?

With the current implementation your example would be written this way:

blub := '''
   line1
      line2, indented 3 spaces
   line3
   '''; // the ending triple quotes are aligned with the no-indentation position

Some background for this discussion: Raw string literal

18 minutes ago, dummzeuch said:

Unfortunately the parser is quite complicated as it is now

If the parser is too complicated by itself, it probably doesn't matter which syntax change is actually chosen.

The docs that comes with the beta installer.

You don't expect beta testers to discover how to use new features by blind guesses, do you?

Of course, one has to participate in the beta to get access to both, but everyone with an active subscription can ask for it.

1 minute ago, Anders Melander said:

how does one differentiate between preserve or trim leading white space and preserve or ignore newline?

The docs contain more information than the blog post shows.

Exactly! Nobody is forced to use this new feature.

Also, I don't see anything breaking except tools parsing new code using that feature. Obviously that is always the case with new language features. The only way to avoid that is not allowing new language features in the first place.

I actually prefer the new syntax over the suggested one, as that is already occupied by a call to function multiline taking a string parameter - and fails because of the line-breaked string literal.

Instead of teaching the compiler that a function call to multiline (what happens if I already have a similar named function in the scope?) to accept line breaks in the only sting literal parameter, the new syntax keeps the available parsers intact. They will just fail on the new multiline syntax as any Delphi compiler version before does.

The new syntax is pretty simple to detect:

Quote

• It is introduced by a triple quote (’’’) and a new line (so no text following the triple quotes on the same line)
• It can encompass multiple lines of the source code file (with no limitation)
• It ends with a closing triple quote (’’’) in a line without any text preceding it

This makes tweaking the parser not too complicated, as the start and end tokens are easy to recognize.

While the triple quote alone resembles still valid syntax in previous versions, the mandatory new line would fail to parse. That is the condition where the new parser should intercept until the end condition is met.

It still seems unclear how one has to escape a triple quote with no text preceding it inside a multiline string.

Come on - it's a meme - it has to be silly.

2 hours ago, Vincent Parrett said:

I usually have something like this so I can have one inc file that supports versions before and after XE4

The IFEND works in all versions. LEGACYIFEND ON only makes XE4+ accept only IFEND, too. That might be helpful to write code compatible with versions before XE4 when written and tested with newer versions only. So it is more like a safeguard for the developer, but code written like before XE4 will also compile in XE4+ without that LEGACYIFEND directive.

I'm not aware of something like that. There is a change regarding IFEND since XE4:

Quote

Before the XE4 release, $IF statements could only be terminated with $IFEND, and the $IFDEF, $IFNDEF, $IFOPT directives could only be terminated with $ENDIF.

At XE4, this changed so that $ENDIF became an accepted terminator for $IF, $IFDEF, $IFNDEF, and $IFOPT.

1 hour ago, dummzeuch said:

It was introduced with Delphi 6.

You can even check for it:

{$IFDEF CONDITIONALEXPRESSIONS}
{$IF CompilerVersion < 23.0}
  ...
{$IFEND}
{$ENDIF}

1 hour ago, Stefan Glienke said:

I rather copy the latest version when a new one comes out/is in beta.

Me too. Although f.i. PngComponents are prepared to compile with newer versions without changing more than the LIBSUFFIX (which in my case is handled by Project Magician), I always copy the package folder to a decent named one.

The VirtualTreeView approach works fine when you just compile and install from the lowest Delphi version to the highest or you revert any changes before opening the package in another one.

10 minutes ago, Fr0sT.Brutal said:

This package madness really bothers. Especially knowing most versions doesn't differ at all.

I like the VirtualTreeeView approach, which has a package folder named RAD Studio 10.4+. It works perfectly for 11 and probably for 12, too.

43 minutes ago, Fred Ahrens said:

Sorting units by name is dangerous.

Albeit there actually is a request for that, MMX does not sort the units by name. They are grouped according to a user defined pattern, but inside the group the order stays intact.

F.i. this is the Groups entry for one of my projects: 

After some Delphi units in a decent order based on dependency, there are the Raize and TMS units followed by VirtualTrees, PngComponents and the ZipForge units. The last four mimic the unit scopes and naming convention of the project itself also ordered by dependency.

(TMS can improve their unit naming btw.)

A typical uses clause looks like this:

uses
  Winapi.Messages,
  System.Classes, System.Actions, System.Types, System.ImageList,
  Vcl.Graphics, Vcl.Menus, Vcl.ActnList, Vcl.Controls, Vcl.ExtCtrls, Vcl.Forms, Vcl.StdCtrls, Vcl.Tabs, Vcl.Dialogs, Vcl.ImgList,
  Vcl.VirtualImageList, Vcl.AppEvnts,
  RzTabs, RzForms, RzShellDialogs, RzPanel, RzButton, RzSplit, RzCommon,
  Common.Form,
  IpButton, IpMRU, IpMultiLanguageSupport,
  TcEditorTypes, TcGlbCfgSystem, TcGlbCfgVisualStyle,
  RNcCodeViewer, REditorStructure, REditorItems, RBasePalette, RStoragePalette, REditorPalette, RCustomPalette, REditorPanel,
  RBaseFrame, RObserver, RStandardStatus, REditorNesting, RBaseEditorFrame;

The grouping algorithm is pretty flexible and I never had a case that could not be handled.

If auto-sort a uses clause is automatically sorted whenever MMX modifies it - a very handy feature.

It started with the request to expand the unit scope names, which gave a good boost to compile time in some cases. The idea of uses clause grouping and sorting crept in my mind when I noticed difficulties to quickly scan the list of used units. With a sorted and grouped uses clause the used libraries are clearly visible immediately. So its partly for compilation speed as well as a neat look (some call it OCD).

2 hours ago, Kryvich said:

There is no reason to stay on the old version of Delphi. Only if you have specific requirements that do not allow you to switch to a new one.

Even that would not magically extend the license. The only option to continue working with 10.4 is buying a full version where the license also covers older versions.

Thanks for reporting. I know that MMX has problems with those one-line declarations and conditional defines. I have added these two to the bug tracker.