[1470] Задержки переключения состояний prvPlayerState

[McClaud]

Об этом я и говорил, что раньше было так же, как сейчас с выездом дочерних окон. На самом деле - это баг, интерфейс не должен замораживаться.

Значит задержка на кнопке вызова дочернего окна это тоже баг, и будет фикситься. Я думал фича, на заморозку всего интерфейса не обратил внимания...
Ну а в принципе возможно как-то модифицировать TASSEButton, чтобы продлить время демонстрации Push-кадра до переключения PlayerState?

[Artem]

Ну а в принципе возможно как-то модифицировать TASSEButton, чтобы продлить время демонстрации Push-кадра до переключения PlayerState?

Как ты себе это представляешь? Ведь кнопка никак не завязана на PlayerState

[McClaud]

Как ты себе это представляешь? Ведь кнопка никак не завязана на PlayerState

Ну, я-то не знаю "кухни". Я спрашиваю: в принципе что-то подобное можно сделать? Другую, специальную кнопку сделать, связанную с PlayerState... Но что-то же надо сделать. Это ведь не логично, что кнопка, нажатие которой ассоциируется именно с нажатием - не может быть таким образом оформлена из-за "дребезга". Понимаю, что такова вообще логика работы в винде. Со срабатыванием на отпускание сделать ничего нельзя, но задержку-то организовать можно? В 3.55 был глюк - секундная задержка, иногда её чуть недоставало, "дребезг" проскакивал. Поэтому я и прошу эту задержку реализовать не по времени - в лоб, а сколько нужно для переключения PlayerState. Ну, право же, - смотреть спокойно на дёрганье невозможно, а исключение нажатого состояния тоже смотрится не ахти: кнопку нажал/отпустил, а она самостоятельно через некоторое время сама "вжимается в пол"...
Надо что-то придумать 

Я может излишне эмоционален, - вопрос уж больно для меня болезненный. И я вот что подумал. У кнопок (и переключателей) есть точка доступа State, по которой переключаются наборы кадров. Нужно только чуть подкорректировать логику, а именно: отображать Push-кадр до смены значения на State (с нуля на единицу, с единицы ли на нуль - неважно, главное изменение). Уверен, что внешне это никак не скажется на классическом их, кнопок, применении. Вот только реализуемо ли это?

[Black_AVP]

... Поэтому я и прошу эту задержку реализовать не по времени - в лоб, а сколько нужно для переключения PlayerState...

Как я понимаю, задержка образуется не из-за запоздалого переключения prvPlayerState. При нажатии PLAY грузится файл и требуется время на его распаковку, размещение в памяти, чтение данных и параметров,  и только после этого меняется состояние провайдера. А если при чтении файла эксепшен - тогда и провайдеру нельзя переключаться.
Может, подойдёт тот костыльный вариант, который я упоминал: сделать возможным получать сообщения о клике мыше низлежащими по Z-ордеру элементами, но с теми же координатами, тогда можно сделать пирожок из Button и DigitsDisplay. А в Редактор Текстур добавить чекбокс типа "Транслировать клики мыши низлежащим элементам".

[McClaud]

Как я понимаю, задержка образуется не из-за запоздалого переключения prvPlayerState. При нажатии PLAY грузится файл и требуется время на его распаковку, размещение в памяти, чтение данных и параметров,  и только после этого меняется состояние провайдера. А если при чтении файла эксепшен - тогда и провайдеру нельзя переключаться.
Может, подойдёт тот костыльный вариант, который я упоминал: сделать возможным получать сообщения о клике мыше низлежащими по Z-ордеру элементами, но с теми же координатами, тогда можно сделать пирожок из Button и DigitsDisplay. А в Редактор Текстур добавить чекбокс типа "Транслировать клики мыши низлежащим элементам".

Совершенно верно, задержка обусловлена обработкой данных.
Твоё предложение подразумевает расширение возможностей скин-движка и редактора, но по сути остаётся "костыльным"? Сама по себе трансляция кликов может и нужна (сейчас же нельзя с одной кнопки управлять двумя провайдерами), но проблему задержки не решит. А нужно то всего "заморозить" Push-кадр до смены состояния на State. Т.е. просто расширить логику поведения кнопки. Тем более, что на работе кнопок для других задач это никак не скажется - нет задержки на State - нет "заморозки".

[Artem]

Совершенно верно, задержка обусловлена обработкой данных.
Твоё предложение подразумевает расширение возможностей скин-движка и редактора, но по сути остаётся "костыльным"? Сама по себе трансляция кликов может и нужна (сейчас же нельзя с одной кнопки управлять двумя провайдерами), но проблему задержки не решит. А нужно то всего "заморозить" Push-кадр до смены состояния на State. Т.е. просто расширить логику поведения кнопки. Тем более, что на работе кнопок для других задач это никак не скажется - нет задержки на State - нет "заморозки".

А если смена State так и не произойдет?

[McClaud]

А если смена State так и не произойдет?

А если ограничить период "заморозки" небольшим запасом по времени? Судя по багу в 3.55 задержка редко превышает секунду. Сделать двухсекундный задел на несрабатывание. Если State не переключился, кнопка возвращается в ненажатое состояние. Для случая с незадействованным State исключить заморозку вообще.
А, кстати, в редакторе два типа кнопок: просто кнопки и переключатели, хотя между ними разницы вроде и нет. Хоть первый, хоть второй можно использовать и так и так. Разве что "умолчательное" состояние характеризуется разным набором кадров. Или я что-то упустил? Может режим с заморозкой оставить для переключателей, не трогая просто кнопки?

[Artem]

В таком случае, уж лучше ввести промежуточные состояния у провайдера - Starting, Pausing, Stopping

[Black_AVP]

В таком случае, уж лучше ввести промежуточные состояния у провайдера - Starting, Pausing, Stopping

А, может, будет достаточно даже одного дополнительного состояния Waitihg, чтоб не добавлять много новых констант, конкретно не важно какое состояние следующее (оно определяется нажимаемой кнопкой), важно отловить этот момент неопределённости.

[Soolo]

А, может, будет достаточно даже одного дополнительного состояния Waitihg, чтоб не добавлять много новых констант, конкретно не важно какое состояние следующее (оно определяется нажимаемой кнопкой), важно отловить этот момент неопределённости.

мне думается, что одного доп состояния будет мало

[Artem]

А, может, будет достаточно даже одного дополнительного состояния Waitihg, чтоб не добавлять много новых констант, конкретно не важно какое состояние следующее (оно определяется нажимаемой кнопкой), важно отловить этот момент неопределённости.

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

[Black_AVP]

кто знает, какие вещи могут понадобиться в будущем...

А, может, "под шумок", и эта давняя мечта как-нибудь прокатит: http://www.aimp.ru/forum/index.php?topic=45090.0
В части выделения состояния удержания кнопок ускоренной перемотки?
Ведь, есть же где-то в программе, как я понимаю, процедура обработки этого состояния - плеер на неё реагирует, проматывает трек. Почему бы из неё не послать сообщение провайдеру prvPlayerState, что кнопка удерживается, а потом что отпущена?

[McClaud]

В таком случае, уж лучше ввести промежуточные состояния у провайдера - Starting, Pausing, Stopping

Все нововведения, при их безусловной полезности, не решают проблему текущих скинов, без их коррекции в новом редакторе. Я же надеялся обойтись "малой кровью", реализовав предложенные мной полумеры на уровне плеера последующего билда.

[McClaud]

В таком случае, уж лучше ввести промежуточные состояния у провайдера - Starting, Pausing, Stopping

А в рамках текущей версии есть надежда хоть на какое-то на решение данной проблемы, или ждать четвёрку?

[Artem]

А в рамках текущей версии есть надежда хоть на какое-то на решение данной проблемы, или ждать четвёрку?

Решения проблемы нет вообще, ни для 4-ки, ни для 3-ки.