|
|
Native Symbian input control and 3rd party library.
| Fri, 2008-09-05 17:52 | |
|
Hello all, The problem is that this library doesn't provide access to native controls (lib is cross platform), but I absolutely need a simple text input field (CEikEdwin) I found a way to construct it, but I can't get it to be drawn on the screen and it doesn't get focus and doesn't receive input. All I get with edgelib is a pointer to RWindow, screen surface bitmap (CFbsBitmap) and usual globals like CEikinEnv::Static() etc. (this information was given to me on edgelib forums) here's the code that dynamically crealtes input text field. RWindow *window = (RWindow*)m_pEdge->GetWindowHandle();Also, I tried to get it drawn on the screen by calling manually Thanks |
|
Forum posts: 1248
It is sometimes difficult enough to get Symbian controls working in their normal environment of (UIQ in my case) views and dialogs. I have seen enough crazy things like redraws that don't want to happen, Edwins that with a simple line of text take a full bloody second to refresh, and controls that suddenly draw white text on white background because they trip over their own skinning.
And now you want to get EIKON and S60 controls working in an edgelib environment? And at the same time break the cross-platform sense of that library which is a large part of its purpose in the first place?
I would say: Forget it and do something worthwhile, like taking the basic elements of edgelib and build yourself some simple text input field. If you choose functionality carefuly, that should not be that hard, shouldn't it?
René Brunner
Forum posts: 32
Well... how am I supposed to do simple text input control?!??
First of all, I don't really care if it breaks anything, since that part that needs to have the input box is used only on symbian. So, back to building input box myself... how much work is it supposed to be?!?! Do i need to handle cursor? cursor blinking?!? text selection??? copy-paste of selected text??? Virtual keyboard etc etc etc. On top of all that I'll need to precess input buffer and then draw text on the screen.... NO WAY I"M GOING TO DO ALL THAT STUFF!!!
I need to write it ALL or symply get enough information on how that drawing & event handling stuff implemented in edgelib and using that information make native control work properly. On edgelib forums they didn't say that I should write it myself (that's way too much work to make it work properly!), but instead they give me hints on how to get access to symbian specific part (RWindow CFbsBitmap and CEikonEnv)
Forum posts: 1248
A lot of !'s and ?'s do not make it better.
Of course you do what you deem appropriate. I am just stating my opinion, free for you to ignore. You are free to think that I don't know what I am talking about.
A simple text input control does not need a blinking cursor, nor text selection, and copy-paste even less.
Look, not much is known about the inner workings of S60 and UIQ controls, even less is properly documented, and this probably won't change until Symbian will be open-sourced around 2010 or 2011. What is known is that there are a lot of complex interactions between controls, windows, views, FEPs, control stack, focus handling and so on. If you with your edgelib hosted Edwin break just a *single* such interaction, if just *one* precondition for the proper functioning of the control is not fullfilled, it will not work. And good luck trying to find out what is broken. I had cases where I did hour-long debugging sessions going through Symbian on the emulator on the CPU instruction level, lacking source of course, to find out something.
It is just my very humble opinion that writing a simple edgelib-based input control will probably be less work than trying to get CEikEdwin working, certainly less stressful.
René Brunner
Forum posts: 32
Well, I understand what you say, but still I think it's possible to get that part done without major problems. All I need is to understand object relation of all that CEikAppUi's, RWindow's RWindowGroup's, RWsSessions and CCoeControl's and how drawing works and what guys at edgelib did to remove/hide all that code and how to get access to that system stuff.
I know a way how to make it draw on screen without flickering. I manually Flip() backbuffer on the screen and manually ->Draw() the text control, but I can't get it to be drawn by Ui framework automatically. Also, it doesn't receive focus and doesn't fire any events (in object observer).
Also, I noticed that calling SetFocus(); on the editor always panics with: QIKON-PANIC: 31, which is EQikPanicCommandModelNotFound. Maybe it gives any hints to anybody? I just want to make it done, it's like my personal goal, and it's not important if it's fragile. I just want to understand how Ui framework works in Symbian by trying to solve this problem.
Maybe I addtostack this editor to a wrong window? How do I get current window at the top? How do I get current view at the top? Is it intentionally done so that SetContainerWindowL couldn't take RWindow (it get shadowed by inheritance, and that's why I had to cast RWindow to CCoeControl to get access to this overload)? I can get access to CFbsBitmap, can I make my control to draw on that bitmap instead of screen? How do I make a control receive focus/input? (I tried to call all types of methods that enable focus receving on window group etc, but it doesn't help)
Forum posts: 1248
Well, of course nothing to say against making this one's personal goal. But then it is a good idea to make sure that one knows the size of the task. Your wordings like "All I need to understand..." tell me that IMHO you still underestimate the problem substantially.
I brainstormed a little about the problem, because it *is* interesting per se, and meanwhile I think chances are it's impossible to get it working. Why? Because I think that it won't be possible to get edgelib to cooperate in the correct way.
An example: For the Edwin to function completely, it must receive pointer events. How does it receive them? Simple question, really: The window's HandlePointerEventL must pass them to the control that has the focus. I would expect that for a window under edgelib HandlePointerEventL is implemented by edgelib itself. Now, the big question: Is there a mechanism in the Symbian variant of edgelib to allow you to hook yourself into the processing of that HandlePointerEventL method in order to delegate some of the pointer events to your waiting Edwin? Maybe, maybe not.
Second example: That panic, EQikPanicCommandModelNotFound. So there is no command model, right? Well, maybe edgelib makes *damned* sure that there is none because that one probably would be way too independent and for example draw unwanted soft button bars on the screen or catch pointer and keyboard events at the wrong moments. Now, your Edwin needs one, however, as it looks. Task at hand: Not only find a way to create a command model against the outspoken will of edgelib (might be possible), but also keep edgelib working properly at the same time (might be next to impossible.)
A third potential problem might be releasing the Edwin again: Does edgelib call your code at the right moment so that you are able at all times to properly release your Edwin? If not, you have a memory leak problem at hand, even if all other things work.
The whole thing would be *much* easier if edgelib and Symbian both were open source and one did not need to speculate like I do know, but could have a look at that HandlePointerEventL method to check whether there can be hooks or not. But as I said, Symbian is a black box, a rather black one at that, and edgelib probably another one.
René Brunner
Forum posts: 2009
Yes, it is intentionnally. SetContainerWindowL doesn't take a RWindow as parameter but a CCoeControl. Because a UI in Symbian is built on a tree of CCoeControl which ARE NOT RWindows (but may own one). Casting a RWindow to a CCoeControl is just a bad idea (there is no inheritance relationship between the two classes).
All your questions are actually not really related to the Symbian UI framework but how the Edgelib hides all this Symbian specific stuff. To create an Edwin, you need to have a father CCoeControl. This CCoeControl is constructed / initialized by EdgeLib (at least I assume so). And to be able to use and make your Edwin integrates into the environment, you will need to modify the CountComponentControl() and ComponentControl() of this father control. If you don't have access to them then no luck for you: you will have to drop edgelib or your edwin... (or write your own text input using edgelib primitives).
Eric Bustarret
NewLC Founder & CEO / Professional Symbian OS Consultant
Forum posts: 1248
I don't know exactly about the requirements at hand, but maybe you could use a small CEikDialog to query the text from the user. A CEikDialog is a little "world" in itself where an Edwin will feel right at home of course, and maybe the dialog will not care too much about the environment "below" it, i.e. the edgelib controlled view. (Maybe already a CQikSimpleDialog is much more finicky.)
René Brunner
Forum posts: 32
CEikDialog isn't an option for me, I need to use text input field on the existing gui. The thing is that we have something already using edge primitives and it feels like garbage... they don't feel normal, and now we need t9 input etc... So I was thinking it should be easier to use native controls.
Regarding RWindow and CCoeControl... I didnt' cast anything in my code as you can check. All I did is this: CCoeControl * cntrl = editor; Edwin inherits from CCoeControl and CCoeControl has SetContainerWindowL that takes RWindow. Only becase Edwin iherits indirectly from CCoeControl I can't call SetContainerWindowL(RWindow) on edwin itself.
The way I'd execute all that stuff is the following. All I need is access to screen and processing of events. So, if there' s a possibility to make a control draw to a window that has a virtual surface (a bitmap) so that I'd blit that bitmap myself later and I also can process text input events from edge and forward them to the text input control. In windows it's easy to do all that stuff, not sure how I could do that in symbian (if ti's at all possible to do that)
Forum posts: 1246
You should look more at CEikonEnv, that is the key to your success.
I think this should work:
Create the CEikEdwin as window owning (don't call setcontainerwindow!) and you should be able to get it to work by using CEikonEnv::AddDialogLikeControlToStack
Then use RemoveFromStack() when it shouldn't be visible.
make sure to position it on the screen so it looks like it is in the right place compared to everything else.
disclaimer:
This is from reading the manual though, havn't tested this exact functions myself.
But, anyhow, the key to your problem lies within CEikonEnv, the application framework.
It should be possible to somehow hook your ccoecontrol into that, and make it draw it ontop of your normal edgelib-view.
Forum posts: 1248
Interesting. Never heard about that one. Nice idea to make the Edwin window-owning.
But still, mtlgui obviously wants to get the thing running on UIQ3, and there you still have (at least) the hurdle about the whole command system, as mtlgui discovered already (a CEikEdwin with focus wants to insert functions like "Cut", "Select all" and so on into the current main menu, and there doesn't seem to be one on edgelib), and that problem alone can doom the whole thing.
mtlgui "admitted" that he or she has already something running based on edgelib primitives, so this seems to me to be mostly about admitting defeat and lower one's expectations of what's achieveable, rather than a real technical problem
René Brunner
Forum posts: 1246
I see... I havn't used edwin much.
But doesn't surprise me if it has a lot of weird dependencies you never notice in the normal app framework...
If the edgelib integration is using the Qik classes and not the eikon classes, its possible you could get it to work, by adding menues etc that it depends on...
If edgelib uses pure eikon, its less likely unfortunately
But on the plus side, its quite likely edgelib do use Qikon classes for UIQ, since thats usually the easiest to actually get to work reliably.
An easy-to-make but unfortunately false assumption is that *Eik* classes are the same on S60 and UIQ...
In reality there is lots of patches in the Eik classes to adapt them to Akn or Qik...
Well anyway, if it works, the entrypoint should still be CEikonEnv::Static().
Through that, you can get a pointer to your apps AppUI, and cast it to a CQikAppUi, and try use it, adding views and/or controls.
I don't know enough details of Qik to give much more specific help, but thats the approach I would try... create the control as a window/view of its own, and convince the app framework it should be displayed on top in the right position.
Should involve the least amount of code, and be the most compatible approach...
I'd allocate about a week to it, and couldn't guarantee it would actually work in the end
Forum posts: 1248
Indeed. Once I managed to confuse the FEP in UIQ2 with some surprising (and maybe not 100% rule-conforming) focus settings and view switches so that the virtual keyboard just refused to come up after a tap on its icon in the status bar. So even by staying within the framework you can run into trouble...
Anyway the UIQ3 FEP which seems to be more robust could nevertheless be unhappy somehow about a weird thing like a window-owning Edwin on top of a edgelib-controlled view - another potential show-stopper.
René Brunner
Forum posts: 32
Well, I absolutely don't need that buttons at the bottom!! What I need is that when i focus in a text edit box, I get possibility to use virtual keyboard (I use uiq3 P1i phone) and I won't be able to have the same stuff with edgelib... NEVER! That's why I wanted to have native control. And we already have something homegrown using edgelib primitives not because I admitted to failure to get it done, but because it was done at the beginning this way and now I need to modify this input box, fix some stuff... basically make it more like normal input box (and if it was native control, we'd never have these problems!!)
AddDialogLikeControlToStackL seems like a solution to this problem, but once again symbian shows that's it's complete garbage. I just can't construct edwin before I set container window. Probably Edwin ISN'T DialogLikeControl.... But which control is DialogLike then? I tried to search code examples and didn't find anything helpful.
I also asked this question at edgelib forums, hopefully they will be able to cooperate and provide some ideas on how to get it done.
Forum posts: 32
TO: alh
yes, it seems that simple stuff can take a week of work easily
For example there are apps that can float on top of all other apps (like screencapture) - I may do something similar at the end and it will work as expected! I use similar approach in wince - I draw a control on existing window from another process, that all had to be done because of ram limitation per process in wince5. It was way more complicated that simple text input, but it didn't take a week of work (cause it's Windows)
I'll think about creating a separate window and even possibly a separate process to handle that
Forum posts: 1246
Too bad about not being able to do it window owning...
Modified approach:
Create your own custom CCoeControl, which is window owning.
Set the window of your custom CCoeControl as container window on the edwin
make sure your custom control calls "Draw" and "OfferKeyEventL" on the edwin
Then use AddDialogLikeControlToStackL on your custom CCoeControl.