Derive from CCoeControl, implement HandlePointerEventL
| Sun, 2008-06-15 23:34 | |
|
(I'm gonna try with just giving some basic info, if it becomes obvious that that isn't enough, I will add my own code) I have an appview that derives from CQikViewBase, and in that .cpp-file (hkpaintappview.cpp) I would like to use a class that derives from CCoeControl which also implements HandlePointerEventL, so every class can take care of handling pointer events themselves, which makes coding easier and also cleans up the code. I have checked some sample code from sony ericssons developer website, and I have mimicked the code I have found in Square.h and Square.cpp (class CSquare) in SE:s example MineSweep (http://developer.sonyericsson.com/site/global/techsupport/tipstrickscode/symbian/p_boardgame_uiq3.jsp). But when I make my own class that way, and only import it in my view class through the views header file (Classname class;), it doesn't work (and the compiler complains about an unused variable, obviously). Do I need to derive my View-class only from CCoeControl instead of CQikViewBase, or do I need to do anything more with the class variable created in the header file, for example, call its constructor? |
|






Forum posts: 1242
I tried to understand your problem and your question, but failed.
I think it would be indeed very helpful if you post some code and header fragments to illustrate. And that new control of yours that you want to derive for CCoeControl or whatever, do you want to place it onto your view, or is the view class itself somehow your problem?
René Brunner
Forum posts: 7
Yeah sorry, I think I was a bit too tired..
pen.h:
#ifndef PEN_H
#define PEN_H
// pen.h
#include <coecntrl.h>
class CHKPaintView;
class Pen : public CCoeControl
{
public:
~Pen();
Pen();
TInt penSize;
void HandlePointerEventL(const TPointerEvent& aPointerEvent);
protected:
private:
};
#endif
pen.cpp:
#include <pen.h>
#include <eikenv.h>
#include <hkpaintview.h>
#include <w32std.h>
void Pen::HandlePointerEventL(const TPointerEvent& aPointerEvent)
{
//CCoeControl::HandlePointerEventL(aPointerEvent); maybe?
iEikonEnv->InfoMsg(_L("works?")); //easy way to check if it works.
}
hkpaintview.h
#ifndef HKPAINTVIEW_H
#define HKPAINTVIEW_H
#include <qikviewbase.h>
#include <pen.h>
#include <coeccntx.h>
#include <eiklabel.h>
#include <qikmenupopout.h>
#include <qikcolorselector.h>
class CHKPaintAppUi;
class CQikSlider;
class CHKPaintView : public CQikViewBase
{
public:
static CHKPaintView* NewLC(CQikAppUi& aAppUi);
~CHKPaintView();
Pen * pen;
private:
CHKPaintView(CQikAppUi& aAppUi);
void ConstructL();
void Draw(const TRect & aRect) const;
void HandlePointerEventL(const TPointerEvent& aPointerEvent);
void HandleControlEventL(CCoeControl* aControl, TCoeEvent aEventType);
*snip!*
And in hkpaintview.cpp, I neither include pen.h nor use the initialized pen from hkpaintview.h (Pen * pen;), do I need to use the variable pen in hkpaintview.cpp in order for the Pen::HandlePointerEventL function to run in pen.cpp?
Forum posts: 1242
I think we have a misunderstanding somewhere here big enough that you can drive a truck through, but I don't know yet where it is
The only way that would make sense to me is to treat you new, custom control "Pen" like you would any other standard control that you create dynamically (instead of going the resource way) and put on your view.
Means: What do you do if you want to put, say, a CEikEdwin on your view? Well, declare a member variable in your view's .h file for it, and in your view's .cpp create/instantiate the CEikEdwin, give it a size, a position, maybe a few more things, and then make the view to be the father of the CEikEdwin, e.g. by using the old-fashioned SetContainerWindow() method or the newer, modern AddControlLC() method of the view.
Now, what about your Pen? Well, exactly the same. Member variable in .h, new(ELeave) Pen() in your .cpp, and so on.
There is no other way that you will ever get your Pen::HandlePointerEventL code to execute than to create a Pen control and put it on the view so that the UI framework will know it and give it some pointer events to handle, depending on its size and position.
René Brunner
Forum posts: 7
Ok, I think I understand. But the thing is, the Pen class wont be visible at all, do I still need to do as you told me now? It will be a pen tool for a drawing program, and it would be nice if it could take care of the pointer events on it's own, at least so I thought.
Forum posts: 1242
Trouble is, if it's not visible, it won't have any pointer events on its own...
I think maybe you don't need a control i.e. a class derived from CCoeControl, but only a nice place to put some code. If you are indeed programming something like a paint program, you will probably have just the view as a control where the user can draw, and probably a bitmap where you "draw" in parallel, to be able to handle redraws.
In this scenario, I don't see the pen as a control, not even an invisible one, but just a certain amount of code that handles drawing as if by a pen. You could make this code into a normal class, derived directly from CBase. This class has then a method to handle pointer events that you will call in your view's HandleProinterEventL method. If your program is simple and cannot have more than one pen that the user can freely configure and switch, but only one current pen, you also need just a single objekt of this class "Pen".
René Brunner
Forum posts: 7
Hmm yeah, the pen class could just have a method that takes TPointerEvent as a parameter, that I send from the view class' HandlePointerEventL?
Forum posts: 1242
Yes, that's exactly what I had in mind.
René Brunner
Forum posts: 7
Thank you very much, I don't really know why I didn't think of that.. Well, thanks anyway!