Welcome Guest ( Log In | Register )

> foobar2000 Tech Support Forum Rules

Please read foobar2000 Tech Support Forum Rules before posting and comply with all the points.
Failure to provide all the information pointed out in the above document in your post is considered wasting other people's time and in extreme cases will lead to your topic getting locked without a reply.

See also: Hydrogenaudio Terms of Service.

accessibility: MSAA EVENT_OBJECT_NAMECHANGE fired on all playlist item
post Jun 22 2011, 05:33
Post #1

Group: Members
Posts: 62
Joined: 10-November 03
Member No.: 9758

foobar2000 version: 1.1.7

foobar2000's default user interface implements Microsoft Active Accessibility (MSAA) for its playlist control in order to make it accessible to screen readers and other assistive technologies.

Whenever playback is started or stopped, an EVENT_OBJECT_NAMECHANGE win event is fired on every playlist item from the currently playing item to the end of the playlist. For example, in a playlist containing 2 items, if the first item is playing, EVENT_OBJECT_NAMECHANGE is fired on both items whenever playback is started, paused, resumed or stopped. This becomes a very serious problem in large playlists, as foobar2000 floods the system with unnecessary events, causing some MSAA clients to freeze indefinitely in the worst case. EVENT_OBJECT_NAMECHANGE should only be fired if the name of the item actually changes.

Steps to reproduce:
1. Load or create a playlist containing more than 1 item.
2. Set up an MSAA event inspection tool such as AccEvent or AccProbe to watch the foobar2000 application.
3. Play the first item.
Expected: EVENT_OBJECT_NAMECHANGE should not be fired on any playlist items, as their name has not changed.
Actual: EVENT_OBJECT_NAMECHANGE is fired on all playlist items.

I'd be glad to provide any further information requested or help with debugging.

Go to the top of the page
+Quote Post
Start new topic
post Nov 16 2011, 10:26
Post #2

Group: Members
Posts: 128
Joined: 3-January 04
Member No.: 10920

This has been brought to my attention by -MM- I have then consulted it with Jamie and finally tried to reproduce.
I can confirm it too.
This is most evident with Windows 7 and never because of a newer accessibility framework UIAutomation which is available since that version of Windows by default.
Can this be looked into please?
Go to the top of the page
+Quote Post

Posts in this topic

Reply to this topicStart new topic
1 User(s) are reading this topic (1 Guests and 0 Anonymous Users)
0 Members:


RSS Lo-Fi Version Time is now: 26th November 2015 - 12:03