Поясняю ситуацию. Допустим у нас есть пустое WPF приложение с одной единственной "служебной" кнопкой button по нажатию на которую автоматически создается кнопка button1 (свойства все прописаны в коде-размер, расположение и т.д.), если пользователь еще раз нажмет на кнопку button, то под button1 создается кнопка button2 с такими же свойствами как и button1 и т.д.
Главный вопрос над которым я уже несколько месяцев думаю думаю и не могу придумать: вот пользователь создал кнопки, выбрал из списка функции для этих кнопок, но ГДЕ и КАК можно все это сохранить, чтобы при следующем запуске приложения все это снова отображалось  в приложении? Ведь в наличии только exeшник программы и все.  Если только в  xml файл каким-то образом записывать...
Но вообще  в моем случае все равно будет использовать MsSQL - может всю эту информацию каким-то образом туда писать?...
На самом деле это очень важный вопрос: пользователи должны кастомизировать приложения под себя, так как им нужно - это вектор для программирования десктопных приложений на ближайшее будущее...
В Windows Form тоже нет никаких  готовых решений... 
Помогайте кто чем может...если кто сталкивался с подобным - напишите хотя бы какой-нибудь примерчик простенький. 
Всем заранее спасибо

При выходе из приложения можно записывать контролы XamlWriter-ом, а при следующем запуске приложения - считывать этот XAML при помощи XmlReader-а.

пример из msdn иллюстрирует именно Ваш случай ИМХО.

Это сообщение отредактировал(а) tol05 - 16.1.2010, 22:17

можно создать потомок класса (class myButton:button{}) с содержанием нужных параметров кнопки и  записывать все созданные кнопки в List<myButton> масив. И сохранять этот масив.

Примерчик самый простой хотя бы

в моем посте есть линк


а вот на пример этого подхода действительно хотелось бы посмотреть )

а вот на пример этого подхода действительно хотелось бы посмотреть 

примерно так, только осталось отучить BinaruFormater от класса Button.

Без кружки пива код не смотрите 

Присоединённый файл ( Кол-во скачиваний: 3 )
 ConsoleServer_Client.zip 50,16 Kb

WolfTheGrey, коротко о Вашей идее:
- Вы выбрали только несколько свойств из того великого множества данных, с которыми может быть ассоцииирована кнопка. При каждом чихе (грубо говоря) Вам нужно будет дорабатывать свой серилизуемый класс.
- если нужно будет сохранять восстанавливать другие контролы - Вы очевидно будете создавать для каждого из них подобный класс. Приложение будет требовать перекомпиляции и доставки нового варианта клиентам.
И чем Вы замените тогда List<myButton> ? Объектом List<myUnknownButAnywayBeautifulControl> ? Тогда десерилизация (в List конкретных типов) может быть проблематичной.

Ведь основная проблема - как восстановить данные при повторном запуске

Вы на этот вопрос не ответили.

И последнее. Сохранение\восстановление графического интерфейса приложения - это простая и далеко не самая важная задача этого самого приложения... Если таким образом подходить к решению каждой из таких задач.. 

Это сообщение отредактировал(а) tol05 - 17.1.2010, 17:06

пространство имен: System.Windows.Markup не плохая тема 

Это сообщение отредактировал(а) WolfTheGrey - 18.1.2010, 07:04

tol05: Ваш пример из msdn не будет сохранять обработчик кнопки. Если набор обработчиков фиксирован и заранее известен, можно использовать метод предоженный мной в теме сохранение-созданных-пользователем-кнопок

math64, просто я полагал вопрос состоял в сохранении\восстановлении графического состояния - дерева элементов. 
Чтение\запись XAML это сделать позволяет и, очевидно, для этого и придумано. 

Да ведь и Вы в своей теме об этом же рассуждали. Я не видел Вашей темы просто )
Кстати, мне понравился Ваш подход. Единственное, что бы я сделал - вместо enum сделал бы иерархию объетов Action (наподобие того как сделан паттерн Command в WPF), где каждому Action ставился бы в соответствие свой хандлер и, таким образом, убрал бы switch.

То, что обработчики событий не сохраняются (поведение т.е.) - это указано в msdn (Сериализация ограничений XamlWriter.Save)... Что делать! Но, с другой стороны, это не всегда и плохо )
Например, когда Вы хотите внедрить фрагмент чужеродной разметки в свое приложение. Какая это будет разметка, каких она будет требовать хандлеров (да и будут ли там вообще какие-нибудь хандлеры) - этого Вы не узнаете, пока не прочитаете эту разметку в рантайме. 
Соответственно, нельзя объять необъятное ))

вот так я примерно рассуждал