Leaderboard

A HIDDEN GEM IN DELPHI SOURCES (SHELLCONTROLS) Many times I intercept requests on the WEB from Delphi developers for components of the Windows "Shell" (similar to Windows Explorer) that were once present in Delphi (maybe in Delphi XE3), which have "disappeared" from the Delphi components palette. Those components are: - TShellComboBox - TShellListView - TShellTreeView - TShellChangeNotifier The good news is that those components are still there and have also been updated over time, but the packages are missing and are therefore not installed "by default" in the Delphi IDE 🙁 So we have prepared a Repo on Git-Hub containing the packages of these components, to facilitate their installation in the Delphi IDE and therefore their use. The prepared packages are for different versions of Delphi, starting from Delphi XE6 up to Delphi 12 and are available here: https://github.com/EtheaDev/DelphiShellControlsPackages In the same repository there is also a small Demo that shows the components "in action", also reconstructed from a demo present only for C++ and transformed in Delphi Pascal. bye Carlo

Normally, after startup, there are already about 1500 threads running in Windows itself

If all threads are fully utilizing the CPU you will more than likely cause slowdowns. The CPU will force one thread to stop, have to push its stack and pop the stack of the new thread, etc etc. As indicated above, for any process where each thread is waiting a lot (not just IO but really anything) you can happily create as many threads as you like (within reason).

No, not al all. Remember a few decades ago, when most personal computers had only one processor? We had multiple threads then, the operating system cycles them for you nicely, even over the several processors if your system has more. If you're running really intensive work in the threads, you may cause slowdowns by having more threads than processors (it's interesting to learn about thread affinity as well), but as soon as you're doing I/O from these threads (and the system handles device calls on your threads) you may get an increase of total performance, because the system can let more threads work while some threads are 'waiting'. There's more to the story when you're using completion ports, or do overlapped IO calls... But only remotely related to your question about threads.

The first example is the correct one. The second one is not, as TThread.Queue will run after lStrings instance is being destroyed. Also it is extremely important that you pass nil to the TThread.Queue like you did because passing the current thread instance TThread.Queue(TThread.CurrentThread, would remove queued procedure when the thread has finished running and if that happens before queued code had the chance to run there would be a memory leak. This is less of a problem with tasks, as their threads are reused, although theoretically, such situation can still happen. But if you replace TTask with anonymous or custom thread then such situation is more likely to happen, especially if there are no more code in a thread after calling Queue that could delay its destruction. However, the second example would also work if you would use TThread.Synchronize instead of Queue ad Synchronize is blocking call and Free will be executed only after code inside Synchronize is executed.

ok well, it's ok now. What I did ; went back to 10.4, did the Revert System Files to Default thing again and compiled. Then retried with 11.3, and it works. There must have something very logical that I didn't get, but I'll see that later.

For answers see: python4delphi/Tutorials/Webinar II at master · pyscripter/python4delphi (github.com) python4delphi/Tutorials/Webinar II/VarPythDemo at master · pyscripter/python4delphi (github.com)

Did you check programmer2k's suggestion? Having other JDKs on the system where the path appears before that of the Adoptium JDK can cause trouble.

Ciao, siamo in un forum internazionale. Dovresti esprimerti in inglese. Hi, we are in an international forum. You should express yourself in English. The list of forms in use in the program is displayed in the "Project/Options" menu Forms that should not be displayed during creation must have the VISIBLE property set to false, view and change the property from the Object Inspector. You must set the property in each individual Form. At runtime if you need to display a Form you must call the SHOW method of the Form itself, example: Form2.Show Obviously it must have already been created either because it is in the "Auto Create Form" list above or because it was created at runtime.

I would (did not think this too much) something like this. Go code trough with D7, make it is modern at it can get. (Few refactoring rounds, get rid of code that is not in active use etc) Update all 3rd party components and libraries. Get rid of those not available for modern delphi versions anymore and not supported Get rid of all visual components that are not absolutely needed. In legacy app there might be visual components form 5 different libraries or something like that. If can get byt, use stock Delphi components as much as you can. Mainly just reduse code base as small as you can, before start using new Delphi. Move to the new delphi and make 32bit app with that. Refactor and further modernice as much as you can. Do 64bit port as last step. -Tee-

However,

Underwhelming featurewise might just mean they focused on fixing bugs. I could live with that. Many of the features introduced in the recent releases didn't really matter for me personally. One can hope ...

There is one fundamental thing missing in your function - copying the field values. The other thing is that you don't need to mess with TVarRec at all. Here's how I would do it: function RecordToArray(DS: TDataSet): TArray<Variant>; var FieldIndex: Integer; begin SetLength(Result, DS.FieldCount); for FieldIndex := 0 to DS.FieldCount - 1 do Result[FieldIndex] := DS.Fields[FieldIndex].Value; end; procedure ArrayToRecord(DS: TDataSet; const Values: TArray<Variant>); var FieldIndex: Integer; begin Assert(DS.FieldCount = Length(Values)); for FieldIndex := 0 to DS.FieldCount - 1 do DS.Fields[FieldIndex].Value := Values[FieldIndex]; end; Another option is to use variant array: function RecordToVarArray(DS: TDataSet): Variant; var FieldIndex: Integer; Data: PVariant; begin Result := VarArrayCreate([0, DS.FieldCount - 1], varVariant); Data := VarArrayLock(Result); try for FieldIndex := 0 to DS.FieldCount - 1 do begin Data^ := DS.Fields[FieldIndex].Value; Inc(Data); // move to next elemnt in resulting array end; finally VarArrayUnlock(Result); end; end; procedure VarArrayToRecord(DS: TDataSet; const Values: Variant); var FieldIndex: Integer; Data: PVariant; begin Assert(VarIsType(Values, varArray or varVariant)); Assert(VarArrayDimCount(Values) = 1); Data := VarArrayLock(Values); try for FieldIndex := 0 to DS.FieldCount - 1 do begin DS.Fields[FieldIndex].Value := Data^; Inc(Data); // move to next elemnt in resulting array end; finally VarArrayUnlock(Values); end; end; // you could then access those value using index: var Values := RecordToVarArray(DS); Writeln(VarToStr(Values[0])); Writeln(VarToStr(Values[1])); ...