SVN Build bugs

Jekteir

22-03-2008 23:58:09

Heya,

Hope all's going well; I've been away from work on my project for quite a while, but I'm spending the rest of the month on it now. I just got the latest QuickGUI from SVN, but there are a few build bugs:


Compiling...

QuickGUINStateButton.cpp

quickguinstatebutton.cpp(60) : error C2680: 'QuickGUI::Border *' : invalid target type for dynamic_cast
'QuickGUI::Border' : class must be defined before using in a dynamic_cast
quickguinstatebutton.cpp(60) : error C2227: left of '->_notifyParentSkinComponent' must point to class/struct/union/generic type
quickguinstatebutton.cpp(81) : error C2680: 'QuickGUI::Border *' : invalid target type for dynamic_cast
'QuickGUI::Border' : class must be defined before using in a dynamic_cast
quickguinstatebutton.cpp(81) : error C2227: left of '->_notifyParentSkinComponent' must point to class/struct/union/generic type
quickguinstatebutton.cpp(102) : error C2680: 'QuickGUI::Border *' : invalid target type for dynamic_cast
'QuickGUI::Border' : class must be defined before using in a dynamic_cast
quickguinstatebutton.cpp(102) : error C2227: left of '->_notifyParentSkinComponent' must point to class/struct/union/generic type

QuickGUIProgressBar.cpp

quickguisheet.h(20) : error C2504: 'QuickGUI::Panel' : base class undefined

QuickGUIRadioButton.cpp

quickguipanel.h(42) : error C2504: 'QuickGUI::RadioButtonGroup' : base class undefined

QuickGUIRadioButtonGroup.cpp

quickguipanel.h(42) : error C2504: 'QuickGUI::RadioButtonGroup' : base class undefined

QuickGUIWindow.cpp

quickguisheet.h(20) : error C2504: 'QuickGUI::Panel' : base class undefined


Might the undefined base class messages be a symptom of some kind of headers/forward class declarations problem?

Was also (of course) wondering if there was going to be any movement on menus soon? I don't know what was entailed in the old menu system (and don't have the source for it any more) but since (AFAIK) it was basically an amalgam of lists and labels, am I right in thinking there wouldn't actually need to be much, or possibly any, low-level work done to get menus running again?

Finally: does any shutdown code need to performed for quickGUI when the object which has a pointer to QGUI's manager is deleted? I used to delete the quickGUI manager, but now the destructor is protected.

Thanks,

Jek

kungfoomasta

23-03-2008 00:22:13

Might the undefined base class messages be a symptom of some kind of headers/forward class declarations problem?

For classes like the Panel, Sheet, and Window, I can't use forward declarations, because the Window and Sheet inherit from Panel. I'm not familiar enough with Code Blocks (assuming you're using that) to know what the issue is with the code.

Menus are on the list, but I'm currently experimenting with a new rendering design and seeing if it works, and whether or not QuickGUI would benefit from it. Aside from this, my current focus is on the SkinSet Editor. The skinning system needs to be revamped to make it easier for people to skin themselves. You're right that menu's wouldn't take that much work.

does any shutdown code need to performed for quickGUI when the object which has a pointer to QGUI's manager is deleted? I used to delete the quickGUI manager, but now the destructor is protected.

Destroy QuickGUI::Root and it will clean up the managers for you.

Zini

23-03-2008 12:02:31

I haven't updated my working copy yet, but a quick glance at the code tells me, that you are missing an #include "QuickGUIBorder.h" somewhere (probably in QuickGUINStateButton.cpp). Maybe it's the precompile headers again, that are masking the bug. Did I mention, that I hate precompiled headers?

btw. the dynamic_cast at line 60 is mostly pointless. You should cast to a reference, not to a pointer (so if anything goes wrong an exception can be thrown instead of the program being terminated).

Jekteir

23-03-2008 18:20:51

Thanks for the info.

Actually I'm on VC++ 2005 now, so it isn't a C::B problem.

Could well be the precompiled headers though; I still don't really understand them and I haven't touched any precompilation settings. It basically wouldn't build 'out of the box'.

Still no idea about the cast at 60. It does sound like border isn't included (I was tired last night so I may not have spotted this -- I spent an hour or two before I got to the SVN source, trying to make the last release run!). I guess the code builds for you guys, though?

As for inheriting from panel, -- well, I'm guessing an include is missing or something again.

Rendering design: didn't you already redo the whole rendering design once? I thought the new way was the best (and set in stone)? I'm just anxious because I really need to have some moderately stable gui code that isn't going to keep breaking my project, and I'm starting to wonder if QuickGUI is a good idea, since I'm spending far more time plowing through QuickGUI issues than my own code, it seems. I know operating under Ogre is a goliath requirement in terms of keeping track with your options, but maybe it would be worth sketching out some kind of UML roadmap and holding to that as the 'stable base' of your project's direction? Even just things like widget constructors, which i) accepted names; then ii) you had to use setName(); then iii) setName is gone and names are in constructors again -- get very irksome!

Can I get a copy of the old QGUI menu code? Maybe I'll just stick that in my QuickGUI copy and try to fix whatever breaks under the new system.

Jek

kungfoomasta

24-03-2008 17:16:27

Apologies, I know it sucks to have so much redesign all the time. The main reason for this change is that it will make it easier to create custom widgets. Please give me 2 weeks, starting tonight I will start putting in a lot of effort into the library.

Jekteir

24-03-2008 18:54:12

Might the undefined base class messages be a symptom of some kind of headers/forward class declarations problem?

I'm looking at this again now and I'm pretty sure it's one of those subtle and annoying circular dependency problems. Something is including something else, which ends up including the first thing, only it can't, because it's already been defined... Probably a header include can be moved from another header to a source file to fix this. Somewhere. :P

quickguinstatebutton.cpp(60) : error C2680: 'QuickGUI::Border *' : invalid target type for dynamic_cast
'QuickGUI::Border' : class must be defined before using in a dynamic_cast


I stuck #include "QuickGUIBorder.h" in the top of QuickGUINStateButton.cpp and this error went away.

Apologies, I know it sucks to have so much redesign all the time. The main reason for this change is that it will make it easier to create custom widgets. Please give me 2 weeks, starting tonight I will start putting in a lot of effort into the library.

Thanks for that; your new rendering batching sounds good; no arguments there. I just hope it's the final version :P I'm doing a lot of C++ work until the 10th because I have an internship interview then, so I'd like to spend some time working on my own code and getting back into the swing of things before then :P Hopefully I'll get QuickGUI building, it'll roughly work, and then I can return to trying to clean up my (many) own messes :)

Jek

Jekteir

24-03-2008 19:14:17

OK, I fixed this problem. It was in QuickGUIRadioButtonGroup.h:

#include "QuickGUIRadioButton.h"
//#include "QuickGUIManager.h"


QuickGUIManager, through a labyrinth of includes, ends up including Panel.h, which is bad when panel.h wants to include QuickGUIRadioButtonGroup.h.

So, you might want to do this in the SVN too :) My copy builds, now.

Jek

kungfoomasta

24-03-2008 20:18:32

Yah, circular dependencies do get annoying. I used to try to avoid them, but I find there are a lot of instances where it is really necessary. (GUIManager uses Sheets, and Sheets use GUIManager, etc.)

Glad you found the issue, I will add those includes in and commit them so others won't have problems like these.

I just hope it's the final version

Definately agree. It will be the last major update of the rendering process.

kungfoomasta

08-04-2008 21:51:03

Well its been 2 weeks and I didn't make that estimate. There is actually a lot of work that needs to be done before I can put out anything usable. I'm making awesome progress, and mainly just wanted to say I'm aware my deadline won't be met. :P (and yes, I'm being very cloudy on what exactly I've been doing.. :twisted: )

Jekteir

08-04-2008 22:24:40

Ha, OK. Well, I have a games internship interview in the next couple of days, so i'm freaking out on my own whole new level ;p

Jek

Jekteir

11-05-2008 01:31:33

Hey, just wanted to remind you about these problems. I got the latest from SVN today and the circular dependency issues (and lack of border.h include in nstatebutton) were still there, so I had to go through and patch it up again.

J

Jekteir

11-05-2008 02:27:13

Oh, and there's a line in SkinSet::SkinSet(const std::string& skinName, ImageType t, const std::string &resourceGroup) I was unsure about:

i.load(mTextureName,Ogre::ResourceGroupManager::DEFAULT_RESOURCE_GROUP_NAME);

That seems to always load from the default group instead of the one the user specified in the call. Should it be:

i.load(mTextureName,resourceGroup);

?

Jek

kungfoomasta

12-05-2008 17:24:19

The image is only used internally and I store a reference to it, so it doesn't really matter what resource group it is a part of. I could change it to the passed in resource group for consistency, but it doesn't have any effect on the transparency checking its used for.

The Skin system will be upgraded for the next version. I'm currently working on the ToolBar/Menu Widgets so I can create the SkinSet Editor.