Как создать окно в c

Создание окна

Класс окна определяет набор поведений, которые могут быть общими для нескольких окон. Например, в группе кнопок каждая кнопка имеет аналогичное поведение, когда пользователь нажимает кнопку. Конечно, кнопки не полностью идентичны; каждая кнопка отображает собственную текстовую строку и имеет собственные координаты экрана. Данные, уникальные для каждого окна, называются данными экземпляра.

Каждое окно должно быть связано с классом окна, даже если программа только когда-либо создает один экземпляр этого класса. Важно понимать, что класс окна не является «классом» в смысле C++. Скорее, это структура данных, используемая внутренне операционной системой. Классы окон регистрируются в системе во время выполнения. Чтобы зарегистрировать новый класс окна, начните с заполнения структуры WNDCLASS :

Необходимо задать следующие элементы структуры:

• lpfnWndProc — это указатель на определяемую приложением функцию, называемую процедурой окна или «окном». Процедура окна определяет большую часть поведения окна. Далее мы подробно рассмотрим процедуру окна. На данный момент просто рассматривайте это как прямую ссылку.
• hInstance — это дескриптор экземпляра приложения. Получите это значение из параметра hInstancewWinMain.
• lpszClassName — это строка, идентифицирующая класс окна.

Имена классов являются локальными для текущего процесса, поэтому имя должно быть уникальным только в процессе. Однако стандартные элементы управления Windows также имеют классы. Если вы используете любой из этих элементов управления, необходимо выбрать имена классов, которые не конфликтуют с именами классов элементов управления. Например, класс окна для элемента управления «Кнопка» называется «Button».

Структура WNDCLASS содержит другие элементы, не показанные здесь. Их можно задать равным нулю, как показано в этом примере, или заполнить их. В документации WNDCLASS подробно описывается структура.

Затем передайте адрес структуры WNDCLASS в функцию RegisterClass . Эта функция регистрирует класс окна в операционной системе.

Создание окна

Чтобы создать новый экземпляр окна, вызовите функцию CreateWindowEx :

Подробные описания параметров можно прочитать в документации по функции CreateWindowEx , но вот краткий обзор:

• Первый параметр позволяет указать некоторые необязательные поведения для окна (например, прозрачные окна). Задайте для этого параметра нулевое значение для поведения по умолчанию.
• CLASS_NAME — это имя класса окна. Это определяет тип создаваемого окна.
• Текст окна используется различными способами различными типами окон. Если в окне есть строка заголовка, текст отображается в строке заголовка.
• Стиль окна — это набор флагов, определяющих внешний вид окна. Константой WS_OVERLAPPEDWINDOW фактически является несколько флагов в сочетании с битовой или. Вместе эти флаги дают окну строку заголовка, границу, системное меню и кнопки «Свернуть » и «Развернуть «. Этот набор флагов является наиболее распространенным стилем окна приложения верхнего уровня.
• Для положения и размера константная CW_USEDEFAULT означает использование значений по умолчанию.
• Следующий параметр задает родительское окно или окно владельца для нового окна. Задайте родительский объект, если вы создаете дочернее окно. Для окна верхнего уровня задайте значение NULL.
• Для окна приложения следующий параметр определяет меню для окна. В этом примере не используется меню, поэтому значение равно NULL.
• hInstance — это дескриптор экземпляра, описанный ранее. (См . WinMain: точка входа приложения.)
• Последний параметр — это указатель на произвольные данные типа void*. Это значение можно использовать для передачи структуры данных в процедуру окна. Мы покажем один из возможных способов использования этого параметра в разделе «Управление состоянием приложения».

Функция CreateWindowEx возвращает дескриптор в новое окно или ноль, если функция завершается ошибкой. Чтобы отобразить окно( то есть сделать окно видимым, передайте дескриптор окна в функцию ShowWindow :

Параметр hwnd — это дескриптор окна, возвращаемый CreateWindowEx. Параметр nCmdShow можно использовать для свернуть или развернуть окно. Операционная система передает это значение программе через функцию wWinMain .

Ниже приведен полный код для создания окна. Помните, что WindowProc это по-прежнему просто прямое объявление функции.

Поздравляем, вы создали окно! Сейчас окно не содержит содержимого или не взаимодействует с пользователем. В реальном приложении графического пользовательского интерфейса окно будет реагировать на события от пользователя и операционной системы. В следующем разделе описывается, как сообщения окна обеспечивают такой интерактивный вид.

Окна на чистом WinAPI. Или просто о сложном

Казалось бы, что WinAPI уходит в прошлое. Давно уже существует огромное количество кросс-платформенных фреймфорков, Windows не только на десктопах, да и сами Microsoft в свой магазин не жалуют приложения, которые используют этого монстра. Помимо этого статей о том, как создать окошки на WinAPI, не только здесь, но и по всему интернету, исчисляется тысячами по уровню от дошколят и выше. Весь этот процесс разобран уже даже не по атомам, а по субатомным частицам. Что может быть проще и понятнее? А тут я еще…

Но не все так просто, как кажется.

Почему о WinAPI сейчас?

В один прекрасный момент, изучая потроха одной из игр в весьма неплохом эмуляторе NES, я подумал: Вроде неплохой такой эмуль, а в отладчике нет такой простой вещи, как навигация по кнопкам клавиатуры, которая есть в любом нормальном отладчике.

Здесь я не зря дал ссылку на репозиторий, т.к. видно, что ребята столкнулись с проблемой, о которой речь пойдет ниже, но так и не решили ее.

О чем это я? А вот об этом кусочке кода:

Таким образом, авторы хотели добавить поддержку клавиатуры, но суровая реальность недр архитектуры диалоговых окон в Windows жестко пресекла такую самодеятельность. Те, кто пользовался эмулятором и отладчиком в нем, хоть раз видели это сообщение?
В чем же проблема?

Ответ такой: так делать нельзя!

И, возвращаясь, к изначальному вопросу о WinAPI: очень много популярных, и не очень, проектов продолжают его использовать и в настоящее время, т.к. лучше, чем на чистом API многие вещи не сделать (тут можно бесконечно приводить аналогии вроде сравнения высокоуровневых языков и ассемблера, но сейчас не об этом). Да и мало ли почему? Просто используют и все тут.

О проблеме

Диалоговые окна упрощают работу с GUI, одновременно лишая нас возможности сделать что-то самостоятельно. Например, сообщения WM_KEYDOWN/WM_KEYUP, приходящие в оконную процедуру, «съедаются» в недрах DefDlgProc, беря на себя такие вещи, как: Навигация по Tab, обработка клавиш Esc, Enter, и т.д. Кроме того, диалоги не нужно создавать вручную: проще, ведь, набросать кнопок, списков, в редакторе ресурсов, вызвать в WinMain CreateDialog/DialogBox и все готово.

Обойти такие мелкие неприятности просто. Есть, как минимум, два вполне легальных способа:

1. Создать свой собственный класс через RegisterClassEx и в процедуре обработки класса схватывать WM_KEYDOWN, перенаправлять в процедуру обработки самого диалога. Да-да! Можно создавать диалоги со своим собственным классом, и встроенный в VS редактор даже позволяет задавать имя класса для диалога. Вот только кто об этом знает и этим пользуется?
   Минус очевиден: Нужно регистрировать еще один класс, иметь на 1 CALLBACK процедуру больше, суть которой будет всего-навсего в трансляции пары сообщений. Кроме того, мы не будем знать куда их транслировать, и придется городить костыли.
2. Использовать встроенный механизм акселераторов. И нам даже не придется менять код диалоговой процедуры! Ну, разве что, добавить одну строчку в switch/case, но об этом ниже.

Tutorials?

Не побоюсь сказать, что все туториалы по созданию окон через WinAPI начинаются с такого незамысловатого кода, обозначая его, как «цикл обработки сообщений» (опущу детали по подготовке класса окна и прочую обвязку):

Здесь действительно все просто:

1. GetMessage() выхватывает очередное сообщение из очереди, и ключевой момент: блокирует поток, если в очереди пусто.
2. TranslateMessage() из WM_KEYDOWN/WM_KEYUP формирует сообщения WM_CHAR/WM_SYSCHAR (они нужны, если кто-то хочет сделать свой редактор текста).
3. DispatchMessage() отправляет сообщение в оконную процедуру (если таковая существует).

И ниже приводится пример правильного цикла.

Стоит сказать, что в шаблонах VS для Win32 приложений, написан именно такой неправильный цикл. И это очень печально. Ведь мало кто будет вникать в то, что сделали сами авторы, ведь это априори правильно. И неправильный код множится вместе с багами, которые очень сложно отловить.

После этого фрагмента кода, как правило, следует рассказ про акселераторы, и добавляется пара новых строчек (учитывая замечание в MSDN, предлагаю сразу писать правильный цикл):

Этот вариант я видел чаще всего. И он (та-дам) снова неправильный!

Сперва о том, что изменилось (потом о проблемах этого кода):

В первой строчке из ресурсов загружается таблица клавиш, при нажатии на которые, будет формироваться сообщение WM_COMMAND с соответствующим id команды.

Собственно TranslateAccelerator этим и занимается: если видит WM_KEYDOWN и код клавиши, которые есть в этом списке, то (опять же ключевой момент) будет формировать сообщение WM_COMMAND (MAKEWPARAM(id, 1)) и отправлять в соответствующую для дескриптора окна, указанного в первом аргументе, процедуру обработки.

Из последней фразы, думаю, стало понятно, в чем проблема предыдущего кода.
Поясню: GetMessage выхватывает сообщения для ВСЕХ объектов типа «окно» (в число которых входят и дочерние: кнопки, списки и прочее), а TranslateAccelerator будет отправлять сформированную WM_COMMAND куда? Правильно: обратно в кнопку/список и т.д. Но мы обрабатываем WM_COMMAND в своей процедуре, а значит нам интересно ее получать в ней же.

Ясно, что TranslateAccelerator надо вызывать для нашего созданного окна:

И вроде все хорошо и замечательно теперь: мы разобрали все детально и все должно работать идеально.

И снова нет. 🙂 Это будет работать правильно, пока у нас ровно одно окно — наше. Как только появится немодальное новое окно (диалог), все клавиши, которые будут в нем нажаты оттранслируются в WM_COMMAND и отправляться куда? И опять же правильно: в наше главное окно.

На этом этапе предлагаю не городить костылей по решению этой тупиковой ситуации, а предлагаю рассмотреть вещи, которые уже реже (или почти не встречаются) в туториалах.

IsDialogMessage

По названию этой функции можно подумать, что она зачем-то определяет: относится данное сообщение диалогу или нет. Но, во-первых, зачем нам это знать? А во-вторых, что с этой информацией нам делать дальше?

На самом деле, делает она чуть больше, чем следует из названия. А именно:

• Осуществляет навигацию по дочерним контролам кнопками Tab/Shift+Tab/вверх/вниз/вправо/влево. Плюс еще кое-что, но этого нам достаточно
• По нажатии на ESC формирует WM_COMMAND( IDCANCEL )
• По нажатии на Enter формирует WM_COMMAND( IDOK ) или нажатие на текущую кнопку по умолчанию
• Переключает кнопки по умолчанию (рамочка у таких кнопок чуть ярче остальных)
• Ну и еще разные штуки, которые облегчают пользователю работу с диалогом

Во-вторых, она нам облегчит жизнь по всем остальным пунктам, перечисленным в списке (и даже немного больше).

Вообще, она используется где-то в недрах Windows для обеспечения работы модальных диалоговых окон, а программистам дана, чтобы вызывать ее для немодальных диалогов. Однако мы ее можем использовать где угодно:

Т.е. теперь, если мы оформим цикл так:

То наше окошко будет иметь навигацию, как в родном диалоге Windows. Но теперь мы получили два недостатка:

1. Этот код также будет хорошо работать только с одним (немодальным) окном;
2. Получив все достоинства диалоговой навигации, мы лишаемся прелестей в виде сообщений WM_KEYDOWN/WM_KEYUP (только для самого окна, а не для дочерних контролов);

Пора поговорить о том, чего нет в туториалах и ответах.

Как правило (как правило! Если кому-то захочется большего, то можно регистрировать свой класс для диалогов и работать так. И, если же, кому-то это интересно, я могу дополнить этим статью) WM_KEYDOWN хотят тогда, когда хотят обработать нажатие на клавишу, которая выполнит функцию в независимости от выбранного контрола в окне — т.е. некая общая функция для всего данного конкретного диалога. А раз так, то почему бы не воспользоваться богатыми возможностями, которые нам сама WinAPI и предлагает: TranslateAccelerator.

Везде используют ровно одну таблицу акселераторов, и только для главного окна. Ну действительно: цикл GetMessage-loop один, значит и таблица одна. Куда еще их девать?

На самом деле, циклы GetMessage-loop могут быть вложенными. Давайте еще раз посмотрим описание PostQuitMessage:

Таким образом, выход из GetMessage-loop осуществится, если мы вызовем PostQuitMessage в процедуре окна. Что это значит?

Мы можем для каждого немодального окна в нашей программе создавать свой собственный подобный цикл. В данном случае DialogBoxParam нам не подходит, т.к. оно крутит свой собственный цикл и повлиять мы на него не можем. Однако если создадим диалог через CreateDialogBoxParam или окно через CreateWindow, то можно закрутить еще один цикл. При этом в каждом таком окне и диалоге мы должны вызывать PostQuitMessage:

Обратите внимание: теперь для каждого нового окна в нашей программе мы можем добавить в обработку собственную таблицу акселераторов. WM_QUIT будет выхватывать GetMessage из цикла для диалога, а внешний цикл его даже не увидит. Почему так происходит?

Дело в том, что внешний цикл «встал» на вызове DispatchMessage, который вызвал нашу процедуру, которая крутит свой собственный внутренний цикл GetMessage с таким же DispatchMessage. Классический вложенный вызов (в данном случае DispatchMessage). Посему внешний цикл не получит WM_QUIT и не завершится на этом этапе. Все будет работать стройно.

Но и тут есть свои недостатки:
Каждый такой цикл будет обрабатывать сообщения только для «своего» окна. Про другие-то мы здесь не знаем. А значит, если где-то объявится еще один цикл, то все остальные окна не будут получать нужной обработки своих сообщений парой TranslateAccelerator/IsDialogMessage.

Что ж, пора учесть все эти замечание и написать наконец правильную обработку всех сообщений от всех окон нашей программы. Хочу заметить, что ниже рассматривается случай для одного потока. Т.к. каждый поток имеет свою очередь сообщений, то для каждого потока придется создавать свои структуры. Делается это весьма тривиальными изменениями в коде.

Делаем красиво

Т.к. правильная постановка задачи является половиной решения, то сперва надо эту самую задачу правильно же и поставить.

Во-первых, было бы логично, что только активное окно принимает сообщения. Т.е. для неактивного окна мы не будем транслировать акселераторы и передавать сообщения в IsDialogMessage.

Во-вторых, если для окна не задана таблица акселераторов, то транслировать нечего, будем просто отдавать сообщение в IsDialogMessage.

Создадим простой std::map, который будет мапить дескриптор окна в дескриптор таблицы акселераторов. Вот так:

И по мере создания окон будем в него добавлять новые окна с дескриптором на свою любимую таблицу (или нуль, если такая обработка не требуется).

Ну и после закрытия окна удалять. Вот так:

Теперь, как создаем новый диалог/окно, вызываем AddAccelerators( hNewDialog, IDR_MY_ACCEL_TABLE ). Как закрываем: DelAccel( hNewDialog ).

Список окон с нужными дескрипторами у нас есть. Немного модифицируем наш основной цикл обработки сообщений:

Значительно лучше! Что же там в HandleAccelArray и зачем там GetActiveWindow()?

Есть две функции, возвращающих дескриптор активного окна GetForegroundWindow и GetActiveWindow. Отличие первой от второй вполне доходчиво описано в описании второй:

Если первая будет возвращать дескриптор любого окна в системе, то последняя только того, которое использует очередь сообщений нашего потока. Т.к. нас интересуют окна только нашего потока (а значит те, которые будут попадать в нашу очередь сообщений), то и возьмем последнюю.

Так вот HandleAccelArray, руководствуясь переданным ей дескриптором на активное окно, ищет это самое окно в нашей мапе, и если оно там есть, отдает это сообщение на трансляцию в TranslateAccelerator, а затем (если первый не увидел нужного) в IsDialogMessage. Если и последняя не обработала сообщение, то возвращаем FALSE, чтобы пройти по стандартной процедуре TranslateMessage/DispatchMessage.

Теперь каждое дочернее окно вправе добавить себе любимую таблицу акселераторов и спокойно ловить и обрабатывать WM_COMMAND с нужным кодом.

А что там еще об одной строчке в коде обработчика WM_COMMAND?

Обычно код обработки WM_COMMAND выглядит так:

Теперь можно написать так:

И теперь, возвращаясь к тому же fceux, добавив всего одну строчку в код обработки команд от кнопок, мы получим желаемое: управлять дебагером с клавиатуры. Достаточно добавить небольшую обертку вокруг главного цикла сообщений и новую таблицу акселераторов с нужными соответствиями VK_KEY => IDC_DEBUGGER_BUTTON.

P.S.: Мало кто знает, но можно создавать свою собственную таблицу акселераторов, а теперь и применять ее прямо налету.

P.P.S.: Т.к. DialogBox/DialogBoxParam крутит собственный цикл, то от при вызове диалога через них акселераторы работать не будут и наш цикл (или циклы) будет «простаивать».

P.P.P.S.: После вызова HandleAccelWindow мап l_mAccelTable может измениться, т.к. TranslateAccelerator или IsDialogMessage вызывают DispatchMessage, а там может встретиться AddAccelerators или DelAccel в наших обработчиках! Поэтому лучше его после этой функции не трогать.

Пощупать код можно здесь. За основу был взят код, генерируемый из стандартного шаблона MS VS 2017.

2.2 Создание первого оконного приложения в .NET. "Убегающее окно".

Создавая данную программу, мы рассмотрим основные принципы создания оконных приложений в C#, а также методы реализации с помощью них каких-либо конечных целей: в нашем случае — это забавно убегающее окно.

Создайте новый проект, в качестве типа шаблона установите приложение Windows Forms, как показано на рисунке 1:
Рисунок 1. Создание нового проекта.
Назовите проект RandWindow и нажмите кнопку ОК.

1. Окно Toolbox (Панель элементов управления) — элементы управления вы можете разместить на создаваемой форме.
2. Окно Solution Explorer (Обозреватель решений) — здесь вы сможете увидеть следующие узлы: Properties — настройки проекта, Links (Ссылки) — подключенные к проекту библиотеки, а также созданные и подключенные к проекту файлы исходных кодов (с расширением .cs) и подключенные к проекту формы (например, Form1).
3. Окно Class View (Окно классов) — здесь представлены все созданные в программе классы.
4. Окно Properties (Свойства) — выбрав любой элемент управления или даже форму, вы сможете увидеть все параметры данного объекта, а также изменить значения, установленные в них по умолчанию.

Создание оконных приложений сводится к созданию всех необходимых диалоговых окон, а также к размещению на них необходимых элементов. В дальнейшем мы настраиваем обработку событий, создаваемых пользователем, и настраиваем технические аспекты работы программы. В нашем случае сначала разместим все необходимые элементы управления на главной форме, после чего добавим обработчик события перемещения мыши и обработку нажатия кнопок.

Добавление новых элементов управления на форму

Итак, после того как вы ввели имя проекта, установили необходимый шаблон и нажали кнопку ОК, MS Visual Studio автоматически создаст каркас оконного приложения, после чего мы сможем добавить на него новые оконные элементы.

Для этого необходимо перетащить необходимый оконный элемент из окна инструментов (ToolBox).

Нашему окну потребуется 2 элемента поля для ввода, в которые мы будем выводить координаты указателя мыши, что облегчит нам понимание работы программы.

В центре окна будет находиться надпись, которую мы создадим с помощью элемента Label.
Снизу будут расположены 2 кнопки.

Немного растяните заготовку окна. Если вы нажмете на него правой кнопкой, то откроется контекстное меню. В нем нажмите на пункте свойства, после чего вы сможете изучить различные параметры окна, которые вы можете изменить. На рисунке 3 изображены самые (как правило) необходимые свойства:
Рисунок 3. Различные свойства окна (формы) в C# .NET.
Немного растяните заготовку окна и добавьте все необходимые элементы. На рисунке 4 вы можете увидеть их в окне ToolBox:
Рисунок 4. Перетаскивайте необходимые элементы из окна Toolbox на создаваемую форму.

Перейдите в свойства строки Label1, где измените текст на «Вы стремитесь сделать мир лучше?». Также измените тип шрифта, для этого найдите свойство Font (рис. 5).
Рисунок 5. Свойство Font элемента Label.
После чего установите тип шрифта Tahoma, ширину шрифта Bold и размер равный 16 (рис. 6).
Рисунок 6. Установки шрифта.
Далее измените текст на кнопках, используя свойство Text.

Полученная заготовка окна программы будет выглядеть следующим образом (рис. 7).
Рисунок 7. Форма будет выглядеть следующим образом.

Техническая часть работы программы

1. Сначала мы добавим обработчик события перемещения мыши и реализуем вывод ее координат x и y в два созданных поля ввода.
2. Далее мы создадим функции обработчики щелчка по каждой из клавиш мыши (особенно усердные пользователи все же смогут попасть по кнопке «Да, конечно!»).
3. Далее мы добавим код, реализующий случайное перемещение окна в том случае, если курсор приблизиться к кнопке «Да, конечно!».

Определение перемещения указателя мыши по форме

Щелкните непосредственно на части формы создаваемого приложения (НЕ на одном из элементов).

Теперь перейдите к свойствам формы с помощью щелчка правой кнопки мыши -> контекстное меню свойства.

Теперь необходимо перейти к списку возможных событий, которые может получать данное окно. Для этого щелкните на кнопке «Event» (события), как показано на рисунке 8:
Рисунок 8. Переход к списку возможных событий.
Когда пользователь передвигает указатель мыши по нашему окну, операционная система посылает сообщение программе с текущими координатами указателя. Они-то нам и нужны.

Чтобы назначить обработчик данного события, найдите строку MouseMove (рис. 9), после чего сделайте двойной щелчок в поле справа от нее – автоматически добавится обработчик события движения мыши и добавится функция Form1_MouseMove в коде нашей программы.
Рисунок 9. После двойного щелчка справа от MouseMove появиться данная строка, и автоматически совершится переход к коду функции-обработчика данного события.
Добавьте в эту функцию 2 строки, чтобы ее код стал выглядеть следующим образом.

Данная функция, обрабатывающая событие перемещения указателя мыши над формой, получает 2 параметра: объект отправитель и экземпляр класса MouseEventsArgs, содержащий информацию о координатах указателя мыши и других текущих свойствах.

textBox1 и textBox2 это экземпляры класса textbox, реализующие управление нашими элементами поля для ввода.

Член данных экземпляров Text позволяет установить текст в данных полях.

Таким образом, если теперь откомпилировать программу (F5), при перемещении указателя мыши по форме окна мы будем видеть координаты указателя (внутри формы), которые будут непрерывно изменяться.

Теперь вернемся к заготовке нашей формы. Для это щелкните на соответствующей закладке (Form1.cs [Конструктор]), как показано на рисунке 10:
Рисунок 10. Переход к конструктору форм C#.
Сделайте двойной щелчок по первой кнопке: Visual Studio автоматически добавит код обработки данной кнопки при нажатии.

Добавьте следующие строки кода:

Теперь снова вернитесь к конструктору и добавьте вторую кнопку, также с помощью двойного щелчка по ней.

Она будет содержать следующий код:

Как видите, здесь мы немного усложнили код вызова окна-сообщения, чтобы продемонстрировать то, как оно работает, более подробно. Все параметры передаваемые в функцию Show закомментированны в исходном коде.

Теперь нам осталось только реализовать перемещение окна в тот момент, когда мышь приближается к кнопке «Да, конечно».

Для этого мы добавим код в функцию:

private void Form1_MouseMove(object sender, MouseEventArgs)

Принцип очень прост: получая координаты движения мыши, мы проверяем не входят ли они в квадрат, очерчивающий нашу кнопку с небольшим запасом. Если да, то мы генерируем 2 случайных числа, которые будут использованы для перемещения окна.

Мы бы могли просто отслеживать сообщение о наведении указателя мыши на кнопку, но оно приходит с заметной задержкой, в связи с чем пользователь без особого труда нажмет на кнопку да, поэтому мы будем просто вычислять попадание курсора в зону вокруг кнопки.

Также нам понадобится объявить несколько "рабочих" переменных, которые мы будем в дальнейшем использовать.

Генерация случайных чисел

Класс Random в C# представляет собой генератор псевдослучайных чисел — т.е. данный класс отвечает за выдачу последовательности чисел, отвечающую определенным статистическим критериям случайности.

Random rnd = new Random();

Здесь мы объявили экземпляр класса Random (rnd), с помощью которого мы будем генерировать случайные числа. В дальнейшем мы будем использовать код, вида rnd.Next (диапазон_генерации) или rnd.Next (от, до -1) для генерации случайного числа.

Также мы объявим еще несколько переменных, часть из которых сразу будет инициализирована.

tmp_location объявляется для того, чтобы в будущем временно хранить текущее положение окна.

Также нам следует подумать о том, что при случайном перемещении, наше окно может выйти далеко за пределы экрана.

Чтобы определить разрешение экрана в C# .NET, мы будем использовать:

_h и _w будут хранить в себе размеры экрана пользователя, которые определяются при их инициализации.

Теперь код этой функции будет выглядеть следующим образом:

Вот, собственно, и все. Откомпеллировав приложение, можете попробовать нажать на кнопку "Да, конечно". Это будет крайне трудно.