How to issue commands from a Thread to the (main) AppUI-Thread?

[NevenS]

Hello,

I have a running RThread* thr.

I also have a running AppUi* appUi where
class AppUi : public CAknViewAppUi.

Lets say appUi is running in thrMain and thrMain!=thr.

How can I generate commands in thr for appUi which will be processed in appUi->HandleCommandL() or similar function? So this HandleCommandL() must be running in thrMain thread context.

Thanks in advance

[sriky27]

Hi,

If I am correct I guess you have to use IPC for communicating between them

[yogpan]

Hi,
Of course you have to have IPC communication, but is there any specific reason for having such functionality. I mean is it that some other application needs to send some sort of signal to other application to execute command. In that case you can try using RProperty also.

[NevenS]

Hi,
before I start implementing CActive objects and RProperty, is there no way for the thread thr to simulate commands which can be handled in thrMain in the AppUi->HandleCommandL function?

Something like: thr uses the CCoenv::Static (or an instance CConev::Static points to, recursively if needed) to send commands to AppUi? For example (pseudocode)

THREAD thrMain
..AppUi created & running
handle = CCoenv::GetWindowHandleOf( AppUi );
thr->AppUiHandle = handle
AppUi::CCoenvMessageHandlerRuns()..

THREAD thr
..thr created & running
CCoenv::SendMessageTo( thr->AppUiHandle, someMessage )

THREAD thrMain
..AppUi::CCoenvMessageHandlerRuns( message )
message == someMessage


I am not looking for InterProcessCommunication but for a simple InterThreadCommunication (or INTRAProcessCommunication). Unless the CCoenv (the whole GUI Handler) is running in an own process.

[sriky27]

Hi,

I never tried doing that and you have rightly pointed out that it is Intra Process communction. May be it is a good way to start off.

[wizard_hu_]

Singleton-like entities in Symbian API-s are usually thread-specific (since they still use TLS somewhere in the deep). So you can not access CCoeEnv in a secondary thread.
You can benefit from the fact that threads share their address space and use RThread::RequestComplete directly. This way you still need active objects, but you can eliminate the need for copying memory around what "traditional" IPC mechanisms (client-server, message queue) would do.
In this case you need some access control, you can guard the shared objects with an RCriticalSection for example.

[NevenS]

RThread::RequestComplete wouldn't work since it should be used from "this" thread to signal "this" thread that an async. request is complete (so says my s60 developer docu). So I could not pass a TRequestStatus from ThreadA
to ThreadB and use RThread::RequestComplete to signal from B to A that A's request is complete.

I found a work-around though. The Main AppUI Thread is using an ActiveObject timer to check on all the worker threads.. I really hope this is not the best solution there is on Symbian, but I just don't know how to send signals from an RThread to the AppUI Thread without blocking the AppUI Thread (it's not good since GUI would block).

And yes, MessageQueues etc. are known to me.

[wizard_hu_]

RThread::RequestComplete wouldn't work since it should be used from "this" thread to signal "this" thread that an async. request is complete (so says my s60 developer docu). So I could not pass a TRequestStatus from ThreadA
to ThreadB and use RThread::RequestComplete to signal from B to A that A's request is complete.

You are confusing User::RequestComplete (working on the current thread) with RThread::RequestComplete (which obviously works on the thread referred by the given RThread object. It can be "this" too, but it can be a completely different thread, whatever you RThread::Open).