Comments 13
Вам, конечно, спасибо за старание, хоть какое-то.
Не считая кода, значительная часть статьи — перечисление множественных недостатков вашей работы. Вас кто-то гнал, что «В связи с вышеизложенным и катастрофической нехваткой времени код отнюдь не блещет элегантностью», «В порыве лютого энтузиазма писал код без оглядки на «Best Practice Guides»»? Имейте уважение к читателям.
А конкретно по реализации — по-моему, она чудовищна. Я запутался в адорнерах, бизиадорнерах, АдорнаблеЛейерах, адорнерманагерах, аттачах-детачах и прочем. В вашем подходе, получается, чтобы иметь возможность крутить индикатор занятости, нужно наследоваться от BaseAdornableControl?
Для назначения адорнера у вас нужно писать кучу кода, подписываться на событие вьюмодели. Это не MVVM-подход.
Простейшая схема:
Контрол BusyIndicator, который занимается исключительно отрисовкой самого себя, имеет единственное депенденси-свойство IsRunning
BusyIndicator хостится в том контроле, на котором нужно показывать прогресс, биндим его свойство IsRunning к свойству IsBusy вьюмодели.
Будет как-то так:
BusyIndicator IsHitTestVisible=«False» CacheMode=«BitmapCache» IsRunning="{Binding IsBusy}"
И все.
Не считая кода, значительная часть статьи — перечисление множественных недостатков вашей работы. Вас кто-то гнал, что «В связи с вышеизложенным и катастрофической нехваткой времени код отнюдь не блещет элегантностью», «В порыве лютого энтузиазма писал код без оглядки на «Best Practice Guides»»? Имейте уважение к читателям.
А конкретно по реализации — по-моему, она чудовищна. Я запутался в адорнерах, бизиадорнерах, АдорнаблеЛейерах, адорнерманагерах, аттачах-детачах и прочем. В вашем подходе, получается, чтобы иметь возможность крутить индикатор занятости, нужно наследоваться от BaseAdornableControl?
Для назначения адорнера у вас нужно писать кучу кода, подписываться на событие вьюмодели. Это не MVVM-подход.
Простейшая схема:
Контрол BusyIndicator, который занимается исключительно отрисовкой самого себя, имеет единственное депенденси-свойство IsRunning
BusyIndicator хостится в том контроле, на котором нужно показывать прогресс, биндим его свойство IsRunning к свойству IsBusy вьюмодели.
Будет как-то так:
BusyIndicator IsHitTestVisible=«False» CacheMode=«BitmapCache» IsRunning="{Binding IsBusy}"
И все.
Извините… не туда ответ запостал.
> В вашем подходе, получается, чтобы иметь возможность крутить индикатор занятости, нужно наследоваться от BaseAdornableControl?
Совсем не обязательно. Для добавления адорнера в произвольный контрол есть менеджер.
> Для назначения адорнера у вас нужно писать кучу кода, подписываться на событие вьюмодели.
Во-первых, один обработчик не есть «куча кода». Во вторых, вы получаете контроль над добавлением и удалением адорнера. В-третьих, адорнер не должен висеть в памяти, когда он не нужен.
> BusyIndicator IsHitTestVisible=«False»
Конкретно в ситуации адорнера занятости IsHitTestVisible должен быть равен True, чтобы перехватывать события мыши.
> BusyIndicator хостится в том контроле, на котором нужно показывать прогресс, биндим его свойство IsRunning к свойству IsBusy вьюмодели.
Для этого нужно будет делать адорнер на основе контрола, а это достаточно тяжелое решение. Опять же, нежелательно, чтобы выключенный, невидимый контрол потреблял память.
Совсем не обязательно. Для добавления адорнера в произвольный контрол есть менеджер.
> Для назначения адорнера у вас нужно писать кучу кода, подписываться на событие вьюмодели.
Во-первых, один обработчик не есть «куча кода». Во вторых, вы получаете контроль над добавлением и удалением адорнера. В-третьих, адорнер не должен висеть в памяти, когда он не нужен.
> BusyIndicator IsHitTestVisible=«False»
Конкретно в ситуации адорнера занятости IsHitTestVisible должен быть равен True, чтобы перехватывать события мыши.
> BusyIndicator хостится в том контроле, на котором нужно показывать прогресс, биндим его свойство IsRunning к свойству IsBusy вьюмодели.
Для этого нужно будет делать адорнер на основе контрола, а это достаточно тяжелое решение. Опять же, нежелательно, чтобы выключенный, невидимый контрол потреблял память.
А почему просто не взять готовый контрол из WPF Toolkit?
Как вариант просто посмотерть как там в красках Good practice все сделано и не изобретать свои квадратноколесые велосипеды.
Как вариант просто посмотерть как там в красках Good practice все сделано и не изобретать свои квадратноколесые велосипеды.
> А почему просто не взять готовый контрол из WPF Toolkit?
Какой контрол вы имеете в виду?
В начале поста я написал, что важно понимать каким образом можно их сделать. Какие варианты есть. Без понимания как работают адорнеры можно сделать ошибки, из-за которых потом придется наворачивать жуткие костыли.
Пример тому пост, на который я ответил. Функционал готового продукта не устроил разработчика — пришлось лезть рефлекшном внутрь. И в итоге кода будет столько же, но «опасного» в плане стабильности.
К тому же, сроки с заказчиком утверждены, и они не позволяют пройти процедуру соглосования лицензий того же Toolkit'а на стороне заказчика.
Какой контрол вы имеете в виду?
В начале поста я написал, что важно понимать каким образом можно их сделать. Какие варианты есть. Без понимания как работают адорнеры можно сделать ошибки, из-за которых потом придется наворачивать жуткие костыли.
Пример тому пост, на который я ответил. Функционал готового продукта не устроил разработчика — пришлось лезть рефлекшном внутрь. И в итоге кода будет столько же, но «опасного» в плане стабильности.
К тому же, сроки с заказчиком утверждены, и они не позволяют пройти процедуру соглосования лицензий того же Toolkit'а на стороне заказчика.
> Какой контрол вы имеете в виду?
Вопрос снимается — перешел по ссылке… В статье дополнил про использование контролов. Это на самом деле целый диалог, а не легковесный адорнер.
Вопрос снимается — перешел по ссылке… В статье дополнил про использование контролов. Это на самом деле целый диалог, а не легковесный адорнер.
Скопирую со своего комментария
>Как вариант просто посмотерть как там в красках Good practice все сделано и не изобретать свои квадратноколесые велосипеды.
То, что вы тут приводите в качестве примера набор говнокода, я полностью соглсен с первым комментарием.
А потом, странно что вы на стадии создание архитектуры и ее согласования не понимали что вам нужны будут дополнительные контролы и задумались об этом только когда проект подходит к концу.
>Как вариант просто посмотерть как там в красках Good practice все сделано и не изобретать свои квадратноколесые велосипеды.
То, что вы тут приводите в качестве примера набор говнокода, я полностью соглсен с первым комментарием.
А потом, странно что вы на стадии создание архитектуры и ее согласования не понимали что вам нужны будут дополнительные контролы и задумались об этом только когда проект подходит к концу.
Во-первых, тут приведен код не из реального проекта.
Во-вторых, раз уж началась-таки критика, то извольте указывать, что конкретно вы называете ГК и/или «как правильно писать.»
В-третьих, это Agile. Сегодня кастомеру не нужны индикаторы, а завтра он захочет их поиметь. Будь добр исполни прихоть.
Во-вторых, раз уж началась-таки критика, то извольте указывать, что конкретно вы называете ГК и/или «как правильно писать.»
В-третьих, это Agile. Сегодня кастомеру не нужны индикаторы, а завтра он захочет их поиметь. Будь добр исполни прихоть.
>Во-первых, тут приведен код не из реального проекта.
В виду того, что мы, как выяснелось, обсуждаем сферического коня в вакуме с надуманными вами гепотетическими ситуациями дисскусию предлагаю закрыть.
В виду того, что мы, как выяснелось, обсуждаем сферического коня в вакуме с надуманными вами гепотетическими ситуациями дисскусию предлагаю закрыть.
Ну раз у вас конкретных замечаний нет, то можно было и не начинать дискуссию. Тем более в заголовке ясно написано «Как бы… делал..».
А концепция как раз приближенная к практике. Если вы считаете использование Adorner'ов «говнокодом», то мне тоже нечего добавить.
А концепция как раз приближенная к практике. Если вы считаете использование Adorner'ов «говнокодом», то мне тоже нечего добавить.
Я всего лишь хотел сказать и повторить слова, которые пишутеся почти на каждой странице книги Руководство Microsoft по проектированию архитектуры приложений. 2е издание: не изобретайте велосипеды, используйте готовые решения.
А от себя добавить, что если не знаете как изобретать — посмотрите как длеают это люди, кторые знают.
А от себя добавить, что если не знаете как изобретать — посмотрите как длеают это люди, кторые знают.
В качестве примера вы указываете на тулкит? Про него я отписался уже. Это решение тяжеловесное и сделано оно как ProgressBar.
Если у вас есть другие примеры — приведите.
> посмотрите как длеают это люди, кторые знают.
Вы думаете, что Telerik, DevExpress, Visifire, написанные известными компаниями, идеальны? Или в этих конторах тоже «незнающие девелоперы»? Нет и нет. Заюзав Visifire или Toolkit'овский DataGrid вы столкнетесь с конфликтом его логики и логики, которую требует заказчик.
Вот к примеру DatePicker тулкитовский. При размещении его в выпадающем меню возникают проблемы. Скрыть Popup с этим пикером логично по событию смены даты. Но проблема в том, что смена даты происходит по MouseLeftButtonDown. Из-за этого MouseLeftButtonUp срабатывает уже на контроле, находящемся под Popup'ом.
На лицо неправильное использование.
А с индикаторами, наследованными от контролов может получиться также. Новичок начнет втыкать их для каждой формочки или отдельного контрола, разведет таких диалого большое количество, а когда увидит, что его приложение жутко тормозит и жрет память немеренно, то станет лишь ругать разработчиков тулкита, визифайра и т.д., НО НЕ СЕБЯ.
Если у вас есть другие примеры — приведите.
> посмотрите как длеают это люди, кторые знают.
Вы думаете, что Telerik, DevExpress, Visifire, написанные известными компаниями, идеальны? Или в этих конторах тоже «незнающие девелоперы»? Нет и нет. Заюзав Visifire или Toolkit'овский DataGrid вы столкнетесь с конфликтом его логики и логики, которую требует заказчик.
Вот к примеру DatePicker тулкитовский. При размещении его в выпадающем меню возникают проблемы. Скрыть Popup с этим пикером логично по событию смены даты. Но проблема в том, что смена даты происходит по MouseLeftButtonDown. Из-за этого MouseLeftButtonUp срабатывает уже на контроле, находящемся под Popup'ом.
На лицо неправильное использование.
А с индикаторами, наследованными от контролов может получиться также. Новичок начнет втыкать их для каждой формочки или отдельного контрола, разведет таких диалого большое количество, а когда увидит, что его приложение жутко тормозит и жрет память немеренно, то станет лишь ругать разработчиков тулкита, визифайра и т.д., НО НЕ СЕБЯ.
>Во-первых, тут приведен код не из реального проекта.
В виду того, что мы, как выяснелось, обсуждаем сферического коня в вакуме с надуманными вами гепотетическими ситуациями дисскусию предлагаю закрыть.
В виду того, что мы, как выяснелось, обсуждаем сферического коня в вакуме с надуманными вами гепотетическими ситуациями дисскусию предлагаю закрыть.
Sign up to leave a comment.
Как бы я делал BusyIndicator