11-23-2009 04:29 AM
"The only reason for the globaleventcode is to communicate information to the phonelistener. The application in question is running on symbian where internal TCP communication is used as the communication vehicle.
If there is an alternative way of sending commands to and receiving information from a running phonelistener I would like to know how"
I presume this is 'configuration' type information. A Phone Listener is not running. It is driven by events (but not GlobalEvents). When these events occur, the Phone Listener can do whatever it likes. It can, for example, check a shared class and determine what needs to be done - this shared class could be in RuntimeStore which can be updated independently. So you can do what you want to do without combining the implementations by 'communicating through RuntimeStore.
In your circumstances, I would look to fire a GlobalEvent from the Listener, and process that GlobalEvent in your own Application process (not your own Application class). Then your Application does not have to tell the Listener anything and you run as little code as possible in the Phone Application Process.
11-23-2009 06:38 AM
OK, thanks (and cudoed) Peter,
Tested the globalevent sending from Phonelistener and thats OK. So its possible to combine globalevents and
phonelistener in one direction :-)
Will use runtimestore or maybe RMS RecordStore the other way
11-23-2009 07:03 AM
"Will use runtimestore or maybe RMS RecordStore the other way"
Don't forget you can use PersistentStore too, if you need the 'configuration' data to be permanent.