Leaderboard

https://quality.embarcadero.com But I can tell you right now that most, if not all, of your complaints aren't bugs and will never be implemented as new features or enhancements. Just because something doesn't work the way you'd like it to doesn't make it a bug.

Blocking the app does not require blocking the UI thread. Your code should not sit there blocking the main UI thread waiting until the worker thread ends. Let the code in the UI thread return control back to the VCL's main message loop. Have the thread notify your code when it has finished its work. Simply prevent the user from interacting with your UI in the meantime, if that is what you need to do. Both of the solutions presented to you above will accomplish that for you. You should read the following article: Modality, part 1: UI-modality vs code-modality It is written from the perspective of the Win32 API, but since the VCL is based on Win32, the same concept applies in this case. That requires message handling. Of course, you will get that with an Application.ProcessMessages() loop, but that opens up your code to a host of issues, which have already been pointed out earlier. If you are going to process messages anyway, you may as well let the VCL do it for you. Don't block your UI thread.

Unfortunately, as I already pointed out earlier, the VCL's TApplication constructor calls OleInitialize() before the ComObj unit has a chance to call CoInitialize/Ex(), and OleInitialize() internally calls CoInitialize(nil), so if you require CoInitializeEx() with any mode other than COINIT_APARTMENTTHREADED then you will have to do your COM work in a separate worker thread instead of in the UI thread. The ComObj unit is not the only unit that uses InitProc. InitProc is a chained list of initialization procedures, so you can't use Assigned(InitProc) alone as an indicator of whether you should call CoInitializeEx() or not. If you need CoInitializeEx() called, then just call it yourself unconditionally, and just be sure to pay attention to whether it fails or not. Returning S_FALSE is NOT a failure condition! A thread cannot change its COM threading mode once it has been set. That is what the RPC_E_CHANGED_MODE error code tells you. That IS a failure condition! If you need to use a different COM threading model than the calling thread has already been set to, you will have to move your COM work to another thread that is able to be set to the desired COM model. Typically, but not necessarily always. It really depends on each app's particular requirements.

I think that you needs just add the "ODBC driver" for MSAccess +2007... or, install MSOffice, LibreOffice or OpenOffice suites Microsoft Access Database Engine 2010 Redistributable https://www.microsoft.com/en-us/download/details.aspx?id=13255 This download will install a set of components that facilitate the transfer of data between existing Microsoft Office files such as Microsoft Office Access 2010 (*.mdb and *.accdb) files and Microsoft Office Excel 2010 (*.xls, *.xlsx, and *.xlsb) files to other data sources such as Microsoft SQL Server. Connectivity to existing text files is also supported. ODBC and OLEDB drivers are installed for application developers to use in developing their applications with connectivity to Office file formats. create a DSN file and use it on FDConnection (.. ODBCAdvanced params...)

TApplication.CreateForm in the first place must create the instance (when the formcreate is called) and just after can assign it to mainform. You can do TMainForm.FormCreate(Sender: TObject); begin ..... MakeSurface(self); For me it's always a code smell when somebody uses a global variable or reference.

A simple debug would tell you the reason. At the moment of Application.MainForm.Formcreate the Application.MainForm property is nil.