Leaderboard

That was a waste of time and energy.. You should read more RTL code and the answers to your questions!!

I did a clean install of Delphi 10.4.2. One of the first steps is to compile and install GExperts. SVN revision 3449 compiled fine, but when running the "Register-GExperts-XX104.cmd" it fails with "Runtime error 217 at 50CDB390", followed by "Problem beim Starten von .\GExpertsRS104.dll. Eine DLL-Initialisierungsroutine ist fehlgeschlagen." To trace the error I compiled GExperts in Debug mode, using Debug-DCUs. Then I used Run->Parameters to set "C:\Windows\System32\rundll32.exe" as "Host", and the full path to the compiled GExpertsRS104.dll and ",InstallGExperts" as parameter: Host application: C:\Windows\System32\rundll32.exe Parameters: C:\Full\Path\To\GExpertsRS104.dll,InstallGExperts Now I could debug the installation from within the Delphi IDE. The startup-code InitUnits (in System.pas) initializes all units and calls class constructors; and in Vcl.WinXCtrls.pas it calls a class constructor TSearchBox.Create. This code creates an internal TImageCollection and adds two default images, which finally leads to TWICImage.Create in Vcl.Graphics.pas (Line 10624 ff). The call to CoCreateInstance(CLSID_WICImagingFactory, ...) fails with error code $800401F0 = CO_E_NOTINITIALIZED = 'CoInitialize has not been called' and an exception is raised with message 'Cannot create instance of class CLSID_WICImagingFactory'. To solve this problem, I need to insert CoInitialize(nil) somewhere, and because I won't change VCL and RTL units I had to find another place. Finally I found that the initialization block in GX_GenericUtils.pas is called some steps before the exception is raised, and already uses unit ActiveX, so I placed a CoInitialize(nil) in GX_GenericUtils.pas initialization block. initialization CoInitialize(nil); // this line added Initialize; ... And the error is gone! Finally I could install GExperts into Delphi 10.4.2 😉 [Yes, I know how to use RegEdit]. @dummzeuch : Maybe there is a better place to insert that missing CoInitialize(nil). Also I don't know if that call has side effects on older Delphi versions and should be surrounded by some IFDEFs. Since it is only one line inserted, I did not create a patch. I'm going to report this new VCL bug to quality portal. Thanks for reading, Achim

@Mike Torrettinni 10.4.2 is a lot better than 10.4.1 in many respects. These are corner cases, and I expect there will be hotfixes. My guess is that 10.5.0 also will have issues that needs to be hotfixed - simply because exposing the IDE and compiler to real world code will uncover things that were not caught in the testing.

This post covers manifest files with delphi. https://www.finalbuilder.com/resources/blogs/windows-manifest-files

24h and almost 400 billion tries, still no 'Delphi'. Experiment done ☹️

Fixed in version control. See https://github.com/pyscripter/python4delphi/issues/292 Now SystemExit results in a EPySystemExit exception which can be handled in Delphi code. Process termination is prevented.

Brushes like other GDI objects need to be protected when shared between threads https://docs.microsoft.com/en-us/windows/win32/procthread/multiple-threads-and-gdi-objects I never worked with brushes in the background, so don't know exactly how you should protect it. Answer is somewhere in Vcl.Graphics unit.

With 10.5 whole cycle will repeats . So, 10.5.1 will be bugfull like hell, 10.5.2 - will look promising, 10.5.3 - slightly better.

52^6 is bigger than 32bit so of course a 32bit RNG might not yield it. In fact its over 4 times more than 32bit so only like every 4th possible 6 letter combination would ever be yielded. Bonus hint: try a lowercase d 😉

According to the probability theory, there is a 1/19 770 609 664 chance that on the next try you will get the desired 6-letter word. So the fact that after 400 billion attempts it has not been received looks suspicious, but not impossible. (19 770 609 664 = 52*52*52*52*52*52). By the way, here are the probabilities of finding a word with fewer characters: 1-letter word: 1/52, 2-letter word: 1/2 704, 3-letter word: 1/140 608, 4-letter word: 1/7 311 616, 5-letter word: 1/380 204 032, 6-letter word: 1/19 770 609 664.

@FredS Creating a new VCL project, adding your unit, and without saving the files - hovering over FormKeyDown in the implementation section - the IDE locks up. The LSP does not show any particular activity: The IDE seems to be running in a very tight loop in a single thread doing XML processing? Callstack: 0, msxml6.dll!DllGetActivationFactory+0x36a1a 1, 0x6d6a9a500589a9b8 2, 0xffffffff00000000 3, 0x6d6a9a8a00641f44 4, 0x6d6a9a500588c0c8 5, 0x300000000 6, msxml6.dll!DllGetActivationFactory+0x36a1a (No unwind info) 7, msxml6.dll+0x79a8a (No unwind info) 8, msxml6.dll+0x791cb (No unwind info) 9, msxml6.dll+0x6002b (No unwind info) 10, msxml6.dll+0x3f4c0 (No unwind info) 11, rtl270.bpl!SystemIntfClear$qqrr44System%DelphiInterface$17SystemIInterface%+0x13 (No unwind info) 12, rtl270.bpl!SystemFinalizeRecord$qqrpvt1+0x111 (No unwind info) 13, rtl270.bpl!SystemTObjectCleanupInstance$qqrv+0x21 (No unwind info) 14, rtl270.bpl!SystemIntfClear$qqrr44System%DelphiInterface$17SystemIInterface%+0x13 (No unwind info) 15, rtl270.bpl!SystemFinalizeRecord$qqrpvt1+0x111 (No unwind info) 16, rtl270.bpl!SystemTObjectCleanupInstance$qqrv+0x21 (No unwind info) 17, rtl270.bpl!SystemIntfClear$qqrr44System%DelphiInterface$17SystemIInterface%+0x13 (No unwind info) 18, rtl270.bpl!SystemFinalizeRecord$qqrpvt1+0x111 (No unwind info) 19, rtl270.bpl!SystemTObjectCleanupInstance$qqrv+0x21 (No unwind info) 20, xmlrtl270.bpl!XmlXmldocTXMLNode_Release$qqsv+0xe (No unwind info) 21, rtl270.bpl!SystemIntfClear$qqrr44System%DelphiInterface$17SystemIInterface%+0x13 (No unwind info) 22, rtl270.bpl!SystemClassesTInterfaceList$bdtr$qqrv+0x13 (No unwind info) 23, rtl270.bpl!SystemIntfClear$qqrr44System%DelphiInterface$17SystemIInterface%+0x13 (No unwind info) 24, rtl270.bpl!SystemFinalizeRecord$qqrpvt1+0x111 (No unwind info) 25, rtl270.bpl!SystemTObjectCleanupInstance$qqrv+0x21 (No unwind info) 26, rtl270.bpl!SystemIntfClear$qqrr44System%DelphiInterface$17SystemIInterface%+0x13 (No unwind info) 27, rtl270.bpl!SystemFinalizeRecord$qqrpvt1+0x111 (No unwind info) 28, rtl270.bpl!SystemTObjectCleanupInstance$qqrv+0x21 (No unwind info) 29, xmlrtl270.bpl!XmlXmldocTXMLNode_Release$qqsv+0xe (No unwind info) 30, rtl270.bpl!SystemIntfClear$qqrr44System%DelphiInterface$17SystemIInterface%+0x13 (No unwind info) 31, rtl270.bpl!SystemClassesTInterfaceList$bdtr$qqrv+0x13 (No unwind info) 32, rtl270.bpl!SystemIntfClear$qqrr44System%DelphiInterface$17SystemIInterface%+0x13 (No unwind info) 33, rtl270.bpl!SystemFinalizeRecord$qqrpvt1+0x111 (No unwind info) 34, rtl270.bpl!SystemTObjectCleanupInstance$qqrv+0x21 (No unwind info) 35, rtl270.bpl!SystemIntfClear$qqrr44System%DelphiInterface$17SystemIInterface%+0x13 (No unwind info) 36, rtl270.bpl!SystemFinalizeRecord$qqrpvt1+0x111 (No unwind info) 37, rtl270.bpl!SystemTObjectCleanupInstance$qqrv+0x21 (No unwind info) 38, xmlrtl270.bpl!XmlXmldocTXMLNode_Release$qqsv+0xe (No unwind info) 39, rtl270.bpl!SystemIntfClear$qqrr44System%DelphiInterface$17SystemIInterface%+0x13 (No unwind info) 40, xmlrtl270.bpl!XmlXmldocTXMLDocument$bdtr$qqrv+0x6f (No unwind info) 41, xmlrtl270.bpl!XmlXmldocTXMLDocument_Release$qqsv+0x33 (No unwind info) 42, rtl270.bpl!SystemIntfClear$qqrr44System%DelphiInterface$17SystemIInterface%+0x13 (No unwind info) 43, IDELSP270.bpl!BaselspserverTLSPServerLSPServerCharEncoding$qqrp14SystemTObjectx20SystemUnicodeStringp22SystemClassesTStream+0xbd8 (No unwind info) 44, vcl270.bpl!VclFormsTApplicationIdle$qqrrx6tagMSG+0x13b (No unwind info) 45, vcl270.bpl!VclFormsTApplicationHandleMessage$qqrv+0x1c (No unwind info) 46, bds.exe!_dbk_fcall_wrapper+0x1234ad (No unwind info) 47, kernel32.dll!BaseThreadInitThunk+0x19 (No unwind info) 48, ntdll.dll!RtlGetAppContainerNamedObjectPath+0xe4 (No unwind info) 49, ntdll.dll!RtlGetAppContainerNamedObjectPath+0xb4 (No unwind info)

Because IComparer<T> created via TComparer.Construct (TDelegatedComparer<T>) suffer from this issue: https://www.idefixpack.de/blog/2016/05/whats-wrong-with-virtual-methods-called-through-an-interface/ Furthermore every call to GetName_TArrayBinarySearch constructs the comparer again. Eliminating that as well gives me a result of 159 vs 105 which then can be explained by the additional calls through IComparer<T> and the probably a little less optimal allocated registers in the actual method that performs the search because that is the one with many more arguments in class function TArray.BinarySearch<T>(const Values: array of T; const Item: T; out FoundIndex: Integer; const Comparer: IComparer<T>; Index, Count: Integer): Boolean; FWIW your implementation is not exactly the same as the RTL one as you exit as soon as you find a match while the RTL implementation because it returns the index goes on because it returns the first index in case there are successive elements matching.

That's for sure. We could even use more things and types from Spring4D. The main problem, actually - besides some time to integrate - is the deploy of it. Installation is already complex, it's rather complex to add Spring4D as a dependency, worse, as an optional dependency. That's why I'm really looking forward to @Vincent Parrett's DPM, when it's ready, we could deploy several different packages, and it will just download and install whatever dependencies it needs.

@Mike Torrettinni now that we all know your password I suggest you change it!

I assume everyone running VirtualBox with 10.4.2 will get this error with no workaround?

Maybe the reason is that you are using (probably 32bit) pseudo-random numbers, not true random numbers. These 32 bits create 4.29e9 seeds for random number generator, while 6 letters from your 52 letters is 19.77e9 combinations. In fact you could try to set the seed to all numbers from 0 to 255^4-1 and see, whether it creates desired result. If you have 64bit random number generator, it could reach the goal, I guess.

Probably we must talk your your QA because of the empty remarks-section in the XML-doc that is causing the trouble. Just kidding - sorry for that. Looks like no one tested with empty xml-nodes. However - this is such a simple and easy to reproduce test-case that I am quite confident too see a fix quite soon.

This is called the generic navigation. 😛

Goto https://my.embarcadero.com/ and logon and then click on the Download icon in the left panel to get a list of files that you can download.

Thanks. It's taking shape quite nicely now.. still plenty to do, but I hope to have a fully working release this year. Once I get the design time stuff working I'll ping you to give it a try with your libraries.

I am also glad we could find a solution - fyi the actual fix was done a bit different as suggested in the comments of that issue. Also thanks to @jbg who gave some input on the subject and @Bruneau who we worked with to get this solved.

I would suggest that if you want everything synchronous then don't use messaging, there's no point and you are just adding overhead for very little gain. We use asynchronous messaging extensively in FinalBuilder, yes it takes a bit of thought but then that's what programming is about. We use our own messaging library which is thread safe. Under the hood we also use omnithread library for some of the more complex threading.

In VCL, the TBitmap.Canvas must be locked while using the TBitmap in a worker thread. The RTL keeps track of all GDI resources it allocates, and the main UI thread runs a routine periodically that frees GDI resources that are not locked. Which is very bad for TBitmap used in a worker thread. The alternative is to not use TBitmap at all, just use the Win32 API directly for all GDI operations in a worker thread.

No, you can operate on several canvases (of offline bitmaps or metafiles) in parallel, its is just a little bit less efficient since each canvas has to create its own font, pen, brush instead of using an existing one from the VCL sharing pool.

If you work with a TCanvas in background threads always wrap your code in canvas.lock; try ...operate on canvas here finally canvas.unlock; end; The VCL has a build-in mechanism to optimize use of GDI objects, which is shared between all TCanvases used, and his mechanism is not thread-safe. Locking the canvas makes sure it does not use this mechanism while it is locked.