← All posts tagged код

wormpicturesque
dev_c# Q: Когда WPF контролу присваиваем имя?
Навешиваем на него какое-либо событие — можно получить контрол из сендера. — то есть, вроде бы, можно имя не использовать. Что скажите?
A: >Когда ему присваиваем имя
Когда хотим задекларировать, что контрол используется в коде формы.
----
A: более развернуто, пжлст?
Если хотите, чтобы при удалении контрола из xaml-я ломалась компиляция — обзываете контрол и используете сгенеренную дизайнром переменную.Если предпочитаете, чтобы форма падала в рантайме (если ищете контрол по имени) или в форме оставались обработчики событий, которые ни на что не подписаны (как в вашем примере) — можно не заводить переменные.
На самом деле вопрос стиля. Мне больше нравится, когда всё что можно живёт в xaml-е и код формы практически пустой. При таком подходе если действительно приходится обращаться к контролу из формы, то вопросов "обзывать-не обзывать" не возникает.
wormpicturesque
1. Необязательно, правило следующее: a.Equals(b) — true, a.GetHashCode() == b.GetHashCode()
2. Необязательно, если поле не участвует в сравнении на равенство, то хешкод меняться не должен
wormpicturesque
Konstantin Alexandrov> у нас тут возник человек, который говорит что комментирование это хорошо.
"таки написание кода который не требует комментариев == понятного кода" Можите скинуть пару годных статей на тему?)

*** 2011-06-20
[09:35:19] <Игорь Синицын> Неа, это очень зависит от стиля кодирования. Лично я использую 3 приёма, которые напрочб убивают необходимость в подробных комментариях:

1. Разбиение кода на мелкие методы с (относительно) понятными названиями. В результата код читается практически как блок-схема.
2. Агрессивное использование ассертов. В последнее время дополняю debug-only ассертами. Во-первых, видно чего ты ожидаешь от кода. Во-вторых проверки пишутся прямо по месту, ради тестов не нужно нарушать инкапсуляцию.
3. Комментарии используются как метки для todo-list.
[09:36:15] <Игорь Синицын> Разумеется, есть исключения, в паре мест я предпочёл подробно расписать алгоритм в комментарии, сильно непонятный код выходил.
wormpicturesque
[21:55] Игорь: А, понял. StyleCop следит за соблюдением стиля кодирования: пробелы, отступы, переносы.
[21:55] Игорь: FxCop|CodeAnalysis использует метаданные (рефлексию) для анализа скомпилированного кода
[21:56] Игорь: И следдит за правильностью архитектуры, соответствием FDG etc
[21:57] Игорь: Ну а CodeContracts пытается анализировать программу не выполняя её (т.е. восстановить execution flow) и выловить код, который нарушает пред- и постусловия.
[21:58] Игорь: Задача безумно сложная и в общем виде не решаемая (она очень близка к проблеме останова), но у МС всё в основном получилось, главная проблема — излишний пуризм разработчиков, они требуют аннотации контрактами каждого метода. Причём должны указываться контракты, унаследованные от вызываемых методов. Неудобно.
wormpicturesque
* многопоточность
[16:20:41] <Konstantin Alexandrov> вопрос. прогресс бар пока делаем что-то. Соответственно надо 2 потока — делаем/прогресс бар. Делать можем не один раз. как лучше сделать и почему?;)
[16:21:02] <Konstantin Alexandrov> //вопрос больше на будущее, не на прямо сейчас
[16:47:21] *** Игорь Синицын — Отключён (Какие ваши проблемы?)
[16:47:41] *** Игорь Синицын — Доступен (Какие ваши проблемы?)
[17:17:55] *** Игорь Синицын — Отключён (Какие ваши проблемы?)
[17:18:13] *** Игорь Синицын — Доступен (Какие ваши проблемы?)
[17:43:26] <Konstantin Alexandrov> если что от вас ничего не пришло:)
[17:44:57] <Игорь Синицын> > sinix (16:23:06 31/03/2011)
В сервелате есть BackgroundWorker?
Если нет — в фоновый поток надо передать ссылку на диспатчер и дёргать dispatcher.Invoke|BeginInvoke чтобы выполнить код в основном потоке.
Разумеется, из фонового потогка нельзя напрямую работать с контролами.

sinix (16:24:16 31/03/2011)
Если есть возможность — подумать над тем. чтобы обмена было как можно меньше — так проще писать код и проще откатиться, если что-то пойдёт не так.
[17:47:44] <Konstantin Alexandrov> BackgroundWorker да есть
[17:55:52] <Игорь Синицын> Ну тогда его можно и использовать. Дубовая штука, зато неправильно её использовать тяжело
[17:56:40] <Konstantin Alexandrov> огаг как буду юзать, спрошу у вас. спасибо
wormpicturesque
дык вот. есть у мну WebClient который работает асинхронно. мне надо отлавливать окончание загрузки файла. Для эжтого я сделал класс с event на который подписываюся в пользоват ельском коде. Внимание вопрос — что концептуально я сделла не так?;)
[10:21:52] <Игорь Синицын> Блин. Я только проснулся. Нельзя так сразу
[10:21:56] <Konstantin Alexandrov> ог
[10:22:26] <Konstantin Alexandrov> привет как дела? ;). ..далее текст вопроса ...
[10:25:21] <Игорь Синицын> Не надо так, я пока что небодр и невесел.
Я прально понял — вы закачиваете файл, а затем дёргаете событие на который подписывается клиентский код (не код из класса)?

Абсолютно нормально (и единственное простое в использовании решение), только надо убедиться, что событие вызывается в основном UI-потоке.
[10:26:15] <Konstantin Alexandrov> гм. простите. что событие вызывается в основном UI-потоке // подробнее можно?
[10:30:34] <Игорь Синицын> Надо смотреть документацию. Если webClient дёргает своё событие в главном потоке — ничего делать не надо. Если дёргает в фоновом — надо использовать Dispatcher (любой контрол/FrameworkObject от него отнаследован, если код универсальный — надо использовать SynchronizationContext) и вызвать метод Invoke (или Send — для SyncContext). В параметр метода передаётся делегат, который выполнится в основном потоке. В делегате и вызывать событие.
[10:31:15] <Игорь Синицын> SyncContext, разумеется, надо запоминать в основном потоке.
[10:39:08] <Konstantin Alexandrov> судя по сорсам — "AsyncOperation asyncOperation = AsyncOperationManager.CreateOperation(userToken);" — это как понимаю дергает в фоновом