PeterBelow

Well, it may work but I fail to see the usefulness of such a construct.

Because classes are reference type and records are value types. A variable/field of a reference type will always have a a known size, sizeof(pointer). A value type does have the size defined by the type and that would be unknown at the point of the foreward declaration. A one-pass compiler cannot handle that.

Generics in Delphi don't work the way you seem to think they do. To use the generic type T inside a method of the generic class with a specific type the compiler needs some minimal information on what T can be. That is what generic constraints are for. Unfortunately the constraints supported at the moment are quite limited and will not cover what you intend to do.

All components that have the form as Owner (which includes all components dropped on the form in the IDE designer) are automatically destroyed when the form is destroyed. So your query components are destroyed but whether that automatically releases serverside resources depends on how the component, especially its destructor, is implemented. But a TFDQuery will close the query when it is destroyed, so your scenario is OK.

One thing may be a problem. Both the cmtx22 and cmtx33 functions use a (global ?) variable cmtx but do not clear it first. So the array elements not set by the functions will have values carried over from previous uses of this variable. Sorry, but the whole design looks fishy and error prone to me and seems to use plain procedural programming 40 years out of date. You define a large fixed size array type, variables of which will not only waste a lot of memory for elements never used, but you also have no convenient way to figure out from a variable what the dimensions of the actually used part are. In my opinion you should build a TConfusionMatrix class, which internally uses a 2D dynamic array (array of array of extended) to store the values of the matrix. The constructor of the class would take the needed dimension and size the internal array accordingly. You could have additional constructors to build the matrix from your string representation or a 1D array of values, methods to return a string representation, to compare an object of the class to another, properties to return the dimensions of the matrix or to get or set element values. Since the matrix object knows the size of the internal array it would be easy to check report indexing errors and so on.

Does this project use QuickReports? If so, did you install this package on that machine? The exception class indicates that the error occurs while loading components from a DFM or perhaps a report template but the error message is a bit weird. Perhaps it is worded incorrectly and should say that only one instance of TQuickRep is allowed in this template...

Using Sharemem may give you a common memory manager for host app and dlls, but you still have separate code "instances" for all RTL and VCL stuff you use on both sides, which includes any global variables the units in question may use internally, the Application and Screen objects etc. If this worked in the past you have simply been lucky , but your luck appearendly ran out when you switched to the more complex FireDac framework. The only safe way to share object references between modules is to use packages instead of DLLs. Unfortunately, packages are all or nothing, you have to build host program and your own packages (which replace the DLLs you now use) with packages and deploy all the required run-time packages of the RTL, VCL, and whatever else (e.g. 3rd party stuff) to the user's PCs. Not fun. And if you load packages dynamically better not try to unload them in code as well, that has been a source of hard to track errors due to premature RTL etc. unit finalization in the past (may have been fixed but is hard to verify). If you want to stick with DLLs you need a different design that shares interface references instead of object references between the modules. Host and DLLs would use a common unit with the interface declarations; all exported functions would use interface references instead of object references. For the classes you now share you would have to write a layer of TInterfacedObject-derived wrappers that implement the interfaces that allow you to safely call methods and access properties od the wrapped objects.

A TListview is not designed to host other controls. Take a look at TControllist, it may be more suited to your requirements. Another option would be a TScrollbox with a number of instances of a custom frame (which are created in code as needed, each representing the data of a suitable object or record).

Not easily, no. You would have to draw the text yourself (OnDrawCell event) and also adjust the row height as needed. Perhaps showing the full text in a popup hint would be easier to implement.

See the TextHint property of TEdit, that's probably what you are looking for. If not give us more detail.

The problem is likely the huge jump in the Word versions. Newer Word versions use a different document format and plainly refuse to edit documents in ancient formats like Word97, although you can still view them (my latest version installed is Word 2016, so still much older than Word365). You may have to rebuild your template dot with the new Word version to get it to work as you want.

A radio group, by its very nature, must have one of the options checked. If you need to indicate that none of your two options applies then that has to be added as a third option that is checked as default. What type of database field have you tied the group to?

This may not do what you expect it to do. ALength may be int64 but the compiler will calculate the right-hand side using a smaller integer type into which both the constant 2 and errorlevel fit and only extend the result to int64 before storing it into Alength. So the calculation may well overflow the range of the type used for the calculation, and since D12 has enabled overflow and range checks by default you get an exception. Change the code to Alength := int64(2) shl errorlevel; to force the use of int64 for the calculation.

The Install packages dialog affects the current project only if you have one open, and the IDE basic configuration if you have no project open. Changing the latter will not affect any projects you created before, though. To get rid of the package for good you have to edit the registry key HKEY_CURRENT_USER\SOFTWARE\Embarcadero\BDS\21.0\Known Packages (for D10) and rename the items for the dclbind*.bpl packages or move them top the "Disabled Packages" key.

Put all controls on the form on a client-aligned panel and then simply disable the panel while the background thread is active. Also use a handler for the OnCloseQuery event to prevent closing of the app while the thread is running. If you have a main menu bar tie all menu items to actions and disable the actionlist while the thread is running. Just don't forget to enable all the stuff again when the thread is done.

Delphi forms tend to recreate their window handle at the drop of a hat. So move the DragAcceptFiles calls from the events to overridden CreateWnd and DestroyWnd methods, that makes sure the handle changes are properly handled.

See this blog post. Sometimes part of the pages work, but getit is the least stable. If you have it try to installing from the ISO.

You know that this forum is not the right place for feature requests, do you? The replacement for Embarcadero's Quality Portal will hopefully be online soon, post a request there.

Check the project dpr file. Have you set Application.MainformOnTaskbar to false there? Does the form class override the CreateParams method or CreateWnd?

It might be worth noting that XML documentation tags also work inside a normal Delphi comment (enclosed in braces {}) instead of these horrible triple slash comments copied from C# along with the XML tags themselves. Much easier to maintain in my opinion if a tag content spans several lines.

The posted image is not large enough to make out any details unfortunately. Is this a MDI application by any chance? That is an area in the VCL where some major changes were made.

You call GetLastError after the Create call. It will return ERROR_ALREADY_EXISTS if the named semaphore already exists. That also applies to other named synchronization objects, like mutexes. See the API function CreateSemaphoreW. TSemaphore inherits a property LastError from THandleObject, it may serve as well.

If you're german you may want to post on the german DelphiPraxis site, link is at the top right of this page. Anyway: in the Tools -> Options dialog you can find the default folders the compiler will put package-related files in (*.bpl, *.dcp). But these can be overridden in the project options for each package project, so check there too. The project options should have "$(BDSCOMMONDIR)\BPL" as package output folder to use the IDE default. The run-time package has to be in a folder that is on the system PATH, since such packages are loaded by the OS following the same search logic used for DLLs (in fact packages are DLLs with some Delphi-specific extensions). The design-time package can be in a folder not on the PATH since the IDE loads design-time packages using the full path. The IDE installer adds the default folder for run-time packages to the PATH, but that may fail if your PATH is already very long, so better check it. As for installing: do you get no context menu if you right-click on the project name in the Project Manager view?

iSQL is a console program. The system menu of the console should contain a menu item "Properties" (on my german Windows 10 it is called "Eigenschaften") and in the dialog that calls up you can set font size, color, name etc.

Looks like the folder the created dcus are in is not on the IDE library path or the project's search path. Add that folder yourself.