PeterBelow

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.

Which Delphi version are you using? If Delphi 10 or newer you should have _history and _recovery folders in the project's folder, look there. And for the future: make sure you have the autosave feature enabled in the IDE options dialog!

Newer Delphi versions do not create these files anymore since that did only allow one single backup version to be maintained. The _history folder allows multiple versions of the backup, which is much more useful in my opinion.

Since the IDE is 32 bit and so is the integrated debugger debugging a win64 program does run via paserver, just locally. This did have problems in D10, which did get better in D11 and (supposedly, no personal experience yet) in D12. In your scenario it is not a network problem in my opinion, but the IDE is loosing the connection to paserver for some reason. If the error happens, do you see an instance of paserver in task manager? If not, do you see one before you run into the error?

What target platform is the program you try to debug for? This looks like a problem of debugging via paserver running on another machine over an unstable network connection...

You can install major versions in parallel but there is one known problem with D11 and D12 if you use certain IDE add-ins (Parnassus bookmarks and one other) due to a naming conflict in some DLLs they use. See here.

See TPath, it has divers and sundry methods to dissect pathes, including UNC pathes.

Write properly formatted code in the first place? (gdr)

Depends on what you consider "safe". Most stuff on GetIt comes with full source code, so you compile it yourself and for stuff like encryption you do not need any design-time packages, just the code units. I have used (ex) TurboPower Lockbox for encryption in the past; the most recent version can be found on Github.

Packages are an all or nothing thing. In your case the TIdentRec type used by host and package are not the same type, despite of the same name. The package and the host app each contain their own copy of the TestApi unit. To make this work you have to place this unit into its own run-time package, which is then named in the package list of the application and the requires clause of the dynamically loaded package. This way both use the same "instance" of the unit. If you load packages dynamically it is also more reliable to not unload them explicitely but leave that to the RTL package management when the application closes. This avoids some arcane problems with premature unit finalizations. In your case unloading the package seems to mess up the memory manager.

Yes, you have to make sure the dcus for debug and release are deposited in different folders and modify the debug dcus path in your project accordingly. I have no experience in building projects using run-time packages, but I suspect that you will have to build release and debug packages with different names to avoid conflicts. In fact I would recommend debugging without building with packages, if feasable. Makes life much easier...

Well, I tried your example in D12 ( Win32 target) and the evaluator rejected the expression outright: Edit: Tried same project in D11.3, same result. I suggest you delete the dproj file carried over from D10 and open the dpr in D11.3 to recreate the dproj.

Actually I would not expect that. The breakpoint is placed before the call statement to the IndexText funtion (check the assembly view) so the value of idx is unknown at that point; you have to step over the call to the function to make the result available. If it worked in D10 I would consider it a bug there unless you have tooltip expression evaluation active, in which case the debugger may execute the call to get the result for the tooltip.

TField.IsNull is the way to check if a database field is NULL. Do not rely on this conditions beeing mapped to a specific value.

Since several Windows versions an application running in background (= not having the input focus) cannot simply push itself into the foreground anymore because it thinks itself soo much more important than what the user may currently be working with. Instead it flashes its taskbar button to inform the user that it requires its attention. Does that not happen in your scenario?