Delphi - Creating a control that runs in its own process

Question

HI

I have a control that accesses a database using proprietary datasets. The database is an old ISAM bases database.

The control uses a background thread to query the database using the proprietary datasets.

A form will have several of these controls on it, each using their own thread to access the data as they all need to load simultaneously.

The proprietary datasets handle concurrency by displaying a VCL TForm notifying the user that the table being opened is locked by another user and that the dataset is waiting for the lock to be released.

The form has a cancel button on it which lets the user cancel the lock wait.

The problem:

When using the proprietary datasets from within a thread, the application will crash, hang or give some error if the lock wait form it displayed. I suspect this is to do with the VCL not being thread safe.

I have solved the issue by synchronizing Dataset.Open however this holds up the main thread until the dataset.open returns, which can take a considerable amount of time depending on the complexity of the query.

I have displayed a modal progress bar which lets to user know that something it happening but I don't like this idea as the user will be sitting waiting for the progress bar to complete.

The proprietary dataset code is compiled into the main application, i.e. its not stored in a separate DLL. We are not allowed to change how the locking works or whether a form is displayed or not at this stage of the development process as we are too close to release.

Ideally I would like to have Dataset.open run in the controls thread as well instead of having the use the main thread, however this doesn't seem likely to work.

Can anyone else suggest a work around? please.

Your question makes no sense to me. To create a control in a separate process, you put it in a separate application. Fibers are no more safe for use with the VCL than threads. It's not at all clear why the ISAM database's lock message would be a problem; does it directly use the VCL? If so, how? — Ken White
I was just wondering if it was possible to have a control that runs in a seperate process but displays on the form of another process and to do this without having a seperate executable. The ISAM dataset component displays a lock message which is basically a TForm with a cancel button on it. The lock message notifies the user that the table being opened is currently locked by another user. The user can then choose to either wait or press the cancel button. Its code from why back in the DOS days ported to windows and something that I can't change. — There is no spoon
It is possible to have UI from different process appear inside a single parent container. Consider Chrome or IE8. I don't see that you need to do this. You can have UI in background threads, so long as that UI is completely segregated. If this other code is delivered as a DLL then I don't see why you have a problem. — David Heffernan

mghie mghie · Accepted Answer · 2011-03-20T08:46:15

Fibers won't help you one bit, because they are in the Windows API solely to help ease porting old code that was written with cooperative multitasking in mind. Fibers are basically a form of co-routines, they all execute in the same process, have their own stack space, and the switching between them is controlled by the user code, not by the OS. That means that the switching between them can be made to occur only at times that are safe, so no synchronization issues. OTOH that means that only one fiber can be running within one thread at the same time, so using fibers with blocking code has the same characteristics as calling blocking code from within one thread - the application becomes unresponsive.

You could use fibers together with multiple threads, but that can be dangerous and doesn't bring any benefit over using threads alone.

I have used fibers successfully within VCL applications, but only for specific purposes. Forget about them if you want to deal with potentially blocking code.

As for your problem - you should make a control that is used for display purposes only, and which uses the standard inter-process communication mechanisms to exchange data with another process that accesses your database.

Delphi - Creating a control that runs in its own process

2 Answers