Сделать тест на windows forms
Создать тест знаний внутри проекта Windows Forms
Всем добра! Люди, помогите, в долгу не останусь, есть черновая программка для курсовой, нужно.
Как сделать скролл в Windows Forms?
Как в с++ windows forms сделать в форме скролл, который бы действительно прокручивал форму вниз.
Как сделать привилегии в windows forms
Не могу понять как сделать для каждого пользователя свою привилегию. Допустим есть окно.
Давид Монтиков, отвратительно поставленный вопрос!
варианты ответов (под стать вопросу):
1) руками
2) запрограммировать
3) легко!
выбирай любой.
задавай конкретные вопросы! «как готовить еду?» и «сколько воды надо на 200 грамм риса, чтобы он получился рассыпчатым?» — это, согласись, абсолютно разный подход.
а ну раз так, то вот:
1) код нужен на C# (раз уж ты в этом разделе пишешь)
2) использовать нужно либо файлы (подозреваю, что лучше всего использовать бинарную сериализацию — ответы на вопросы выцепить будет чуть-чуть сложнее тем, кто решит ломануть), либо БД (хватит и MS Access в случае чего)
3) в самом примитивном варианте на форме будут нужны:
— 1 лейбл (сам вопрос)
— 1 кнопка (для подтверждения ответа, но можно обойтись и без нее)
— несколько радиобаттонов (по числу вариантов ответа на каждый вопрос)
а дальше — пока у тебя не будет конкретных вопросов (причем не из серии «как мне использовать лейбл», «какой код забивать в кнопку» и т.п., а нормальных вопросов, в которых ты покажешь что сам сделал хоть что-нибудь) — вряд ли кто-нибудь тебе будет помогать.
Ответы на 7 самых частых вопросов по WinForms
Ответы на 7 самых частых вопроса по WinForms
1. Как создать вторую форму
Любая форма представляет из себя класс, унаследованный от Form.
Экземпляр главной формы создается в файле Program.cs по умолчанию.
При этом ShowDialog() блокирует главную форму, т.е. управление вернется в нее, только по закрытию второй формы, а Show() просто отображает вторую форму, т.е. будут доступны обе формы.
2. Как передать данные из одной формы в другую
Часто возникает необходимость передать данные из одной формы в другую, я придумал 7 способов, у каждого свои недостатки и достоинства.
2.1 Изменение модификатора доступа (добавлено 24 июля 2017: лучше воздержаться от применения данного способа)
В Form2 Установить модификатор доступа для контрола/поля public
В любом месте Form1
+ Самый быстрый в реализации и удобный способ
— Противоречит всем основам ООП
— Возможна передача только из более поздней формы в более раннюю
— Форма f показывается только с использованием ShowDialog(), т.е. в первую форму управление вернется только по закрытию второй. Избежать этого можно, сохранив ссылку на вторую форму в поле первой формы
2.2 Использование открытого свойства/метода. Способ очень похож на первый
В классе Form2 определяем свойство (или метод)
+ Противоречит не всем основам ООП
— Минусы те же
2.3 Передача данных в конструктор Form2
Изменяем конструктор Form2
+ Простой в реализации способ
+ Не нарушает ООП
— Возможна передача только из более ранней формы в более позднюю
2.4 Передача ссылки в конструктор
Изменяем конструктор Form2
+ Доступ ко всем открытым полям/функциям первой формы
+ Передача данных возможна в обе стороны
— Нарушает ООП
2.5 Используем свойство ‘родитель’
При создании второй формы устанавливаем владельца
+ Доступ ко всем открытым полям/функциям первой формы
+ Передача данных возможна в обе стороны
+ Не нарушает ООП
2.6 Используем отдельный класс
Создаем отдельный класс, лучше статический, в основном namespace, т.е. например в файле Program.cs
+ Самый удобный способ, когда данные активно используются несколькими формами.
2.7 Использование функций обратного вызова
2.7.1 Передача метода в конструктор
Создаем в основном namespace делегат
Непонятен пункт 2.5 из «Ответы на 7 самых частых вопросов по WinForms»
Вопрос по пункту 2.5 из «Ответы на 7 самых частых вопроса по WinForms». Вот код: // в форме 1.
Ответы на 7 самых частых вопросов по Windows Forms, C++/CLI Edition
Ответы на 7 самых частых вопросов по Windows Forms C++/CLI Edition Эта статья является.
Ответы на 7 самых частых вопросов по Windows Forms, C++/CLI Edition — свой способ передачи данных между формами
Способ с использованием макросов. Средней сложности в реализации и понимании, не знаю, нарушает ли.
Список Ваших вопросов Платону Щукину и его ответы
Данная тема будет предназначана для публикования Ваших вопросов и ответов с службой поддержки.
+ Наиболее гибкий способ передачи данных
— Сложен в реализации и понимании
3. Как получить доступ к контролу из другого потока
С элементами управления можно работать только из того потока в котором они были созданы. При обращении из другого потока будет сгенерировано исключение InvalidOperationException с текстом «Cross-thread operation not valid: Control accessed from a thread other than the thread it was created on.» (Недопустимая операция в нескольких потоках: попытка доступа к элементу управления не из того потока, в котором он был создан.). Возможные решения:
3.1 Простой и неправильный способ
Отменяем проверку, из какого потока используется контрол
Для одного раза может и сработать, но делать так крайне не рекомендуется.
3.2 Использование методов Invoke/BeginInvoke
Эти методы выполняют указанные делегаты в том потоке, в котором контрол был создан.
Invoke вызывает делегат синхронно, BeginInvoke — асинхронно.
Чтобы определить, требуется ли Invoke используйте свойство InvokeRequired.
Например, объявляем делегат
Позволю себе дополнить вопрос по связи и передаче данных двух форм, формы и класса. Подобные темы возникают очень часто, но в данном FAQ нет главного примера — использование событий, которые, как я считаю, являются самым верным способом для передачи к-либо данных.
Итак, вот участки кода. Для лучшего понимания прикрепляю архив с проектом. Имеем:
1.Главная форма, с двумя датагридами и двумя кнопками.
2.Дополнительная форма с тремя текстовыми полями и одной кнопкой.
3.Отдельный класс.
Логика работы: по нажатию на кнопку получения данных из доп.формы, открывается окно второй формы. Заполняем текстовые поля, и по нажатию кнопки форма закрывается, а данные из полей оказываются в гриде 1. По нажатию кнопки получения данных из класса создается объект класса, в конструкторе класса формируется таблица, которая при вызове метода класса передает данные в осн. форму, где они отображаются в гриде 2.
Также уточню, что передачу таблиц я выбрал для наглядности, и передавать таким способом можно все что угодно, используя приведенный шаблон
PS.В моем коде специально не использовались анонимные делегаты и лямбда, для облегчения восприятия новичками.
Код основной формы:
Вложения
 | FormsCommunicatoinTest.rar (51.7 Кб, 1461 просмотров) |
| Комментарий модератора | ||
| ||
| Меню пользователя @ tezaurismosis |
| Читать блог |
Найти вероятность того, что студент, выбирая ответы наугад, ответит на 10 вопросов
Машина-экзаменатор содержит 12 вопросов, на каждый из которых предлагается 4 варианта ответа.
Ответы на Комплект вопросов сертиф экз «1С:Бухгалтерия 8» ред. 1.6
У кого есть ответы на «Комплект вопросов сертифицированного экзамена по программе «1С:Бухгалтерия.
на ответы@mail.ru на один из моих вопросов, где я уточнил, что использую ubuntu 10.10 мне сказали, что.
на ответы@mail.ru на один из моих вопросов, где я уточнил, что использую ubuntu 10.10 мне сказали.
Найти два самых больших и самых маленьких элементов массива
Одномерные массивы для обычных массивов и для класса Array. Составить программу нахождения двух.
Модульное тестирование Windows forms C#
подскажите есть ли возможность произвести модульное тестирование приложений на основе Windows Forms? Не нашла в интернете какой — то определенности для себя. Смотрела туториалы по модульному тестированию, как только дошла до вызова класса — встряла. При вызове класса Form, он не отображается, выходит ошибка о том, что данный класс не существует, хотя ссылку на проект в тесте, который необходимо тестировать я добавляла.
2 ответа 2
Для примера возьмем простейший пример вычисления данных прямоугольника.
Работать будем с уклоном в TDD (Test driven development или «Разработка на основе тестирования»). Создадим решение с проектом, набросаем интерфейс программы. 
Добавьте в решение проект библиотеки 
Добавьте в решение тестовый проект xUnit 
Добавьте ссылки на проект библиотеки в тестовый и WinForms проекты 
Создайте в проекте библиотеки класс MainFormViewModel для главного окна нашей программы.
В проекте тестов переименуйте UnitTest1 в MainFormViewModelTests и добавьте using Rectangle.Core; . Напишите пару таких тестов
Т.к. в классе не было создано соотв. свойств, то действуйте так 
- Теперь запустите тесты
и. тесты не прошли. Это нормально так и должно быть. Исправьте класс так
Добавьте еще два теста
и два соответствующих метода в класс въюмодели. Тесты не пройдут. Подправьте так методы
Убедитесь, что тесты теперь проходят. Далее реализуете методы уже так, чтобы они действительно вычисляли нужные данные и проверяете, что все тесты проходят. Далее будет по принципу «Как нарисовать сову»
Вот такие тесты
К такому тестируему классу
Теперь используем класс въюмодели так
Всё! Ссылка на этот пример здесь.
Обычно новички в программировании слабо различают такую вещь, как слои приложения и часто смешивают воедино бизнес-логику и визуальное представление. Такой код сложнее и в поддержке, рефакторинге и в тестировании.
Типичный пример — в обработчик клика на кнопку помещают логику (открывают соединение с FTP-сервером, производят сложные расчёты и т.п.), можете просто посмотреть сами.
На примере приложения-калькулятора: вы можете нафигачить код прямо в своё winforms-приложение, но если вы выделите класс калькулятора без привязки ко всем этим object sender, EventArgs e то ваш код можно будет весьма просто тестировать, а потом этот протестированный класс калькулятора многократно использовать — хоть в консольном приложении, хоть в winforms, хоть в WPF или веб-приложении asp.net mvc.
А потому, пока у вас вообще нет никаких тестов — начните с простых модульных тестов без всякой привязки к (интеграционному) тестированию UI-интерфейса winforms. А для этого вам нужно будет отделить логику от представления.
Кратко и сжато как тестировать код есть например здесь: Как писать юнит тесты?
Можете в отдельные проекты не выносить, но убрать зависимость от классов winforms — важно.
Как перевести понятия MVP/MVC в термины WinForms?
В описании паттерна MVP (Model-View-Presenter) сказано следующее:
- Model (Модель) — предоставляет данные для пользовательского интерфейса.
- View (Представление) — реализует отображение данных (Модели) и маршрутизацию пользовательских команд или событий Presenter-у.
- Presenter — управляет Моделью и Представлением. Например извлекает данные из Модели и форматирует их для отображения в Представлении.
Что в WinForms приложениях соответствует View и Presenter?
3 ответа 3
Стандартная лапша — в code-behind форм в обработчиках событий производится запросы к модели, какая-то работа и визуализация результата.
В mvp модель остается моделью, то есть это набор бизнес-логики, а код в форме делится на View и Presenter
View — это формы, code-behind этих форм, где производится работа по визуальной составляющей, а также туда же сводятся подписки на события контролов
Presenter — туда вынесен рабочий код, который не являются частью визуализации. View содержит ссылку на presenter и вызывает его методы. А presenter содержит ссылку на View через интерфейс
То есть View в обработчиках событий контролов делегирует presenter-у «сделай это», а presenter содержит управляющий код, который опросит модель, получит результат и потом дернет View и скажет ему «отрисуй такое то»
Таким образом визуализирующий и управляющий код разделяются.
По просьбе @Stack привожу пример. Псевдошарпокод.
Имеем простую модель (она же бизнес логика). Просто читает файл планет
Далее интерфейс представления
и представление winforms
для WPF код в общем то идентичен Winforms кроме класса родителя и сигнатур обработчиков событий (хотя лучше все таки MVVM)
за IMainView может быть скрыто что-угодно — от простой формы winforms до самописной системы отрисовки на удаленной машине.
- «Логика интерфейса» по факту делится на «презентационную логику» и собственно «логику визуализации». В «презентационную логику» входит решение, что делать по нажатию на кнопку и что делать с результатом — по сигналу от UI работает с моделью и просит потом «логику визуализации» отобразить результат. В «логику визуализации» входит отображение того, что просят — контролы, события, установки полей у контролов, кобминирование контролов и так далее.
- Презентер не имеет прямой ссылки на представление, поэтому детали отображения на UI инкапсулированы (опять же чистота кода, вся сложность спрятана) и возможность заменять представление на другое.
- Презентер не имеет прямой ссылки на представление, а значит вместо представлениям можно подсунуть заглушку и протестировать презентер. Тестировать же логику интерфейса без такого разделения крайне сложно (нужно тыкать мышью руками или автоматикой и считывать как то результаты с экрана)
Решил добавить еще один ответ, потому что размер комментариев ограничен, а у @Stack все перемешалось в голове и мой пост отвечает не на вопрос «как», а на «где и почему?»
Цель MVP не сделать возможность подмены UI (для этого просто нужно менять UI), а разделить ответственности и обеспечить тестируемость.
Допустим нам нужно написать приложение под разные абстрактные платформы.
у нас разные UI на разных платформах.
- Делаем проект-ядро, где будет логика приложения и создаем по проекту UI на каждую платформу и при компиляции оно разберется
- Делаем UI на кроссплатформенных контролах
прячем за фасадом (паттерн такой) любые реализации UI приводя их к обобщенному виду фасада. Банально делается класс/интерфейс за которым прячется реальный UI. но это не MVP, а просто сокрытие сложности и зависимостей
Для подобной же цели служит паттерн «мост». Отличие от варианта с «фасадом», что, вместо сокрытия реализации за фасадом, более ярко выражена связующая шина между приложением и графическим приложением и независимость реализации обоих частей
А где же MVP?
Когда задача подмены UI решена, то нужно реализовать эти самые UI.
Допустим одна из наших UI на WinForms. В силу особенностей Visual Studio мы получаем на выходе в Code-Behind основной формы кучу методов (евент-хендлеры и кучу приватных методов реализующих логику интерфейса). Мало того, что это лапша кода, так еще все это невозможно тестировать — для тестирования нужно тыкать на кнопки и отслеживать изменение GUI, что сложно.
Возникает желание навести порядок. Это можно сделать 101 способом (MVC/MVP/MVVM/MVVMC/свой вариант), просто некоторые в конкретном случае будут менее удобны чем другие, а ведь еще хочется не терять визуальный дизайнер студии. И паттерн MVP хорошо подходит для UI, где нет нормальных биндингов, потому что прост и прячет кучу визуализационного кода за интерфейсом. Это и Winforms, и я вот под андроид тоже использую MVP.
вообще то это очевидное решение — разделить godobject на классы и удалить зависимости от реализаций, спрятав за интерфейсами. Типичные варианты решений и обозвали паттернами
Разделив визуализацию и логику мы получаем возможность тестировать ту логику, что вошла в презентер (а туда входит вся управляющая логика взаимодействия с моделью и управления визуализацией). Тестировать просто, ведь презентер просто класс с зависимостями. Если же еще хочется тестировать кнопочки, то winium в руки, но тестировать UI всегда сложно
«как в вашем примере тестировать Presenter. из-за new в методе LoadPlanets() < var planets=new PlanetReader(). >его невозможно тестировать отдельно от конкретной модели» @Stack
Для этого используется то, что называется «принцип инверсии зависимостей». Еще одно очевидное решение, имеющее свое название
Делаем интерфейс IPlanetReader и выносим его в конструктор. Или же используем ServiceLocator. Или же IoC-контейнеры. Или любой другой вариант. MVP всего лишь вариант разделения на ответственности «где за что отвечает», а реализация ответственностей уже не входит в него и там полная свобода действий
тестирование UI это проверка того как смотрятся шрифты -это вообще тестируется только глазами. мы же говорим про автоматическое тестирование.
Тестирование через эмуляцию нажатий кнопок и считыванием информации с контролов. недостатки: сложность считывания даннных (мало ли какие контролы), сложность изоляции (для проверки, что пользователь существует нам нужно подсунуь базу где пользователь есть), скорость работы (из-за того, что полностью работают все слои приложения). Не выявляет функциональные ошибки, когда делает не то, но показывает правильный результат.
При тестировании презентера можно изолировать и подсунуть любые данные, проверить что идет правильный порядок вызовов модели. Пишется намного проще, есть изоляция и высокая скорость работы. В идеале должно быть больше различных тестов, но выбор необходимых тестов определяется возможностями (тесты бизнесу не нужны. они нужны программисту и за них платить не любят).
Лично мне куда проще тестировать презентер (он выявляет функциональные ошибки и за них мне по шапке дают), а кривизна дизайна не фатальна (вся логика в презентере, в представлении логики практически нет и сломать его сложнее, а вреда от этого минимум).
