more crashes...

[Falk Brettschneider]

Hi,

Roland Krause wrote:

> Falk,
> another couple of crashes, this time I send a patch for
> ckdevelop_noslot.cpp.
>
> Same situation as before, start w/ an empty project, hit Save All or
> Save As. Bingo! Though no crash handler (or whats that cure little
> dragon called again?).

Until today I haven't care about both slots. Other things were more
important. For instance I replaced about 500 places where either cpp_widget
or header_widget has been by the appropriate thingy of the DocViewMan... The
architecture changed a bit but at many places.
I think I will have a look at the save slots this day or tomorrow.

>
> What is blind_widget good for anyway? This all looks like a pretty evil
> hack to me ;-)

Seems so. KWriteDoc should do the job of saving.


>
> In class DocViewMan you have docCount() and countDocs() do you need
> them both?

Oops! No. Seems I lost survey in an exessive night. ;-)



> In docviewman.cpp line 535:
>
>   if (pView->inherits("CEditWidget"))
>     m_pCurEditView = (CEditWidget*) pView;
>   else
>     m_pCurBrowserView = (KHTMLView*) pView;
>
> how does this work? How can a QWidget inherit from CEditWidget?

This is the usual way to test a class for inheritance. I ask whether pView
inherits from CEditWidget or not. Since there are only 2 possibilities, the
other class must be that KHTMLView.
See the Qt docu (QObject) for details... Using QObject::inherits is better
than using dynamic cast checks.


>
>     (m_docViewManager->currentEditView()->getName()).fileName()
>
> doesnt that lead to very instable code?

m_docViewManager is always existing. Otherwise KDevelop crashes on startup,
already.
If currentView() is valid, depends on if a document is open. But some slots
are only reached as result of interaction with such a view of a document. I
suppose you found that line in such a slot. So we can take for granted that
there's a current view. And every view has always got a filename or name,
default is "".
So 3 extra pointer checks are quite useless here. We know the validity of
architecture here and avoid to code overhead.

> I mean, we do have no exception
> handling at all in place in case one of the returned pointers is 0, do
> we?

I won't check a pointer for 0L in every case. As said some functions are
never reached if the objects don't exist.

> Please dont take my questions as personal critique of your coding
> style.

No. It's OK. For instance you've found the doc count twins. ;-)

> Regards
> Roland
>

Cheers,
F at lk



_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com


-
to unsubscribe from this list send an email to kdevelop-devel-request at kdevelop.org with the following body:
unsubscribe »your-email-address«