CEGUI (Crazy Eddie's GUI) Forums

So I got this code:



In a nutshell, it takes the currently selected tab and removes it from tabControl, hides the grid corresponding to the tab, then deletes the 2 instances of the grid and tab in the array for more to be put in.

The problem in this code is the last part of it where it is suppose to find out which tab is activated AFTER the selected tab has been deleted. When it calles the getActiveChild()->getID(), it gives me this error:

First-chance exception at 0x005b25e6 (CEGUIBase_d.dll) in PCTGUI.exe: 0xC0000005: Access violation reading location 0x000000dc.

I have nothing in the CEGUI log that's helpful. I thought it was because CEGUI didn't specify the activeChild after the deletion of the last one, but I looked at the code and it is suppose to do so...

I know this must take time to go into and all, but if I just find out what's the algorithm behind the activechil selection, I could code around it so it doesn't have to call the getActiveChild() function and give me this error.

You'd probably be better off using the TabControl methods to access the 'active' page, as opposed the the low-level Window stuff - which in this case may return a Window other than the container window for a content pane.

Use: TabControl::getSelectedTabIndex to get the index of the active tab, and then TabControl::getTabContentsAtIndex to get the content of that tab.

*sigh*

I must be bug prone or something cause it keeps crapping out on me.

What you said helped me for the bit of code that was erronous before, but it just made other errors.

I think there is something very flawed with the tabControl which you should look into. More specifically, the addTab and removeTab function. All my tabs are added with the addTab function since all the tabs can be added at runtime. It can also be removed at runtime with the removeTab function. One little problem though is this:



Nothing complicated, it just takes the ID of the currently selected tab to be removed right?

Well, this is the exception thrown at me:

18/08/2005 14:19:27 (Error) Exception: Window::getChild - The Window with ID: '1' is not attached to Window 'SADTabControl__auto_TabPane__'.

Now, I know the tab has been added to the tabControl cause I can see it, click on it and it even shoots off events. The reason I never used addChildWindow function to add tabs in the tab control is after the first was added (during runtime, which worked fine), the second that was trying to get added would throw and exception which I though addTab would fix, which it did, but now has this problem...

I'm jinxed, stay away from me...

I just tried using removeChildWindow. It works, but the tab still stays there and of course returns and error when trying to click on the tab...this is too confusing...

The method getSelectedTabIndex() returns an index and not an ID, which is likely the root of this latest issue. So you'll probably end up adding some extra calls to obtain the content via it's index (using getTabContentsAtIndex() ), and then getting the ID from there.

The TabControl was contributed by Sinbad who created it specifically for a project he was working on. There are areas that could use improvement, as is the case with any of the widgets, though if this had not been contributed the system would likely not have a tab control at all, so we should be grateful for such contributions and be prepared to contibute further work to improve them as required - that's the whole point of this being open source, not so that I can sit here and do it all myself

Gotcha. Well, I guess i'm going to have to do changes in that widget then. If i get everything working, I'll be sure to post the patch. Is there a specific patch template/protocol or something I should use or just post the code?

Patches should be in the form of a unified 'diff' as produced by using the command:

- or -

within the cegui_mk2 directory.

So, you basically redirect the output of one of these commands to a file and submit the file on the patch tracker along with a description of what it's supposed to do, and any other relevant information.

Anything other than diffs are of little or no use since it's too easy for other recent changes to get lost or reversed. We really need the 'unified' format since these are much more useful to see what's going on and enables us to apply them even when the target files have significantly changed.

I am having the same issue with the removeTab. Neither the remove by name or the remove by window id appear to work. If I destroy the window, the tab remains and then all hell breaks loose when you select that tab.

CrazyEddie wrote:
The method getSelectedTabIndex() returns an index and not an ID, which is likely the root of this latest issue. So you'll probably end up adding some extra calls to obtain the content via it's index (using getTabContentsAtIndex() ), and then getting the ID from there.

I tried this, but it still doesn't work. It always removes the FIRST tab.

CrazyEddie wrote:
The TabControl was contributed by Sinbad who created it specifically for a project he was working on.

*phew*. Now we know who to blame... I am going to email Sinbad and find out when he is going to fix it.

OK, I got it to work..

What wasn't apparent to me until I look at the TabControl source code is that when you attempt to removeTab by using the NAME, you must use the DefaultWindow window name.

that is:



and remove it by doing something like:



This works.