PeterBelow

OK, I would not do it this way, but your problem is probably a missing FormType node in the DPROJ file. Look for nodes "DCCReference Include" and see how a "uninherited" datamodule is defined there. Compare with one of your derived datamodules.

To make the inheritance work for designer classes like a data module your TBaseDataModule has to have a DFM-file, even if it is practically empty, but it must contain a valid Name property. The simplest way to get one is to create a new data module in the IDE and change its Name property to BaseDataModule, then save the unit under the name you want. You can now change the inheritance of your TMainDataModule in the editor, but you also have to switch the designer for that module to the dfm view and there change the first "object" keyword to "inherited". And make sure your TBaseDatamodule is not in the list of autocreated items! You can delete the BaseDataModule variable the IDE created for you, it is not needed.

Microsoft has released several versions of the richedit control over the decades, TRichedit in the current Delphi version (since 11.0 if memory serves) is based on version 4 (the latest and most feature-rich). The Jedi version may be based on an older version. The divers versions are implemented in separate DLLs with different names and use different window class names, so they can coexist on a given Windows system. Different versions may explain the behaviour you see.

Won't the MS Store sign the package for you when you upload it? I dimly remember some mention about this (also for Google and Apple app stores) in a webinar i watched recently.

Is the BiDiMode property set to true on all controls in question? Also look at the methods in the see also section at the bottom of the page linked to for BiDiMode, may be important if you test on a non-hebrew locale.

I just add the "library" foms to the project that needs them, this way the required path is in the dpr file uses clause. Btw.: I think this DCC_RessourcePath is for the resource compiler and you can set it under that node in the Options dialog. Never needed that myself, though.

Then why don't you delegate the hint showing to a task running in a secondary thread? The task can wait for a short interval and if it is cancelled before that interval has elepsed the hint will not be shown at all...

The answer is no since the update would have to be triggered somewhere from inside the work code. But you can create and show a window from a secondary thread, it is just a bit cumbersome to do since the visual part of the VCL is not thread-safe. The secondary thread needs a message loop that will process all messages for the window, including timers and paint messages. The simplest way to get that loop is to show the window modally. And the safest way to do such stuff is to not use a Delphi form but do it all the API way (hence the cumbersome part above 8-)). If you want to use a Delphi form the important points to mind are: Do not autocreate the form! Create the form inside the Execute method of the secondary thread, using Nil as owner. Use a try finally block to make sure the form is destroyed. Use a field of the thread class to store the form reference. ShowModal the form. Add a public method to the thread class the main thread can call to get the form to close once the work is done. The method should set the form's ModalResult to mrCancel to allow the modal loop to exit normally.

Try to set the KeyValue property to the ID you want to look up.

A Windows service should to all of its work in a secondary thread started in the OnStart event (and terminated in OnStop, perhaps also paused and resumed if possible in the corresponding events). The main thread should only process commands received from the service manager, which TService handles internally. That aside: from a look at the source TServiceApplication actually starts any services in a secondary thread and, after launching that, goes into a simple loop (actually it calls Vcl.TApplication.Run) which does the normal Idle processing, including the CheckSynchronize call that handles queued or synchronized tasks from background threads. So your construct will probably work, but I would not go this way in a service application. If the queued call blocks for some reason that would prevent the service app from terminating.

The control has a ShowCheckbox property. This gives the user a checkbox to check or uncheck to indicate a NULL or NOT NULL state. The Checked property then tells you the user's descision. A bit cumbersome but the Windows common control behind TDatetimepicker has no concept of an "empty" state.

A TList<T> has a constructor overload that takes a comparer (IComparer<T> instance) to use for sorting and searching the list by default. The Sort method also has such an overload. You use TComparer<T>.Construct() to fabricate a suitable comparer on the fly, providing an anonymous method that does the actual comparison of two items in the way you want the sort to go. This anonymous method has to "know" the record type in question, so you can directly refer to the fields of the two items passed to it. Forget about pointers, you do not need them to work with generics.

Set the DefaultMonitor property of the form to dmDesktop, this way the form left and top do not depend on the monitor the form is on and will restore the form to the monitor it was on before (unless the user rearranges his desktop configuration). For the necessary code see the PB.Winset unit in the attached archive. Winset.zip

Well, well, has been some years since somebody asked about chemistry here 8-)... As it happens I am a (retired) organic chemist and have worked for more than 30 years for a german (later french) pharma company in research. I wrote a lot of software working with chemical information, mostly from chemical databases. While the core of my library depended on MDL (later Accelrys) ISIS (long dead) and their Oracle chemistry package I tried during my last year at the company to get rid of the ISIS dependency by creating a Delphi wrapper for the Indigo library. Unfortunately I did not have enough time to complete and test the wrapper, and it is based on the 2017 32-bit Indigo DLLs, but perhaps you can find something of use in the mess. I also included some other units related to chemistry in the attached archive without ISIS dependencies. Have fun ;). chemistry.zip

If memory serves the IDE deletes these files when it closes normally. Check the first two items under "Autosave" as well. The first creates backups of open units in the _history folder.

Not if you use the standard Windows style. If you configure the app to use one of the custom styles (like Windows 10) you can set the StyleElements.seFont property element to false and it will then use the font.color you set and not the Windows default.

If you only need to capture TWincontrol decendants you can do this with a few code lines using the TWincontrol.PaintTo or TWincontrol.PaintWindow methods, using a properly sized TBitmap as target.

Try the ItemWidth property instead.

From the help it looks like the StyleServices function can take a parameter that specifies the control you want the style info for. So, have you tried to pass a main menu instance as this parameter? Or look at the drawing code in vcl.menus.pas, that should show you how the vcl gets the colors to draw with.

Components dropped at design time load their properties from the dfm file after the constructor has executed. To set a property to a different value you need to override the Loaded method and do the deed there.

I assume Forms.Dialogs.pas is a unit not defining a form build in the form designer? In this case I would export functions from that unit that internally create and show(modal) one of the specific form classes, setting any needed setup values from parameters passed to said functions and returning any data entered/selected by the user as function result or in var or out parameters. This way other units need not require the specific form class units in their uses clause, only Forms.Dialogs. Note that the dialog forms would not be autocreated in this setup, the exported functions would all create, show, and then free a new instance of their dialog form.

The VCL has to work in the API environment that Windows provides. So aim your criticism at Microsoft ;).

You are wrong, the design makes eminent sense for a message/event driven environment like Windows. A modal form has its own internal message loop and that needs a way to figure out that it should exit the loop. Modalresult <> mrNone is that condition.

The IDE requires Win10 or 11, but applications build with it can run on older Windows versions, depending on which features they use. It may be necessary to modify the default manifest, though, if it specifies a newer Windows version as requirement (have not checked if it does).