Tab Controller: More checking need to be done

[Chryso]

Hi,

When you try to add twice the same tab, CEGUI gives out an error. Could you just make it return a null value instead ? (easier than a try/catch block)

When you try to get the content of a tab that is not present, CEGUI gives out an error. Could you just make it return a null value instead ?

And I haven't yet been able to test it, but i guess it might be the same for the remove tab.

Note: The objectives is to actually know if a tab controller actually already has a tab containing the window. Like isATab(windowName) which would give out a true / false value

Regards,

PS: getChildAtIdx also needs some error checkings regarding boundaries
PPS: How do I check if a tab already contains a window ? I tried looking at the childs, but no luck.

[Jamarr]

When you try to add twice the same tab, CEGUI gives out an error. Could you just make it return a null value instead ? (easier than a try/catch block)

How does 'null' tell you why addTab() failed? It doesn't. The method 'addTAb()' is very explicit - you are telling the tab control to add a new tab, and clients expect that to happen unless something 'exceptional' happens. Really, I think it should add the tab anyway and just make you look dumb for adding the same tab twice.

When you try to get the content of a tab that is not present, CEGUI gives out an error. Could you just make it return a null value instead ?

Same thing. You are explicitely requesting the content of a tab. Clients expect this content to be available unless something 'exceptional' is preventing that access; in this case, that being the tab doesn't even exist. 'null' does not tell you why you cannot access the tab.

Why you are even trying to access a tab that may or may not exist sounds like you have some design issues you need to resolve...

Note: The objectives is to actually know if a tab controller actually already has a tab containing the window. Like isATab(windowName) which would give out a true / false value

There are probably numerous ways to do this; like maybe isChild()? or getTabPane()->isChild()? or recursiveChildSearch()? or...try looking over the API.

[CrazyEddie]

Hi,

Hi,

Most of this was written while Jamarr was also posting, and I didn't go back and revise it, so forgive any repetition

When you try to add twice the same tab, CEGUI gives out an error. Could you just make it return a null value instead ? (easier than a try/catch block)

No.

When you try to get the content of a tab that is not present, CEGUI gives out an error. Could you just make it return a null value instead ?

No.

]And I haven't yet been able to test it, but i guess it might be the same for the remove tab.

No! (Should 'fail' silently).

Note: The objectives is to actually know if a tab controller actually already has a tab containing the window. Like isATab(windowName) which would give out a true / false value

Depending upon the CEGUI version, there are ways of doing this already, for example by using the Window::isChild or Window::isChildRecursive functions.

PS: getChildAtIdx also needs some error checkings regarding boundaries

No. The API reference clearly states that this is not bounds checked.

To elaborate on those earlier "No"'s; First of all, exceptions are not errors per se, but exceptional conditions that ideally should not happen (yes, the distinction is subtle, but it's there). The the library is written in C++ and not C and we use exceptions and not return value checking - this will never, ever change while I am around (having said this, there is a pending RFE to effectively remove all exception usage, though it will not use return codes / values instead. The use of that particular feature will be highly unstable, it will be provided for those who really wanted it, but otherwise the feature will be unsupported). The concept of our exception usage is that you can assume that if the function returns you have a successful result; related to this I am already moving towards changing many public interfaces that currently operate with pointers to use references instead - this is again to reinforce the underlying ideals of the designer (that would be me ).

CE.

[Chryso]

Hi,

Okay, no problem with the NOs since I now know why i want the exceptions to happen.

As to answer the question about the adding twice the same tab. The stupid thing is as follow:

I have 1 tab controller, one of the tab is used for debugging purposes, so I want to hide / show the tab depending on an option somewhere else.

So first I add the window to the tab controller, works fine. However I then want to actually know in which state is the window (added or not to the tab controller) so that when the option is unchecked it removes the window from the tab controller and I wanted to see if the window could actually be removed or added before actually doing the add or remove.

Thus I embarked on a journey to make my method to actually check if the window was contained in the TabController. And that is where I actually started getting problems because when I try to do: TC:getChildrenAtIdx(i) and go through all of them I never find my window even if it is actually added. Which is very frustrating. And this is why i posted all the stuff above ^^

As for isChild() and isRecursiveChild() I do not know if I can actually access them at the moment, though I can make the request to be allowed to.

Anyway, I think I found a solution to my problem while writing this post... actually look at the parent of my window and see if said parent is the tab controller! Instead of trying to see if the window is actually the child of the tab controller

Oh, and one last thing I forgot to mention I guess... is that I am accessing CEGUI from LUA... not directly. (and thus I am very restricted regarding the API available to me)

Thanks for the information and keep up the good work

Regards!

Info:
This is what I tried for example

Code: Select all

   if ( CPT_CAS_DebugTabWindow:getParent() == CPT_CA_TabHolder ) then
      CPT_CA.RemoveTab(CPT_CAS_DebugTabWindow);
   else
      CPT_CA.AddTab(CPT_CAS_DebugTabWindow);
   end


And CPT_CA.AddTab and RemoveTab are:

Code: Select all

-- ===============================================
function CPT_CA.AddTab(tabWindow) -- need to work on how to put the tab in the correct order
   CPT_CA_TabHolder:addTab(tabWindow);
   -- TODO: Put TAB in specific order
end

-- ===============================================
function CPT_CA.RemoveTab(tabWindow) -- this is used to remove tabs from the tab holder mainly used when switching from no alliance to alliance and the reverse
   CPT_CA_TabHolder:removeTab(tabWindow:getID());
end


[Chryso]

Ok, got a function working that actually recursively checks the child and is able to tell me if the tab controller actually has the window as a child or not.

If I try to remove a tab through the window ID it does not work, it works if i try with the window NAME however.

Bug due to LUA which does not handle overloads...

Anyway, thanks a lot for the info ^^

Regards!

[CrazyEddie]

Are you using our lua binding, or something made externally? I ask because of your comments about restricted API and overloaded functions - our own binding is pretty comprehensive and does correctly offer access to all the overloaded functions.

Anyway, I think some of the issues are due to the fact the added content pane windows are not added as direct children of the TabControl, rather they are added as children to an internal TabPane 'helper' (Jamarr touched on this in his reply).

CE.

[Chryso]

I do not know if they are using your lua binding system but I believe that they did it themselves somehow because overloading ain't working

Thanks for the info and sorry for the trouble