Tobias Grimm wrote: > Klaus Schmidinger wrote: > > >>The cMenuText menu doesn't want any higher level menu (from >>which it has been invoked) to do anyting special in case, e.g., >>a color key is pressed. Therefore it only processes its known >>keys and makes everything else be ignored. > > > > Ok. I thought a menu should only return osContinue for keys, it has > processed and I never saw a reason for a parent to process the keys > pressed from it's child menu. But if I understand you right, osContinue > is returned for keys, that no other parent menu should process. > > Is this a valid usage scenario for a plugin?: > > Story: In an item list, items are selected by the cursor key and the > color keys invoke actions on the items. Opening an item with kOk should > display some details, but the color keys should do exactly the same as > in the list. > > Implemented like this: A class derived from cOsdMenu show's a list of > items. Pressing a color key invokes an action for the selected item. > Pressing ok shows item details in a cMenuText-submenu. The class that > inherits from cMenuText overrides ProcessKey() and returns osUnknown for > the color keys. This way the parent's key actions are invoked. I guess this should work. Klaus
