List not dispatching event when selected index changes

Is there a reason why the List widget doesn't dispatch eventListChangePosition events when the selected index changes in a lot of places? It seems like a bug to me and it's making it a lot harder to work with since it doesn't actually let you know that it changed in a lot of cases so I'm having to manually dispatch the event myself. I also have a version of the List code that has all of the event being dispatched at the proper times but I'm not sure what the procedure is for committing code. Do I need to post the patch somewhere? Please let me know, thanks

P.S. I'm also using the current release code, not the current subversion code, which is why it's a List and not ListBox but I can easily port the patch to the current revision if that would be better.

Could you explain which cases are not handled? Also what version of MyGUI do you use.

If you want to submit your changes - try with code from svn and create patch for last revision, if bug still exist there. Then I'll apply your patch if everything is fine in it.

It would probably be easier just for you to look at the patch. I've uploaded it to my mediafire account and you can get it here. This patch is against the latest version of the code in SVN as of yesterday evening.

Patch is good and I'll definitely apply it, but could you check other cases where selected index changes. Most obvious that you missed is ListBox::insertItemAt

Ah I see. I was just searching for mIndexSelect = and forgot to check for ++ and -- cases. I'll take a look right now. I also made a mistake in the removeItemAt() changes. It should read

// If there is anything selected when something gets removed, whether or not the index actually changes, there has
// to be an event dispatched since the index may not change but the selected data does if it's less than the current value.
bool dispatchEvent = mIndexSelect != ITEM_NONE && _index <= mIndexSelect;


Hopefully you haven't committed it yet. I'll upload a new patch once I take another look for the other cases.

EDIT: New patch has been uploaded to the same URL as the first one. The only other change I could find was insertItemAt() like you mentioned.

Did this ever get committed to the repository? Haven't heard anything in a long time.

With your changes in some cases two events dispatched, so it require a bit more work. Also we need to change other widgets in the same way to keep things consistent.

Ah, I guess I didn't quite test it enough. Thanks for letting me know.

I hate to double post but I have to ask; Can you explain what the cases are when it dispatches more events than it needs? I'd like to fix the issues for at least a local commit since we really need this working for our project.

We discussed index changes event not being dispatched with another MyGUI developer and we decided, that this won't be changed.
We only send events about user activity, not about actions, that developer made.
Dispatching such events will cause problems, because you won't be able to determine if your action or user action caused this and if you do some list related actions inside this event you will fall into recursion.
You can't, for example, add event that change list itself:
let's say you need to add list item whenever user select one, then when you add item list will dispatch another event (with proposed changes) and you'll get another event that will cause another and so on.

From the other hand you always know when you change list through code and you can manually call your event handler if you need that. You can use getIndexSelected() method to get current (already changed) selected item.