Developer forums (C::B DEVELOPMENT STRICTLY!) > Development

Proposed rule "Do not include wx/wx.h inside the Code::Blocks SDK headers."

<< < (3/5) > >>

killerbot:
wait wait, the include should not be needed in Manager.h --> no knowledge is needed there, the forward declaration is sufficient.
I am gonna try out first the window pointer.

killerbot:
most can do with the wxWindow*, 5 places need a frame* --> added method GetAppFrame()

thomas:
I don't understand why this is necessary. wxFrame derives from wxWindow, so if I get a wxWindow*, I can use it as wxFrame*.
Why do we need an extra function to "down"-cast the pointer? Personally, I don't think we should replace things that work correctly with less flexible alternatives if there is no urgent reason (maybe I just don't see the reason?).

The wx.h header inclusion has little impact, since the header guards will already be defined due to precompiled headers, but it is certainly true that we can avoid loading the file in the first place, good idea.

killerbot:
@Tim : could you update to rev 4381 and adjust your patch to that one, I think it will shrink a lot ;-)

Note : I build on windows (pch) and linux (non pch).
EDIT: linux : not ok for th moment, problem with wxsradiobox.cpp, it seems that wxUSE_RADIOBOX is not defined, so the include of wx/radiobox.h doesn't seem to bring a lot [autotools build !! dunno how to fix that for the moment]

I will then further address your patch (in case some things are still left in there, I guess there will ;-) )

@Thomas : I agree and disagree, GetAppWindow() now returns a wxWindow*, which you can cast to a wxFrame*, but that because actually you know it is a frame, but there's no guarantee,  therefor I made an explicit function, which you can trust ;-)

EDIT2 : adjust 1 more file of wxSmith (and committed) , and on my own system currently I have modified 2 files (wxsradiobox.cpp and wxschecklistbox.cpp : I have them include for *now* wx/wx/.h) but with a solution I don't like. But currebtly i can further test, since rev 4382 broke my entire linux build [../../src/include/logger.h:4:25: error: calling fdopen: Bad file descriptor]

thomas:
Yes, but before, it returned a wxFrame* so it was safe to assume it is a wxFrame, or you could use it as wxWindow* if you wanted to do that. I just don't see how it is better now  8)

Don't get me wrong... I mean, it's all nice and good, just it doesn't seem to be much better, but it possibly invalidates quite a bit of code.

From the past, I remember having wxWidgets 2.6/2.8 issues with wxWindow/wxFrame, relating to the window placement code. They moved one member function (forgot which one) from wxFrameto wxWindow between releases, and this was just the one that I had used. So possibly this breaks for 2.6 now again (have not tested). True, we officially support 2.8 now, but that doesn't mean that it *must* break for 2.6  :D

Ah, writing this, I see you have already edited about 35 depending sources to reflect the changes...  so forget anything I said 8)

Navigation

[0] Message Index

[#] Next page

[*] Previous page