Uwe Raabe

Do you make sure that the datamodule is created before the form is loaded? In similar cases I usually create the datamodule with the form as parent in the form Create (i.e. before the form is loaded). That guarantees that the references to the datamodule can be resolved. If you are interested there are some explanations about DFM loading in this article: Tweaking DFM Loading

There is also Undertand from SciTools, although a bit pricy.

It is only since V15.1 that MMX tries to resolve include files. Before that any $I directive was just ignored (as was almost any other directive).

The problem is that MMX doesn't search for the INC files, because it misses to add the default extension. I will fix this in a future release. As a workaround you can try to add the .INC extension in the source - or wait for an MMX update.

Are both include files existent with an .INC extension? In that case MMX just misses to use this as default extension.

Can you show the corresponding source lines?

How do you guarantee that memfloorobjects.CreateBlobStream actually returns a TnxBlobStream? What is a TnxBlobStream? How is BlobStream declared? What is memfloorobjects? Why do you list memfloorobjects in the with and still reference it in the code so no one can see at a glance where it is used? Why do you use with at all as it only obfuscates the code here? What is GraphicClass and where it is used? Why is the try not directly after TBitmap.Create? Why do you cast to TnxBlobStream when Free is already declared in TObject? What object is created in that line? Neither b nor BlobStream are created in that line and those are the only objects you free.

That is one reason why I am sceptic when someone claims Delphi should support this feature or have that tool out of the box, while often there already exist 3rd party solutions covering all these. I would rather see Delphi step back and concentrate on its core functionality instead of constantly broadening the target. Either these have to compete for the limited resources or they are going to be abandoned like ever so often. Just buying a tool as a Delphi companion is only the start. It needs constant and sufficient investment to keep it going.

That message can also mean that some other module could not be found that the named one relies on.

Check if fMatchResult has its Visible = True in the designer and switch it off to fix the issue.

If it is not that difficult, why don't you create such an example yourself and attach it to a bug report with all necessary steps? That would at least match the workflow Embarcadero is used to.

Is there a way to setup a shortcut to "re-run" the Delphi LSP instances?

Under Tools - Configure Tools add a new entry named Kill LSP with the following settings: Code: Program: taskkill Parameters: /IM DelphiLSP.exe /F

Fine, but there are other means to make the query fetch the complete result set. A simple Last call or setting a local index different to the query order can have the same effect.

Are you fetching the whole result set at once?

I doubt that anyone from Embarcadero can do something against a Windows internal error caused by an update. At least as long as Microsoft doesn't provide steps to work around that.

See KB5020387

Where do you get that information? To my knowledge it is Win10 21H1:

That indicates that somewhere is a direct reference to the XE5 folder in your system. Can it be that in the past you had a Professional edition with FireDAC extension and some remnants cause this?

The issue was not caused by the Delphi components itself, but by the WinApi interface they use, which acted faulty after the Windows update. As stated in my previous comment the issue is already solved with KB5020435. Thus I have no need to switch to any 3rd party component.

And you can confirm that $(BDS)\source\data\firedac is in the IDE Browsing Path and the XE5 path doesn't appear anywhere in the Delphi 11 installation nor in the project?

The $(BDS) variable is set for the current IDE when it is started. If you have multiple IDE instances open each get its own value for $(BDS). There must be something else going wrong in your installation. Is this for all projects or only for one?

Have you checked your library and browsing paths?

I can confirm that KB5020435 solves this issue on my system. As Windows Update didn't list it, I had to download and install it manually

I don't know if all is necessary, but I at least it is sufficient: have a field for the sub component exposed as a published read-property create the instance in the constructor (Self as Owner is allowed omitting the Free in the destructor) call SetSubComponent(True) after creation set all properties as needed don't forget to set Parent