geteventa32 or getevent32

Originally posted by herbert
how to write an application which does not use 100% resources of symbian and lets me use the keyboard and draws something on a screen !
geteventa32 does the job but 100% system usage (a pause 3 helps but there are delays in usage of programm !)
getevent32 waits for keyboard event !

You should not use PAUSE with GETEVENTA32.

Instead, use IOWAIT and let your asynchronous loop handle all the events that you need to do, including keyboard and pen. IOWAIT also waits for an "event" (or more accurately for an asynchronous request to complete).

To get a rough idea check this thread:

"Asynchronous Event Handling - bugs in OPL for v6/S80".

This is a generic event loop in which you can define your pen and key events under the

EventKeyProcess: and EventPenProcess:

procedures.

A more nicely formatted version is available at: www.dp.com.my [dpNotes] dpNote0028

Are you on v5/Eikon, v6/S80 or v6/S60?

Take note of the comments regarding suspected bugs in v6/S80 which most probably would be relevant for v6/S60 as well.

cheers
martin

hi

1000tx - i guess thats it :>

ciao

Big warnign sign - while ASync operations work on 9210, Series 60 has NO Async features yet. As to the 9210, the IOTimer isn;t yet working.

All this is reolated to the might FEP problem/bug/interface.

😞

We're working on it.

Originally posted by Ewan-FreEPOC
Big warnign sign - while ASync operations work on 9210, Series 60 has NO Async features yet. As to the 9210, the IOTimer isn;t yet working.

Thanks for the clarification. We have to hold our horses for a while more before testing async in S60.

However, as the referred async loop shows, the S80 Timer *is* sort of working in the sense that it runs. But something is generating masses of stray signals and it hangs without the two extra IOSIGNAL in the stray signal counter. If this is a bug in the timer, it might explain this behaviour.

cheers
Martin

hi

what about an async opl application which must run in background ! the example stops there with kern-exec 15 (i removed the check for foreground) 😞

ciao

I do not know which example you are referring to. Pls post your code.

In any case, KERN-EXEC 15 is when you are starting a timer before the previous timer has completed.

hi

yes i noticed. anyhow if there would be no bug all would be fine ! calling iosignal twice floods the application and the loop works only until a certain time and waits for user input.

without iosignal all is fine - only it stops after a certain time calling iowaitstat !

is there no help ? is it not possible to let an application run in the background ?

ciao

I can't see how running the application in the background would make any difference for the asynchronous event handling. You do not get rid of the bugs by wiping them under the carpet.

Unless you mean the following:

1. Remove all asynchronous calls and replace with a synchronous version in the main application.

2. Create a separate OPO with a synchronous timer. Run this OPO in the background with RunApp.

3. This OPO could send a keyevent back to the calling application when it has completed.

I have not tried this, but it could solve your problem.

cheers
Martin

hi

the last idea works better but consumes 30k more ram 😞
is there no chance to have opl use threads ?

any chance to start that opo (runapp) hidden ? does not look so nice in a process list 😞

ciao