Leaderboard

With this info in mind, for bad customers you can start programming like that: const _ = 1; _____ = 2; x = _____ + (_-_-_) + 0 + _+0-0+_ ;

That sums it up. Use the xml doc feature for methods and properties, and do it straight away. If it is postponed, it never happens. A colleague asked me on how to use a specific feature yesterday... So... I opened a couple of related units I wrote some time ago, and they had NO xml doc, so yeah, that never happened. The interface sections alone are 1070 and 350 lines, so... I guess I really should work more on my own documentation rather than offer advice To my defense, they are widely used in our projects, so there are plenty of usage examples

BTW: Yesterday I finally found and fixed a problem in GExperts which caused an access violation on IDE shutdown (an OTAPI interface reference that wasn't released after use). But it was caught and logged by an exception handler, so nobody using a release version of GExperts should have seen it. The fix was exactly one line of code, but it took me hours to track it down. The fun with working on IDE plugins: You can reproduce the problem, you see the call stack, you can even single step to the last line of your own code before it happens, but then you only get lots of assembler code of the IDE and other plugins which tells you nothing about what happens.

I'm gaining experience, with the mistakes and failures on the way. Rome wasn't built in a day. It shouldn't, but it gives me a little comfort knowing not everybody is perfect and I'm not the only one having odd 'relationship' with the documentation.

So my first attempt with classes structuring in separate units was very successful. Very good separation of logic and presentation details, classes, inheritance, some poly-thingy probably and other... in multiple units. Nice and good. Happy. Now, 2 weeks later, I started a new feature and I said OK, let me review and see how I did it then, to start similar concept: Open main Form -> that feature is added as a Frame -> open Frame... aha, no code coupled with Controls, so I have no idea what is shown anywhere -> I want to see how I present data in one of the Virtual Treeviews -> I remember I used name something like 'presentation layer', where all data is 'pushed' to controls, so lets look for it -> Frame only uses main data class, in data unit, ok go there -> open main data unit -> search for 'presentation'.. found TPresentationLayer -> open presentation unit -> browse through TPresentationLayer class in presentation layer unit -> find OnGetText for Virtual Treeview, not the right one... browse through the next 2 OnGetText methods... aha: finally found the Array and what is presented in selected Virtual Treeview. I don't get it. At the time of implementing the feature it looked great, everything structured, nice, but I knew where everything was because I was working on the feature. 2 weeks later and it's like it's been 10 years, I'm looking where data is defined, where enums are used and how, where is Array filled, processed and the displayed. Luckily Ctrl+Click works very well so I can jump back and forth through units, if this wasn't working... I can't imagine. What am I doing wrong, did I do 'too much' separation of logic and UI? Do I have bad memory that I can't remember details of 6 small units for a feature, after 2 weeks? How do you deal with this, how do you find out later on what is where and all the details? Any advice appreciated, even though you can't see my code.

No.

Regardless the current typeinfo issue I would always check for typeKind = tkDynArray (and possibly even tkArray) and ElemType = Byte because then you can also handle any custom declared TMyBytes = array of Byte type.

The issue is that TBytes is an alias for TArray<Byte> - generic types being used across different modules have several implications such as that they manifest into each module with their own typeinfo being generated. Try this code for example: uses Rtti, SysUtils; var ctx: TRttiContext; begin Writeln(ctx.GetType(TypeInfo(TBytes)).QualifiedName); end. In a regular console application it will print: System.TArray<System.Byte> While you would assume that it should print: System.SysUtils.TBytes Now if you enable runtime packages for this console application and let it link with rtl you will get an ENonPublicType here. Every module that is using TBytes is not referencing some type that is declared in the RTL runtime package but emiting its own version of TArray<Byte> into its binary. Personally I think this is an issue with the compiler treating the declaration of TBytes = TArray<Byte> different from TBytes = array of Byte in terms of the typeinfo generated - I was sure there is a QP entry somewhere about it but I cannot find it right now. To further provide the proof that aforementioned assumptions of other posters are wrong use the following code with a console application linking with the rtl package: uses Rtti, TypInfo, Classes, SysUtils; var ctx: TRttiContext; begin Writeln(ctx.GetType(TBytesStream).GetField('FBytes').FieldType.Handle = TypeInfo(TBytes)); end. This will print FALSE as the typeinfo of the FBytes field which is of type System.SysUtils.TBytes in fact differs from the typeinfo generated for the usage of TBytes in the console application binary. In fact there does not even exist a type called TBytes but only System.TArray<System.Byte> as TBytes it just an alias as I said and the declaration TBytes = type TArray<Byte> is not legit and raises E2574 Instantiated type can not be used for TYPE'd type declaration

I finally got to the bottom of this issue and I have a simple fix. See https://quality.embarcadero.com/browse/RSP-28200 Please test and vote for it.

The issue is that x64 trig functions are very slow for very large values. Nobody actually wants to know sin for 99999999/pi radians. Put in sensible values for the argument to sin and it looks more reasonable. For instance try using T:=Sin(i/99999999);

May be https://github.com/neslib/FastMath and/or http://docwiki.embarcadero.com/RADStudio/Rio/en/Floating_point_precision_control_(Delphi_for_x64) can help.

OK - I attached now a small first test (FastMM5ConsoleTest.dpr) that compares FastMM5 with FastMM4. Please read first the attached SpeedTestMM5_Sample1.pdf to understand more on the background and motivation. SpeedTestMM5_Sample1.pdf FastMM5ConsoleTest.dpr

copy paste this post as a comment into your frame