[FAQ] Вопросы по работе в AIMP SkinEditor v3.50+

[Black_AVP_Bim]

См. справку, "Свойства ресурсов", Font. Все свойства TFont доступны из скриптов, и в этой теме, если воспользоваться поиском, нетрудной найти примеры изменения и цвета, и стиля, и размера, и гарнитуры шрифтов.

[TurboDISCO Adept]

Black_AVP,    Zhenya, TeDj - благодарю за ответы!

Ну-с... скрипты - это серьёзное дело (во всех отношениях и понятиях). Видимо сначала всё-таки стоит попробовать проделать техническую работу - построить тестовую сборку на многостраничных группах и посмотреть как это всё будет весить и работать, хотя бы и на отдельных кнопках переключения для каждого окна. А потом уже пробовать свести всё под одну кнопку управления, если Вы говорите, что это таки возможно.
...Там, просто, ещё сложность и в том, что и через тот же репозитарий ресурсов не получится сделать - одинаковых элементов почти нет, кроме текстуры черезстрочной шахматки, остальное всё крайне индивидуально для каждого окна. А в подразумеваемом проекте, ко всему прочему, в группы придётся ставить не просто только сменяемую визуальную часть (текстуру-"занавеску") - даже скорее не её, а, как минимум, два полновесных, сменяемых друг-друга, комплекта элементов управления - по дизайну: один комплект визуально на "кнопочном управлении", второй - визуально в формате "тач-скрин". Нет пока понимания, как будут уживаться функционально две кнопки "Плей", "Стоп" и т.д., пусть и поочерёдно скрываемые (но есть стойкое ощущение, что опять творю какую-то дичь    ), как-никак - восемь окон обложки планируется задействовать.

Я в своих проектах иногда делал так. Есть например 3 TabbedGroup, связываю Visibility их контейнеров друг с другом, типа если виден первый контейнер с TabbedGroup1, то виден первый контейнер с TabbedGroup2 и TabbedGroup3. Тогда если виден первый контейнер TabbedGroup1, то видны все первые контейнера. Если второй, то все вторые. Остаётся тогда кнопку привязать к первому TabbedGroup и управлять видами через него. И никаких скриптов.

В какой работе это реализовано? И какие элементы там переключаются? Хотелось бы пощёлкать, посмотреть как получилось... Биндинг я, по крайней мере, в большей или меньшей мере самостоятельно могу попробовать сделать, потому как скрипт - вряд-ли напишу. 

[TeDj]

В какой работе это реализовано? И какие элементы там переключаются? Хотелось бы пощёлкать, посмотреть как получилось... Биндинг я, по крайней мере, в большей или меньшей мере самостоятельно могу попробовать сделать, потому как скрипт - вряд-ли напишу. 

В обложке AndroEvolution, в Опубликованных обложках, проект висит в шапке. Там, помнится, колонки так реализованы. Правда, там всего 2 многостраничных, но суть будет ясна. Если нажать кнопку левого, меняется и правая колонка, и наоборот.

[TurboDISCO Adept]

Ага, спасибо. Пользуюсь сейчас этой Вашей обложкой, но не подумал бы, что смена динамиков организована таким образом...
Конструкция вроде простая, интересно, будет-ли действенна не только в рамках одного окна - проверим. Итак, 8 окон, в каждом - по одной многостраничной группе, содержащей по два взаимно сменяемых контейнера - с полным "набором" текстур и элементов управления каждый. Многостраничная группа "Главного окна" привязывается на кнопку смены, а смена/видимость контейнеров в группах остальных окон подвязывается к соответствующим контейнерам группы "Главного окна".
Попробую организовать, посмотрим, получится-ли...

[TurboDISCO Adept]

Окно визуализации не обязательно. Визуалку можно как встроить в главное окно (как это было до bliss), так и вообще отказаться от визуалки.

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

[Artem]

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

Нет, не обязательны

[gr-e]

Как получить имя воспроизводимого плейлиста? prvPlaylistManager>ActivePlaylistName возвращает имя открытого плейлиста.

[Zhenya]

Как получить имя воспроизводимого плейлиста? prvPlaylistManager>ActivePlaylistName возвращает имя открытого плейлиста.

Видимо, никак.

[Artem]

Как получить имя воспроизводимого плейлиста? prvPlaylistManager>ActivePlaylistName возвращает имя открытого плейлиста.

Для чего это нужно?

[Zhenya]

Для чего это нужно?

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

[Artem]

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

Я не хочу гадать, я хотел бы узнать о реальном сценарии, где без этой информации не обойтись

[gr-e]

Для чего это нужно?

Чтобы сохранять положение shuffle для конкретного плейлиста

[Zhenya]

Чтобы сохранять положение shuffle для конкретного плейлиста

Ну имена вполне могут быть одинаковыми для разных плейлистов. Тогда уж какой-нибудь идентификатор плейлиста нужен.

[gr-e]

Ну имена вполне могут быть одинаковыми для разных плейлистов. Тогда уж какой-нибудь идентификатор плейлиста нужен.

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

[Artem]

Чтобы сохранять положение shuffle для конкретного плейлиста

А причем тут скины?