Баги со звуками

[MisterMyth]

Хоть больше я правил TabSRMM, но так как это правка связана с ВК, то оставлю здесь. Баг, который я правил мелкий, но правлю, что могу и то, что мешает.  В аналоги TabSRMM правку не вносил, так как сам использую TabSRMM. Если правку добавят посмотрю аналоги. Правку я внес потому, что BASS_interface и XSoundNotify конфликтуют и мне не нравится, что для правки багов приходятся ставить дополнительные плагины.

Так теперь о главном. Целью правки было убрать звук входящего сообщения при уведомлениях со стены Вконтакте. Так как баг редкий выкладываю патч с просьбой теста, сам конечно тоже проверю, но на нескольких машинах это можно сделать быстрее. Гарантирую, что dll собираются, это я проверил. Нужен лишь массовый тест в самой программе.

[Elzor]

MisterMyth, баг, о котором ты говоришь, проявляется когда сообщения прилетают, что называется "большой толпой" и от того, в какой контакт они прилетают или даже по какому протоколу, не зависит. Следовательно, патч, который ты предлагаешь - это костыль из говна и палок и место ему там, где место всем вещам сделанных из подобного материала.

[Mikalair]

BASS_interface и XSoundNotify конфликтуют

Они не конфликтуют, это просто в XSoundNotify костыль неправильно работает.

[MisterMyth]

Elzor, так как у меня данный баг есть лишь с ВК я так и написал. Считайте, что это сделано коряво, это ваше право. Я не в обиде. И извиняюсь за оффтоп, но Mikalair, XSoundNotify нужно переписывать под звуки, которые буду сохраняться в настройках контакта.

[MisterMyth]

Elzor,  и еще вопрос это баг только TabSRMM или любого другого модуля для переписок?

[Elzor]

MisterMyth, честно сказать - не знаю. У меня личное ощущение, что это где-то на достаточно низком уровне. Может быть где-то рядом с драйвером базы или, может быть, в ядре. Вроде как все сводится к тому, что у сообщения флаг "прочитано" выставляется позже, чем нотификатор (или кто там вместо него) говорит "дзынь". Или, может быть, при некоторых условиях флаг игнорируется.
Все выше сказанное - ИМХО и на истину не претендует. Я могу тут полностью ошибаться.

[MisterMyth]

Elzor, а форма приведения к "прочитано" едина или нет? Разная у каждого протокола?

[Elzor]

Если я правильно понял твой вопрос, то, стандартно схема будет такая:  прилетело сообщение и протокол отправил его в базу непрочитанным, при этом может быть  сработает нотификатор (в зависимости от настроек и есть ли он вообще) и сообщит об этом пользователю. Потом, при клике по иконке в трее, по контакту в клисте или по непрочитанной вкладке в табсах, или может быть еще при каких-то условиях, сообщение делается прочитанным. Кто конкретно за это отвечает - вопрос (для меня) не до конца понятный, не протокол - точно
Кроме того, сообщение может сразу отправляться в базу прочитанным. Мало кто из протоколов этим развлекается. ВК это делает, если с сервера прилетает уже прочитанное сообщение (при синхронизации истории, например) или для спецконтакта, если выставлена настройка нестандартных окон и уведомлений. Баг в том, что нотификатор не должен при этом дзынькать, а он дзынькает. Почему именно он так делает - история для меня темная.

[MisterMyth]

Elzor, правильно ли я понимаю, что лично для вас правильным лечением данного бага будет либо его исправление либо починка xsound?

[MisterMyth]

Elzor, я нашел причину бага, точнее то, что его вызывает. Сейчас обратил внимание на то, что баг со звуком есть, когда вкладка псевдоконтакта открыта. Пока ее не было не было и проблем со звуком. Проверить сможет еще кто нибудь?

[Elzor]

Elzor, правильно ли я понимаю, что лично для вас правильным лечением данного бага будет либо его исправление либо починка xsound?

Честно говоря, я не понимаю, причем тут xsound. В нем тоже есть баг - ну да, есть, но это другой баг. Правильное решение в любом случае одно - найти сам баг и править его, а не пытаться голой задницей заткнуть пробоину в борту корабля, особенно если пробоина эта выше ватерлинии.

Сейчас обратил внимание на то, что баг со звуком есть, когда вкладка псевдоконтакта открыта. Пока ее не было не было и проблем со звуком.

Насколько я помню, действительно баг проявляется при открытой вкладке. Но это не причина, это просто одно из условий срабатывания.

И вообще все это вот тут - оффтоп, к вк-плагину описанные выше баги никакого отношения не имеют. Прошу модеров по возможности разделить тему.

[MisterMyth]

Продолжил смотреть исходники TabSRMM. Получается очень интересная вещь. Но мне нужна подсказка возможно от Elzora, или возможно от кого то еще. Как я понял Elzor, в первом ответе дал мне намек на то что этот баг повторяется не только у псевдоконтакта от ВК, поэтому я хочу спросить где его еще ловили на чем?

Это может мне понять нашел ли я проблему или нет.

[Elzor]

MisterMyth, бывает проявляется при загрузке жирной хистори с сервера. Проявляется не всегда, и у меня не на всех моих машинах (хотя это как раз может и случайностью быть).

[MisterMyth]

Elzor, и если я не ошибаюсь, то какой бы вид уведомлений пользователь не выбрал для псевдоконтакта, они всегда приходят как сообщение? То есть eventType = EVENTTYPE_MESSAGE? Даже если и нет, похоже на то, что если открыта вкладка псевдоконтакта тип ивента сам назначается как eventType = EVENTTYPE_MESSAGE, а так как в коде вывода сообщений со стены

cle.hDbEvent = NULL; Вот тут вроде бы ивента нет.
cle.flags = CLEF_URGENT | CLEF_TCHAR;

А в коде TabSrMM написано:

   if (dbei.eventType == EVENTTYPE_MESSAGE && !(dbei.flags & (DBEF_SENT)))
      PostMessage(hwndDlg, DM_PLAYINCOMINGSOUND, 0, 0);

Получается, что правая часть условия истина верна.
Где то для открытых вкладок идет смена оригинального eventType. Вместо него прописывается EVENTTYPE_MESSAGE, и именно по этому мы получаем лишний звук.

[Elzor]

они всегда приходят как сообщение? То есть eventType = EVENTTYPE_MESSAGE? Даже если и нет, похоже на то, что если открыта вкладка псевдоконтакта тип ивента сам назначается как eventType = EVENTTYPE_MESSAGE

Правильнее сказать, что вк-плагин получает уведомления со стен и после обработки отдает их на следующий уровень как сообщения. И именно потому что они отданы дальше как сообщения, они показываются в табсе (ну и в историю записываются).

cle.hDbEvent = NULL; Вот тут вроде бы ивента нет.
cle.flags = CLEF_URGENT | CLEF_TCHAR;

А в коде TabSrMM написано:

   if (dbei.eventType == EVENTTYPE_MESSAGE && !(dbei.flags & (DBEF_SENT)))
      PostMessage(hwndDlg, DM_PLAYINCOMINGSOUND, 0, 0);

То есть вообще ни разу не смутило, что cle - это CLISTEVENT, а dbei - это DBEVENTINFO?

Где то для открытых вкладок идет смена оригинального eventType.

Как бы после такого вывода прямо больше ничего не остается, кроме как пожелать успехов в дальнейших изысканиях.