Jump to content

Leaderboard


Popular Content

Showing content with the highest reputation on 06/18/20 in all areas

  1. Sherlock

    ParnassusCoreEditor.dll AccessViolation

    It's called consistency and is considered to be a good thing...most of the time.
  2. As a benefit I see better readability and flexibility. In case we decide to change TArray<T> to something like a TList<T> later, we only have to change that in one place. (Of course the code itself might have to change, too. But that has to be done anyway.) I often start with an alias like TItems = TList<T> and later extend that to TItems = class(TList<T>) with some additional or overridden functionality. Sometimes it is just to hide the necessary constructor parameters inside a simple TItems.Create. If the implementation is indeed relevant for understanding the code, I use type names like TItemArray and TItemList, even if those are also just aliases to TArray<TItem> and TList<TItem>. For me, these benefits are of much more value than keeping the namespace small. The latter may result in shorter compile times, which are already pretty short. Runtime performance and code maintainability gain near to nothing from it.
  3. Be sure to have a backup, after installing this patch Reportbuilder and DevExpress Components connected with Teechart are not working any more: So, whats next if we don't have a backup ??
  4. Mahdi Safsafi

    Class Constructor in Delphi 10.4

    If it was true ... then we're definitely using Elphi 😉
  5. @David Heffernan Which refactoring tool do you use that reliably will change some scenario where you have lots of places across lots of units where you had something like procedure SomeProc var myList:TList<TFoo> begin myList:=TList<TFoo>.Create then you want to change all places from TList<TFoo> to TObjectList<TFoo>. So the refactor would presumably change the variable declarations and the .Create calls across all the units. It really does not work reliably for us and we have lots of search..replace with invetiable 10 minutes of compiling churn to get it all right. We tend to do TFooList=TList<TFoo> and just use TFooList everywhere for this reason. If the refactoring tools worked well, it would make that less necessary.
  6. 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.
  7. I've just run the patch, here a list of whats going on: Before install I had TChart and all Features I installed via welcome page this seems to be just a shortcut to the GeitManager Got the first message Yes, I want ... Then I've got a fullscreen terminal, which is odd. because I cannot see a hanging message-box request, it was behind the terminal. After pressing OK, it moved on Seems to de-install all features I've had installed before even Interbase and all SDK's ... Then its restarting the IDE Of course something is missing now, need attention later ... Then the features components 2nd page were all removed (as they were uninstalled), I had to enable them. Even the samples. Installing the components ... tea time ... Re-Installing also loads the TeeChart, I hope this is the new version then. I will see later in my tests. Finally after install Teechart is back I can compile Android, so also the SDK seems to be back, but I'm unsure if all Android-Components wer initialized. The welcome page still shows a patch, it seems to be an error in "patch installed" detection I re-enabled my TChart usage in a project, and compile the project for test. I found a few issues then: 1. The message box was hiding behind the full-screen terminal 2. All features were disabled and de-installed, even the samples. This is maybe for safety, but I think this could be optimized. 3. When IDE ist startin, to re-install, it noted about missing BPL Surely this could be optimized too, to set the IDE into a kind "installer mode" before, ignoring missing BPL. Then only show message after 2nd start, if still anything is missing. 4. Patch "installed" detection doesn't work reliably
  8. Just for information, this is the readme file of that patch. I cannot see anything related to Teechart or the ability to load packages, but that may as well be hidden somehow. Also does the patch not include any binary that could be executed or loaded and do any harm. Note, that the patch do save the original files in %BDSCatalogRepository%\Backup. Patch1.txt Update: I just noticed that the mentioned patch is different to the one I was talking about. Will investigate further...
  9. I can see also benefit in maintaining code. Imaging you change TItemArray = TArray<TItem>; to TItemArray = TArray<TItemEx>; In the TItemArray version you touch the code in one place only. In the TArray<TItemEx> version you touch the code in thousands of places maybe.
  10. Dave Nottage

    Fill and sign for PDF file not working using Acrobat Reader DC

    All good, thanks. Someone has answered who spotted a discrepancy that I missed, namely in the font widths array. What's worse: I missed that the "one that works" had altered the font info to correct the problem.
  11. Lars Fosdal

    ParnassusCoreEditor.dll AccessViolation

    10.4 does not overwrite the 10.3 versions in C:\Users\<username>\Documents\Embarcadero\Studio\20.0\CatalogRepository\ So, First install for 10.3, then install for 10.4 - and apply the fix above.
  12. Lars Fosdal

    ParnassusCoreEditor.dll AccessViolation

    10.4 has an update to Bookmarks and Navigator. It creates C:\Program Files (x86)\Common Files\ParnassusShared and places ParnassusBookmarks_XSydney.dll ParnassusCoreEditor_XSydney.dll ParnassusNavigator_XSydney.dll So, to cure the 10.3 ailments, copy from C:\Users\<username>\Documents\Embarcadero\Studio\20.0\CatalogRepository\ to the first mentioned common catalog Bookmarks-1.0\ParnassusBookmarks.dll to ParnassusBookmarks_XRio.dll ParnassusCoreEditor-1.0\ParnassusCoreEditor.dll to ParnassusCoreEditor_XRio.dll Navigator-1.0\ParnassusNavigator.dll to ParnassusNavigator_XRio.dll
  13. Not for TArray<T> but possibly for types with actual executable code - see my reply to Mahdi. The question was about TArray<T> where it does not matter at all rather than a few unnoticable microseconds at compile time. You are right however when talking about types that have executable code (and possibly a significant amount of typeinfo) as the compiler always emits all code of a generic type into each and every dcu that is using it as in your example with Unit1 and Unit2. However it does not need to emit into Unit3.dcu because that one is just referencing the type that already fully resides in Unit2.
  14. Yes, there is a disadvantage of using TArray<TItem> instead of TItems. In the same unit where class is declared, whenever compiler found explicit generic type(TArray<TItem>), compiler must do extra work : matching arguments, checking for constraints, ... In a large unit that uses generics massively, this may add a little overhead. TItems on the other side, works as a cache (compiler does not need to check constraints for example). Using TArray<TItem> from another unit adds a noticeable overhead as the compiler must generate the type in-situ for that unit. In fact do the following test yourself: unit Unit1; interface uses System.SysUtils, System.Generics.Collections, System.Classes; type TObject<T> = class a: T; b: T; procedure foo(a, b: T); end; TListOfInteger = TList<TObject<Integer>>; implementation { TObject<T> } procedure TObject<T>.foo(a, b: T); begin end; end. // --------------------------------------- unit Unit2; interface uses System.SysUtils, System.Generics.Collections, System.Classes, Unit1; type TListOfInteger2 = TList<TObject<Integer>>; implementation end. //----------------------------------------- unit Unit3; interface uses System.SysUtils, System.Generics.Collections, System.Classes, Unit1; type TListOfInteger3 = TListOfInteger; // alias implementation end. Now, check the size of Unit1.dcu, Unit2.dcu, Unit3.dcu. Final thing, TItems is more friendly for typing and reading !
  15. I think you meant to write: TItems = TArray<TItem>; Apart from not having to type the angle brackets anymore this is exactly the same type as TItems is just an alias for TArray<TItem>
  16. Lars Fosdal

    Controlling Canon EOS cameras

    Have you tried TCamRemote from https://alkenius.no-ip.org/
  17. Kazantsev Alexey

    Your RAD Studio 10.4 Sydney issues

    The error is not in the implementation of the custom initializer. A custom initializer is available for the “TRec” type, but an initialization error is in the “TData” type, which does not have a custom initializer, but has a field of a managed type. In the code example, you can replace the custom initializer with any other custom management operator (finalizer, assign), and you will get the same error.
  18. Kazantsev Alexey

    Your RAD Studio 10.4 Sydney issues

    Codegen bug https://quality.embarcadero.com/browse/RSP-29299
×