Leaderboard

I will start with a bit of history. The Original Code is based on mwCustomEdit.pas by Martin Waldenburg, a great programmer. The key feature of the editor was fast syntax highlighting. This was more than 20 years ago. After a split of the community the SynEdit project was formed maintaining some of the key features of mwEdit. Over the years some of the best Delphi programmers contributed to the project. The list includes for example Gerald Nunn, Eric Grange, Jordan Russell and many many others. Flavio Etrusco added word wrap and Maël Hörz added unicode support (but in a rather idiosyncratic way). However the project management was very weak and the code gradually became very hard to maintain and improve. It aimed to support very old Delphi versions including Kylix and the code became full of IFDEFs and patches without an overall coherence. An early fork of Synedit is part of Lazarus but the two development efforts have diverged a great deal. When Embarcadero introduced the GetIt package manager they asked Roman Kassebaum to produce a version of SynEdit for GetIt. Roman did a general code cleanup removing support for early Delphi versions and Kylix (Turbo fork(s)). I have added support for code folding (the first major new feature for years) to both the Turbo fork and the main Synedit repository. However the Turbo fork(s) were not actively supported or developed beyond recompiling for new Delphi versions and the main Synedit branch was too hard to work with, hence the creation of SynEdit-2 as a fork of Turbo SynEdit. Main new features in SynEdit-2: Replaced SynRegExpr with the built-in RegularExpressions Move/Copy Line(s) Up/Down commands as in VS Code Delete Line command should work with multi-line selection Handle triple and quadruple clicks for selection Triple click and drag should select lines Double click and drag should select whole words Support OLE Drag & Drop What are the key features missing in Synedit: Better Unicode handling: Better support for wide characters e.g. Chinese ideograms (爾雅爾雅爾雅爾雅) Support for surrogate pairs (two widechars correspond to one glyph) Combining characters (e.g. Åström ḱṷṓn) Multi-cursor and multi-selection editing as in VS Code. When these features get implemented I think SynEdit will become comparable to some of the best editors around. But both of them require major rewriting of the code. Work on the second is well advanced and the unicode work is in the planning stage. Of course it is your choice as to which version of SynEdit to use, but if anyone wants to contribute to the development you are very welcome.

If I am not mistaken, Koru is referring to a different case: type IBar = interface ['{570FBD40-8ECF-4B4B-9898-EF3F4146FFF9}'] end; IFooBar = interface(IBar) ['{1A99C9D3-CC94-4BCE-BF9C-354BF14EC5C7}'] end; type TFooBar = class(TInterfacedObject, IFooBar) end; procedure Test; begin var FooBarObject := TFooBar.Create; Assert(Supports(FooBarObject, IFooBar)); Assert(Supports(FooBarObject, IBar)); //Fails! end; For me this is pretty logical, so nothing to be changed.

"Native Interface" is a terrible name tbh - what exactly would be "native" about it that current interfaces are not. A look at other languages might be helpful to actually define clearly what your desired requirements are - for example traits in Scala.

I totally understand, but some eye candy just wont work. And sooner or later some other stuff will follow. This discussion is as old as Windows itself. It used to be "my customers only run DOS" then became "my customers only run 16Bit Windows" over to "my customers only run WinXP" to what we have today. Someone in that story has not learned, and should be beaten with a set of Windows installation floppies: Hardware manufacturers that create one version of their controlling software and never update it, or for an ungodly price. We could break our ears and keep our software running on DOS, or just inform the customers and let them wise up and do a pitchfork and torch run on their machine manufacturer. After all, it is your hide they'll be after if something wont work because their system is outdated - not that this is the case right now.

Hey all. I use SynEdit in a few projects and I was wondering if anyone has insight on which of the various version is the preferred one to use. I'm on 10.4 and don't need backwards compatibility btw. The one that is on "GetIt" appears to be an older version (1.5.) The one listed as SynEdit2 on github by pyscripter appears to be active, includes some nice changes (ole drag and drop for example) lots of fixes and cleanup (some related to removing support for older Delphi versions.) The one listed as SynEdit/SynEdit on github which seems to be more actively developed then the other two. I've worked with the second two and, as always, it seems when working with third party components I have to make a few changes to the source (adding some missing properties, fixing the extra space on word wrap lines (thanks to a stack overflow answer) and a few other minor issues) which have to be merged into each new update, so picking the "correct" one will obviously help. On a side note I have a feeling that the correct answer might be that there is no correct answer... Just looking for any feedback or thoughts. And this post wouldn't be complete without thanking and acknowledging all the great work people have done on these projects! -Mark

Interface-oriented development is an awesome tool, and the ARC memory management that usually comes with it can be great as well. But in our beloved Delphi, interfaces are not full citizens. Working with Delphi interfaces becomes soon troublesome; the way they have been implemented makes impossible some of the common stuff we do in our daily programming As an example, you can't use an interface method as an event handler. You can't use anything that expects a "procedure of object" or "function of object", nor use generics or other modern features. Why? Because the interfaces we have in Delphi were introduced just and only to achieve COM integration. So, the interfaces don't know they always have an object (delphi class) behind them So we need a remake of Delphi interfaces, but we can't break the software already using them Here comes the "native interface": probably they should have a distinction on their declaration, so the compiler knows to handle them And the big difference using them, is that native interface methods are object methods, so the compiler would know how to handle them. I would like this post to serve as brainstorming for those of you who have ideas about how to enable this division of the com-based interface and a possible new native implementation, implementation of which there may also be proposals for improvement. For example, at least for me, it would be nice if interfaces (at least the native ones) could have multiple inheritance of interfaces: InterfaceTest = ninterface(Interface1, Interface2, Interface3) procedure Test; end; Feel free to comment in any direction.

What you describe is exactly what traits are in Scala. Well minus the fact that traits can even declare fields but when they always implemented by objects that would work as well - hence I would not call them anything like "so and so interface" - because while they might be similar they would be a completely different beast and not to be mixed with them. Anyhow it would come down to no proper way to cleanup those things - Scala and all other languages that have similar things use GC so you will not have any headaches about when something has to be destroyed. If you pass around your objects as traits/ninterface/whatever with the memory management we currently have in Delphi this will just an even huger pain than you already have if you mix object and interface references to classes that either implement reference counting or not. P.S. If you are interested how Scala implements traits: https://www.nurkiewicz.com/2013/04/scala-traits-implementation-and.html

Managed records have Initialize() and Finalize() operators that users can override. But that also means they have to be called automatically when the record enters and leaves scope. So, just like other managed types, there is an hidden try..finally to ensure Finalize() is called, yes. That is not the case with unmanaged records. Inline variables begin and end their lifetime in the same scope that they are declared in. So that is where their initialization and cleanup is performed.

It's just a name, any name would do. This starting name aludes to the fact that such interface would be implemented by Delphi native classes, and that means a lot, as this way the compiler does not just know a method address, but the object instance. And that gives us full compatibility with anything currently implemented that works with class methods. On the other side, there is already an embarcadero answer on Quality portal, acknowledging this is feasable, and would work as expected My knowledge on interface-kind features on other languages is zero, so I wonder if there is something really useful that could improve the kind of interfaces we're suggesting, without making it overly difficult to implement and derailing this train

According to that logic IFooBar must not be assignment compatible to IBar - but it is. Even the compiler knows about this because actually if you implement IFooBar and IBar into the same class without any specific method resolution clauses it puts both IMTs into the very same slot (IBar shares it with the IFooBar one)

There is nothing logical about it - as the previously linked article says:

I agree. Interface inheritance is just syntactic sugar. http://edn.embarcadero.com/article/29779 (warning this links contain references to The Version That Must Not Be Mentioned: Delphi 8)

I think I have encountered this problem on rare occasions but I can't remember the circumstances. Did you mean interface inheritance? For example the following works fine: type IFoo = interface ['{F99BAE4A-6612-4714-96B4-237763239C7F}'] end; IBar = interface ['{570FBD40-8ECF-4B4B-9898-EF3F4146FFF9}'] end; type TFoo = class(TInterfacedObject, IFoo) end; TBar = class(TFoo, IBar) end; type TFooObject = class(TComponent, IFoo) end; TBarObject = class(TFooObject, IBar) end; procedure Test; begin // Supports(interface) var FooBar := TBar.Create as IUnknown; Assert(Supports(FooBar, IFoo)); Assert(Supports(FooBar, IBar)); // Supports(instance) var FooBarObject := TBarObject.Create(nil); Assert(Supports(FooBarObject, IFoo)); Assert(Supports(FooBarObject, IBar)); end;

Yes - because try finally (not only the implicit! ones) are implemented poorly and result in trashing the return stack buffer of the CPU all the time: https://quality.embarcadero.com/browse/RSP-27375 @Attila Kovacs The difference between the two IsBreak versions is most likely related to branch prediction and the difference between a conditional forward jump typically taken and not taken - if you want to read more about it I suggest this rather in depth article by Matt Godbolt: https://xania.org/201602/bpu-part-one As for performance of this nested function I would guess it could run even faster when it would not access anything from the outside because that usually requires quite some stack lifting. And having to do that usually prevents the compiler to have more than one exit point as was mentioned before - if there are no registers to pop and that the compiler neatly puts rets in different places though - but I would guess you will not get around that for this function but probably around repeatedly accessing the LineBreak property and variables P2 and LineBreakLen

Greetings from NexusDB, the home of great database components and Quality Assurance tools for Rad Studio/Delphi/C++ Builder. We have a great EOFY (End of Financial Year) offer for you! Take advantage of the following until the end of June: For any purchase made of new licenses, on all products, take 30% off the normal price. Yes, that is 30% off any full price product, even including our Full Monty Pack which bundles all products! To receive the rebate, make sure you enter the following coupon code during checkout: EOFY2020 Visit our webshop here: http://www.nexusdb.com/support/index.php?q=pricing Please also note, all our prices are in Australian dollars. If you are purchasing from outside Australia, take advantage of the extra 25% "rebate" provided by the favourable USD/AUD exchange rate! Our main products: NexusDB Database http://www.nexusdb.com/support/index.php?q=nexusdb Nexus Quality Suite http://www.nexusdb.com/support/index.php?q=qualitysuite regards, The NexusDB Team

Seems that LOCAL_NOUSEROVERRIDE is your friend here.

"@" operator requires a variable/constant/..., Here is your way : type PMyRec = ^TMyRec; TMyRec = record s: string; public function Address(): PMyRec; inline; end; var stk: TStack<TMyRec>; rec: TMyRec; prec: PMyRec; { TMyRec } function TMyRec.Address: PMyRec; begin Result := @Self; end; begin stk := TStack<TMyRec>.Create; rec.s := 'Hello'; stk.push(rec); prec := stk.Peek().Address(); Writeln(prec.s); prec.s := 'Goodbye'; stk.Free; end.

You can write apps for Win 7 if you take care, but the Delphi IDE itself does NOT support Windows 7.

Then you end up with different names for the same thing. How can that be better? Refactoring tools get these names changed very reliably. I don't understand why people are scared of changing names. If you aren't prepared to change names then your code will be a mess.

Now you have the type named incorrectly in thousands of places. It should be called TItemExArray. Seems far worse to me.

Windows 7 is no longer supported, nor should it be. Why support anything even the original manufacturer only supports grudgingly and for a price? As a consequence applications will run, but eye candy will not be as sweet as intended. That seems to be a good compromise to me.

I can't really see any benefit here. I mean you might think that TItemArray is somehow better than TArray<TItem> but they seem pretty interchangeable to me in terms of readability. And the reader has to trust that convention was followed with TItemArray.

You are just polluting the namespace for no benefit. Use TArray<T>.

I wonder why TChart is not a GetIt thing?