Iscancode and icode in Symbian

Author:Sun DongfengArticleSource: site original Update Time: 8:38:34 

 

We know that the following methods are used to process key events in Symbian:

Tkeyresponse cmegajoycontainer: offerkeyeventl (const tkeyevent & akeyevent, teventcode Atype)

This method is a virtual function defined in ccoecontrol (control base class from which all other controls are derived). Its definition is as follows:

Offerkeyeventl () Virtual tkeyresponse offerkeyeventl (const tkeyevent & akeyevent, teventcode Atype ); Description Handles key events. If a control wishes to process key events, it shocould implement this function. The implementation must ensure that the function returnsEkeywasnotconsumedIf it does not do anything in response to a key event-otherwise, other controls or dialogs may be prevented from refreshing the key event. If it is able to process the event it shocould returnEkeywasconsumed. Note: If a control wants to process key events, it should implement this function. If the control does not do anything for a key event, make sure that the function returns ekeywasnotconsumed in the implementation of the function. Otherwise, other controls or dialog boxes in the Control Stack may not receive button events. If this control can handle key events, it should return ekeywasconsumed. When a key event occurs, the control framework callthis function for each control on the Control Stack, until one of them can process the key event (and returnsEkeywasconsumed). Note: When a key event occurs, the control framework calls the offerkeyeventl method of each control on the Control Stack until one of them can process the key event (and ekeywasconsumed is returned ). Parameters Const tkeyevent & akeyevent The key event. Teventcode Atype The type of key event:Eeventkey,EeventkeyupOrEeventkeydown. Return Value Tkeyresponse Indicates whether or not the key event was used by this control. Notes: Each keyboard key press results in three separate events: eeventkeydown, eeventkey, and eeventkeyup, in that order. When each key is pressed, three independent events are generated in sequence: eeventkeydown, eeventkey, and eeventkeyup. To receive key events, which can be processed by this function, the application shocould call ccoeappui: addtostackl () to add the control to the stack. this only applies, however, to controls which are not components of a compound control. compound controls shocould pass key events to their components as necessary: the components themselves do not go on the stack. To receive key events, applyProgramCall the ccoeappui: addtostackl () method to add the control to the stack. Although this rule is only used in non-mixed controls. The hybrid control should pass the key event to its component: the component itself is not on the Control Stack. Classes that override ccoecontrol: offerkeyeventl () shocould also override the inputcapabilities () virtual function, returning a jsonobject whose attributes correspond to the behaviour of the offerkeyeventl () function. note that it is not necessary to call inputcapabilities () on any component controls from inside a class 'inputcapabilities () function-this is done automatically by the UI control framework. The class that loads ccoecontrol: offerkeyeventl () should also overload the virtual function inputcapabilities (), which returns a tcoeinputcapabilities object. The properties of this object are consistent with the behavior of the offerkeyeventl () method. Note that the inputcapabilities () method is not required in the control, because this process is automatically completed by the UI control framework.

 

Virtual tkeyresponse offerkeyeventl (const tkeyevent & akeyevent, teventcode Atype );

There is nothing to say about the second parameter. It represents one of the three key events. Let's take a look at tkeyevent:

Struct Tkeyevent Tkeyevent Support Supported from 5.0 Description Key event details. when processing a tkeyevent , the tstdscancode in iscancode shocould usually be ignored in favor of the tkeycode in icode . using iscancode wocould bypass the keyboard mapping and any FEP that happens to be installed. the exceptions to this general rule are games where the positions of the keys are more important than their translations, and FePS that are implementing keyboard maps themselves. in these cases, if the icode is used rather than iscancode to determine the key pressed, there will be two unfortunate consequences. firstly, the low-level keyboard mapping might re-arrange the mapping that you are trying to impose. secondly, you will subvert the CTRL + number method of entering Unicode literals. Note: When processing a tkeyevent, iscancode in tstdscancode should be ignored and I code in tkeycode should be used. Iscancode can bypass keyboard ing and any installed FEP (a front-end processor ). The exception to this rule is the game, because the keyboard orientation in the game is more important than their actual values, and in FEP, they have implemented keyboard ing. In these cases, using icode to determine the buttons has two unexpected consequences. First, the underlying keyboard ing mechanism may reset the keyboard ing. Second, you will destroy the CTRL + number method for inputting Unicode characters. Members Defined inTkeyevent: Icode,Imodifiers,Irepeats,Iscancode   Member Data Icode Tuint icode Description The character code generated forEeventkey, Or 0 for a down or up event. Key codes for special keys are defined inTkeycode. Corresponds to the authorization code generated by an eeventkey. The value is 0 when the key is pressed or released.(Note that the value on the screen is 0 when no buttons are pressed during the test. The value is generated only when the key is pressed for more than several seconds, when the button is released, the value is 0, so if you write the followingCodeThe value is always 0, and the actual value cannot be tested: If (Atype = eeventkeydown ){ Tbuf <40> scancode; Scancode. appendnum (akeyevent. icode ); Scancode. Operator + = _ L ("iscancode is pressed down! "); Ceikonenv: static ()-> infomsg (scancode ); } So we should write it as follows: If (Atype = eeventkey ){ Tbuf <40> scancode; Scancode. appendnum (akeyevent. icode ); Scancode. Operator + = _ L ("iscancode is pressed down! "); Ceikonenv: static ()-> infomsg (scancode ); } When Atype is eeventkeydown or eeventkeyup, The icode value is 0. ). Key codes of a specific key are defined in tkeycode. Imodifiers Tuint imodifiers Description State of modifier keys and pointing device. modifier keys are defined inTeventmodifier. Irepeats Tint irepeats Description Count of auto repeats generated. 0 means an event without repeats. 1 or more means "this variable Auto Repeat events". It is normal to ignore this value and treat it as a single event. Iscancode Tint iscancode Description The scan code of the key that caused the event. Standard scan codes are defined inTstdscancode.

 

Therefore, we can see from the above SDK help that the value of iscancode is the scan code of the actual keyboard, that is, a key corresponds to a number. Icode is a key ing, suchEkeyleftarrow,Ekeyrightarrow,Ekeyuparrow,EkeydownarrowAnd ekeydevice3 represent the left, right, top, bottom, and fire keys respectively, while 63554 and 63555 represent the Left and Right soft keys respectively.

Therefore, icode is more universal and the following problems do not occur:

I wrote a program using caknview: offerkeyeventl (const tkeyevent & akeyevent, teventcode Atype) to accept Keyboard Events and only process "*" buttons. I found that, the value of estdkeynkpasterisk defined by Symbian is 133, which works normally on the simulator. However, after I switched to Nokia 6060, I failed. Later I found that the scanning code for Nokia 6060 to "*" is 40, I am confused that if every mobile phone defines its own scanning code system, what is the role of Symbian's scanning code constant? In addition, do all mobile phones not follow the Symbian scan Code definition? If so, isn't each mobile phone model having to define its own scanning terminal file? That's a very scary thing.