Dave Novo

Can you just include the pascal code of what you are trying to size. Never mind implement it... The term "setlength for 3 TArray<Double>" is unclear. Are you trying to size arr_3D: Array of array of array of double? if so, SetLength(arr_3d, a,b,c) should work (where a,b.c are the dimensions you want) Note, SetLength will set the newly allocated memory to zero. or 3 different 1D array of double

What we have done is have a centralized imageList in a datamodule for the application. We then have separate actionList/imageList pairs on every form. In the form Create, we copy the image(s) we need for that form from the central image list to the image list on the form being shown. Its a bit of a pain, we have a list of constants on the central datamodule so we can request images in an easy to read manner. So, on any given form's Create, we do something like actExportToExcel.ImageIndex:=CentralImageDataModule.AddImage(self.ImageList,IMG_EXPORT_TO_EXCEL) Its a bit of a pain and we have some utility functions like CentralDAtaModule.AddImageIndices([act1,act2,ac3],[CONST1,CONST2,CONST3]) to make it a bit simpler. But that way we can update the images in the central data module and have them update everywhere.

You can also do this from the python side and send a script to delete all global variables # List of built-in attributes to preserve preserve = set(dir(__builtins__)) # Iterate over global variables and delete those not in the preserve list for name in list(globals()): if name not in preserve and not name.startswith("__"): del globals()[name]

Hi Paul, As you can see, multiple excellent developers (I exclude myself from the list) have chimed in, with many different opinions, all of them valid. One point that you might not be aware of, is that when you free an object, the variable is still pointing to a location of memory on the heap. Until that memory is overwritten (as far as you should be concerned memory is randomly allocated and you cannot control/predict that) the object may behave fine. i.e. you can call methods on that freed object, and it will appear to work. Or, depending on what memory is overwritten, some of the methods on the object will appear to work, others will crash with an access violation or other error right away. The problem is that the crashes are quasi-random. Sometimes accessing the freed variable may crash right away, other times not. In my experience, it crashes more reliably with a 64 bit compile than 32 bit compile. This can be terribly hard to track/reproduce/fix if it only happens at a customers' site but does not crash on your computer, since for whatever reason, the memory is not reallocated on your computer in the same manner. I would HIGHLY advocate learning how to use FastMM in debug mode and use that ALL THE TIME when developing code. You can turn it off when compiling for release. I

As usual, there is no correct answer. Just opinions/options. Option 1: Just use FreeAndNil all the time. This way, you don't have to think about it, you can code it up in the Delphi IDE auto-complete stuff (and other tools like MMX). It is doing a bit of extra work, and calling an extra method, but you would need to doctor up some very contrived examples to have the speed penalty from FreeAndNil make any kind of impact on your code performance. Option 2: Use FreeAndNil if you free objects in the middle of a method when there is code executing afterwards and you are scared you may accidentally use the freed variable. Also use FreeAndNil in explicit cases where a valid state of an object variable is NIL. If you free objects as the last few lines of a method (or in a destructor) dont use FreeAndNil and rejoice at the nanoseconds of processing speed you have saved compared to option 1 Option 3: never use FreeAndNil. If you use FastMM there is an option on it to catch the use of freed memory. That option does slow down things quite a bit, but it works. That way, even if you reuse a freed object variable, FASTMM will throw an exception. Or, if you dont use FastMM then simply don't make coding errors 🙂 Seriously though, it can take ages to find errors stemming from using freed memory if you dont have FastMM debug mode on, and all the nanoseconds in the world saved from not using FreeAndNil is not worth the hours it will take you to find the bug.

Hi John. Package management on python is something that you need to learn and understand before using Python. If you just install packages willy nilly you will essentially have a non-functional python environment after a while. There are many tools available to help you not shoot yourself in the foot. Out of the box python supports virtual environments. There are package management tools like Conda, Poetry and others. It takes a bit to wrap your mind around it, but just like in Delphi if you install packages where different packages require different versions of other packages you will get yourself into big trouble. Its just that in python you use many more packages (aka 3rd party libraries in Delphi) and the odds that some conflict are much higher simply since there are more of them.

Evidently, there are issues with cycles. I do admit that our huge 3M LOC application has tons of cycles (where we have stuff in the implementation uses clause that would cause circular references if it was put in the interface). We are working on removing these because evidently they slow down the compiler as well. Over the last 20 years we were not aware there was any downside in having cycles and took no effort to refactor things to prevent them. Now we are far more careful. Evidently, LSP (even Delphi 12.3) does not like these and simply dies on our application. However, that does not explain that even in my relatively simple apps it is still unreliable.

Unfortunately, we are not. The company has too many hoops to jump through to get anything out as open source. Plus we used a lot of our base classes and libraries to speed up the coding, so would have to disentangle that.

I agree with you. The LSP simply is unusable on our project and we were forced to write our own IDE plugin and utilize DelphiAST to write our own code insight and code completion. Even in much simply projects I am writing (<10 units, a few hundred lines of code) the code completion, ctrl+click to jump to an identifier, does not work well.

Welcome to the Delphi world. There are lots of tools available for many of the questions your asked. Have a look at the subforum on this site and search for various tools and you will see many examples. Most of the tools have been around for a long time, and are very feature complete and differ by subtleties of usage etc. Delphi Third-Party - Delphi-PRAXiS [en] -for the diagrams, I know both TMS Software and Developer Express have flowcharting tools you can leverage. There are other lesser known ones that are available. Just google "delphi flowchart component" -Similar with Help tools. We used Help and Manual and liked it, but there are many other tools equally as valid. These do not even have to be delphi specific. -Please describe what "font oddities" you are seeing in more details. -Without knowing in more detail what you want, recommending a database is just throwing darts against the wall. All have their pros and cons.

ok, perfect, I got that working. thanks!

Is there an example anywhere of properly hooking up events to a newly created Observable list in order to be notified if items are added/removed to from the list

thanks. I did not realize I had an older version. Just updated....

By the way, I tried the code, based on @Stefan Glienke example above var foo:=TCollections.CreateList<string>; var indexedColl := TEnumerable.Select<string, Tuple<Integer,string>>(foo, function(const item: string ;const index: Integer): Tuple<Integer,string> begin Result := Tuple<integer,string>.Create(index, item); end); and it does not compile. I think the problem is that TEnumerable.Select expects a TFunc<T,TResult> The following seems to be okay var foo:=TCollections.CreateList<string>; var idx:=0; var indexedColl := TEnumerable.Select<string, Tuple<Integer,string>>(foo, function(item: string): Tuple<Integer,string> begin Result := Tuple<integer,string>.Create(idx, item); inc(idx); end);

I guess I could wrap the above code into something like TEnumerateHelper<T>=class function CreateIndexEnumerator(list:IList<T>):<result is whatever the type of the .Select statement is> also, define a type TIndexedEnumItem<T>=Tuple<Integer,T> and consolidate that all to make somewhat simpler code to use on a day to day basis. I think different logic is needed though if the .Where predicate has an integer enumerator passed in.