List::destroyItem problem

Hello,

i have a problem with the list widget. The destroyItem() method doesn't remove the item as it should. I managed to remove the problem using the following changes (diff file):


--- C:\Users\Jörg\Desktop\QuickGUIList.cpp So Dez 21 18:01:08 2008
+++ D:\Source\eCore\Src\QuickGUI\src\QuickGUIList.cpp So Jan 11 19:46:19 2009
@@ -220,15 +220,29 @@
int count = 0;
for(std::list<ListItem*>::iterator it = mListItems.begin(); it != mListItems.end(); ++it)
{
- if(count == index)
+ if(count++ == index)
{
- OGRE_DELETE_T((*it),ListItem,Ogre::MEMCATEGORY_GENERAL);
- mListItems.erase(it);
+ std::vector<QuickGUI::Widget *>::iterator itChild = std::find(mChildren.begin(), mChildren.end(), *it);
+ if(itChild != mChildren.end()) {
+ this->removeChild(*itChild);
+ mListItems.erase(it);
+
+ // Set all positions of ListItems.
+ float y = 0;
+ for(std::list<ListItem*>::iterator it = mListItems.begin(); it != mListItems.end(); ++it)
+ {
+ (*it)->setPosition(Point(0,y));
+
+ y += mDesc->list_listItemHeight;
+ }
+ }
+ break;
}
}

// Update names and Indices
updateItemNamesAndIndices();
+ redraw();
}

bool List::fireListEvent(ListEvent e, EventArgs& args)


I am not 100% sure that the changes contain all steps needed to completly remove the list items. My QuickGui knowledge isn't that broad

I have never worked with diff files before. I hope it is usable

Letschki, thanks for the fix and report, I've fixed this in the code base. I will mostly likely make another release this month, with some new widgets to add to the collection. If you have any particular requests, I may be able to add them in. (assuming they're small and easy to add in)

Now that you ask I have two suggestions (questions). But perhaps there are ways to achieve my goals with the current version

1. It would be nice if there were an easy way to find the child controls of component controls. For example i needed something like the following code in the QuickGUI::Console class:

/**
* Returns the TextBox widget that receives the inputs of the console widget.
*
* @return Pointer to the TextBox input widget of the console widget
*/
TextBox * getInputBox() const;
/**
* Returns the TextArea widget that holds the console's history text of the console widget.
*
* @return Pointer to the TextArea widget of the console widget
*/
TextArea * getDisplayArea() const;

I tried to use findWidget() but there is no 'naming scheme' that i could use to find the "right" child widgets. Additionally this would keep the console class interface for the real console specific methods. The other way would be to include all public methods of the child controls

2. I need a way to set the input focus to a widget that is able to receive keyboard input. For example i wish to set (or remove) the input focus to a console widget once it is visible.

I hope this makes sense and doesn't break the design

I really enjoy using QuickGUI. Again, thanks in advance.

I haven't had a lot of user input regarding Component Widget's and getting access to their Components, but I see your point of view. The reason I don't give public access is to prevent mis-use of Components. For example, if somebody got access to a ScrollBar's scroll buttons, they could add text to it, or resize it, and undefined behavior may result. (Imagine a user grabbing the InputBox and resizing it, moving it, and making it dragable, etc. it would totally break functionality.) I'm more than willing to support your intended use for the InputBox. Since its a new widget, I haven't really made use of it in my own projects, so the interface and what is possible may not be what I would like. If you can elaborate more on what you want to accomplish with the InputBox I can try to open up more access by wrapping it.

For 2, this is definately possible, I think the API is:

Sheet::setKeyboardListener(Widget* w);

I have to double check this, but I believe I make the check that the passed in widget must be a keyboard listener, which is referring to the property

widget_consumeKeyboardInput

I don't have the code on hand, the actual property name might be different. You can set this value before creation of the widget, or after, using an API from the Widget class.

Also note that NULL is a valid parameter to setKeyboardListener, and that only the currently set keyboardListener receives key input and char input.

I should probably add this to the wiki.

I understand your concerns about the direct access to child widgets. As i said i think that nearly all public methods of the component controls are needed, because if they are needed in the standalone textbox widget sooner or later they are needed in the component widget.

For example i have tried the Sheet::setKeyboardListener() method and it worked perfectly (thanks ), but only if i pass the inputbox (textbox) widget of the console widget. Additionaly i had the problem to access the current content of the text box in the console input event handler (no Console::getText() method).

I think your absolutly right to hide 'values' (widgets) that are better left untouched. As long as the most get-methods are available to get needed informations. If more control is needed one can always derieve from the specific widget class.

During my last post I made the connection between your 1 and 2 points. I will review the Console widget and add more 'get' functions, and also create a function to set the keyboard input to the InputBox, something I forgot to do.

- direct keyboard input to InputBox
- getInputBoxText
- getInputBoxTextSegments
- Check to make sure InputBox default Font and Color can be set

I believe I did add a bunch of methods to add Text into the InputBox, but if not I will add them in. The goal in my mind is to be able to allow simple use of the Console similar to DOS prompt, but also allow advanced use such as coloring of commands and chat/messenger-like functionality, where username is prepended to displayed text, and multiple fonts are supported.