Кстати говоря, не забудьте, что для того, чтобы audio mixdown заработал, нужно пометить участок для экспортирования. Это делается сверху на линейке времени, там участок можно просто выделить мышкой. Если нужно сохранить песню целиком, нужно выделить всю песню целиком.
Мигает она, когда выполнение приостановлено. Кликните по иконке, появится контекстное меню, в нем снимите галку со «Script Paused».
Само же переключение девайса происходит по нажатию горячей клавиши. По умолчанию это Ctrl+Alt+F12 (можно менять в конфиге).
Пока что под ваше описание подходит большинство таск-трекеров типа JIRA, versionone, trac и т.п.
Или вам нужно автоматически распределять задачи из ваших категорий в заданной пропорции?
В общем, уточните требования :)
Я имел в виду, что тогда любые объекты можно складывать в любую коллекцию в виде object и затем преобразовывать их к нужному виду при помощи экспортирования.
Также можно вместо StreamWriter ипользовать свой Writer, поддерживающий нужные вам методы форматирования данных на выходе.
Я им вполне успешно пользовался, чтобы подсчитывать время, которое трачу на работу и на развлечения, и вообще, засекать, сколько времени на работе нахожусь. Это было полезно, когда в конце месяца нужно было сдавать тайм-репорт.
Но разве там можно как-то ограничивать доступ к определенным ресурсам? Да еще и в зависимости от времени?
О, спасибо! Я как раз недавно читал несколько его статей по менеджменту у него в блоге. И другие статьи у него классные, про проектирование, к примеру.
Разрешите поинтересоваться, а как соотношение обычных элементов к списковым на что-то влияет?
Меня вот беспокоит другой вопрос. Я сейчас создал две таблицы по варианту №2, и у этих таблиц получилась идентичная структура, за исключением уникального индекса в первой таблице.
Т.е. имеем три поля: id, control_id, value.
В таблице с простыми элементами control_id нужно, чтобы поставить в соответствие запись в этой таблице и элемент страницы, в который данные будут попадать (textbox). Во второй таблице control_id выполняет ту же роль для dropdown-листов + по этому полю нужно будет группировать записи.
Все хорошо, но практически идентичная структура таблиц наводит на подозрения :)
В этом варианте струтуры да, это единственный способ достичь желаемого результата. Но выглядит он как костыль :) В частности, поэтому я уже решил использовать вариант №2. Он является самым правильным с точки зрения нормализированной реляционной структуры данных. Да и самым удобным, судя по всему, тоже.
Наверное, вы имели в виду иерархическую модель данных. Впрочем, она — всего лишь частный случай сетевой модели.
А почему вы считаете, что задача лучше всего решается сериализацией?
Проблема обновления данных встаёт не только и не столько при расширении функционала, но и вообще при любых обновлениях данных.
Вернее, самая большая проблема такого подхода — перенос действий, которые должны производиться базой данных (выборочное обновление, выборочное чтение, поиск), в код приложения. А зачем это делать, если можно структурировать данные правильно и оперировать ими при помощи средств БД?
Собстенно говоря, я уже склонился к использованию варианта с двумя таблицами. Он является самым правильным с точки зрения нормализированной реляционной структуры данных. Да и самым удобным, судя по всему, тоже.
Я нигде не писал, что в этом ваиранте нет Primary Key. Я писал, что идентификатор записи словаря (в которой может содержаться несколько элементов) будет неуникальным в такой таблице. В вашем примере это соответствует ListID. Естественно, будет добавлен искусственный первичный ключ отдельной колонкой.
А вот отличить список с одним элементом от элемента, не являющегося списком, в жанном случае невозможно без добавления уже 4-й колонки а-ля is_list_element. В условии задачи я написал, что это — необходимое условие.
