OutputView item fails at runtime

> Remove the need for a outputview interface library,
> IOutputViewItem is now just an interface.

I saw the commit. It compiles but didn't work because
dynamic_cast
return 0

The problem is these codes in OutputWidget::slotActivated()

QStandardItem *stditem = stdmodel->itemFromIndex( index
);
IOutputViewItem *outitem =
dynamic_cast<IOutputViewItem*>( stditem );
if( outitem )
    outitem->activated();

The activated item inherited QStdItem and IOutputViewItem.
stditem was
not zero. But dynamic_cast<IOutputViewItem> returns
zero because
IOutputViewItem is NOT child or parent of QStdItem.
So we can't rely on dynamic_cast anymore.

One solution is to reimplement QStdItem::type() in each
item.
Maybe we should allocate some unique #define for
outputviewitem
And every items who want special treatment should return
that unique #define via int type().
Only after OutputView calls type(), we can just do simple
C-style cast,
depending on the type() result.

Any idea?

_______________________________________________
KDevelop-devel mailing list
KDevelop-develkdevelop.org
https://barney.cs.uni-potsdam.de/mailman/listinf
o/kdevelop-devel

On 20.05.07 14:22:12, dukju ahn wrote:
> > Remove the need for a outputview interface
library,
> > IOutputViewItem is now just an interface.
> 
> I saw the commit. It compiles but didn't work because
dynamic_cast
> return 0
> 
> The problem is these codes in
OutputWidget::slotActivated()
> 
> QStandardItem *stditem = stdmodel->itemFromIndex(
index );
> IOutputViewItem *outitem =
dynamic_cast<IOutputViewItem*>( stditem );
> if( outitem )
>     outitem->activated();
> 
> The activated item inherited QStdItem and
IOutputViewItem. stditem was
> not zero. But dynamic_cast<IOutputViewItem>
returns zero because
> IOutputViewItem is NOT child or parent of QStdItem.
> So we can't rely on dynamic_cast anymore.

Well, a static_cast would work, but I'd rather not do that
and instead
use a real class (subclasses from QStdItem) and a lib, so
please revert
and remove the default implementation.

One thing I'm wondering: Do we really need the factory in
each
plugin? I'm thinking about having a template-class instead,
as far as I
can see that should work.

> One solution is to reimplement QStdItem::type() in each
item.
> Maybe we should allocate some unique #define for
outputviewitem

See above plus, as I already said before: We don't want
defines for such
types or int-return-types. We want enum's as they provide
type safety.

> Only after OutputView calls type(), we can just do
simple C-style cast,
> depending on the type() result.

No, C-style casts are absolutely the wrong thing, if
anything we would
use a static_cast, but C++ doesn't need C-style casts.

Andreas

-- 
A day for firm decisions!!!!!  Or is it?

_______________________________________________
KDevelop-devel mailing list
KDevelop-develkdevelop.org
https://barney.cs.uni-potsdam.de/mailman/listinf
o/kdevelop-devel

2007/5/20, Andreas Pakulat <apakugmx.de>:
> On 20.05.07 14:22:12, dukju ahn wrote:
> > > Remove the need for a outputview interface
library,
> > > IOutputViewItem is now just an interface.
> >
> > I saw the commit. It compiles but didn't work
because dynamic_cast
> > return 0
> >
> > The problem is these codes in
OutputWidget::slotActivated()
> >
> > QStandardItem *stditem =
stdmodel->itemFromIndex( index );
> > IOutputViewItem *outitem =
dynamic_cast<IOutputViewItem*>( stditem );
> > if( outitem )
> >     outitem->activated();
> >
> > The activated item inherited QStdItem and
IOutputViewItem. stditem was
> > not zero. But dynamic_cast<IOutputViewItem>
returns zero because
> > IOutputViewItem is NOT child or parent of
QStdItem.
> > So we can't rely on dynamic_cast anymore.
>
> Well, a static_cast would work, but I'd rather not do
that and instead
> use a real class (subclasses from QStdItem) and a lib,
so please revert
> and remove the default implementation.

Ok. But now is very late night here and this weekdays seems
to
be busy :( . I'll revert at friday.

> One thing I'm wondering: Do we really need the factory
in each
> plugin? I'm thinking about having a template-class
instead, as far as I
> can see that should work.

Anything would be ok if it is better. The bottom line is
that each plugin
provides some "output-filtering or parsing"
functionality to outputview.
Within bottom line everything could be good.

> > One solution is to reimplement QStdItem::type() in
each item.
> > Maybe we should allocate some unique #define for
outputviewitem
>
> See above plus, as I already said before: We don't want
defines for such
> types or int-return-types. We want enum's as they
provide type safety.

If we have a lib, I don't like #define too.

_______________________________________________
KDevelop-devel mailing list
KDevelop-develkdevelop.org
https://barney.cs.uni-potsdam.de/mailman/listinf
o/kdevelop-devel