DLL thread in the pit daddy's synchronize?

1, origin

Developed a voice-to-Talk Windows program, using the Delphi language, and the Delphix tdxsound control.

The Dxsound provides a Tsoundcapturestream class that allows you to record sound cards for a specified frequency, number of digits, and channel. In its Onfilledbuffer event processing, the audio data is sent to the specified device for streaming intercom.

First write a Test exe program, run OK. It then needs to encapsulate its functionality as a DLL function for other applications to invoke when it is developed, encapsulating it and finding that the microphone's sound is not being sent out. WTF?

2, analysis

Debug found that the callback event code in Onfilledbuffer has not been executed since the call DLL started the talkback function. This does not exist in the EXE program. Remember that Udpserver control has a similar problem, if not set to its Threadedevent property is true, then its Onudpread event in the DLL is basically not receiving any information.

But are there similar property settings in Dxsound? View the source code of the Dxsounds unit and discover that Tsoundcapturestream has a fnotifythread attribute (another thread!). ), when the Start method is called to begin capturing the sound card, a tsoundcapturestreamnotify notification thread is created, and the notification thread calls the Synchronize (Update) method to send the sound card information to the main thread.

Query data found that if the project file is a DLL instead of EXE, application default does not create a window handle, so synchronize send a message to application will not respond at all.

See also: https://www.cnblogs.com/enli/archive/2010/09/28/1837728.html

3, solve

The solution is also to use the method provided above, in the DLL's L project file to add the following statement, problem resolution.

application.initialize; if 0  Then begin     Application.createhandle; End ; Application.Run;

DLL thread in the pit daddy's synchronize?