Есть функция
DWORD GetSysColor(
int nIndex // display element
);
где nIndex имеет следующие значения
COLOR_ACTIVEBORDER
COLOR_ACTIVECAPTION
и так далее
Я пишу
[DllImport("User32.dll")]
public static extern int GetSysColor(int nIndex);

Далее вызываю
int g=GetSysColor(????);
Что писать в качестве параметра если меня интересует COLOR_ACTIVEBORDER.

Добавление от 26-07-2001 12:08:

Поставлю вопрос по другому в какой структуре храниться информация о значениях
COLOR_ACTIVEBORDER
COLOR_ACTIVECAPTION

Ну и пиши COLOR_ACTIVEBORDER. Это же константа. Подставишь другую, получишь цвет другой части.
Правда я не пользовался этой функцией.
С уважением, Андрей.

Так мне нужно как-то узнать узнать какое число соотв константе, не методом тыка же перебирать

Это значение можешь найти в windows.h (по кр. мере оно там раньше было), только нафига изврат в виде дергания из .NET нативных вызовов Windows ???
Не проще ли использовать System.Drawing.SystemColors.ActiveBorder ?

А
int i = COLOR_ACTIVEBORDER;
- не проходит?
Или поиск на COLOR_ACTIVEBORDER

С уважением, Андрей.

cxjhb

ANDYRE
Спасибо, может ты порекомендуешь какие нибудь ресурсы по C# или литературу.

Самое лучшее - MSDN и примеры с beta2

http://www.csharpindex.com/

Visual Studio 2017, C#, в программе присутствует перечисление:
Оно громоздкое. Хочу его вынести в отдельный файл, не вынося из класса. Подскажите, пожалуйста, последовательность действий, как мне это реализовать?

Вопрос, скорее всего, общий по проектированию (на любом языке программирования).

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

Что же у меня в проекте должно еще присутствовать, чтобы на одной странице (файле) был только код из примера, и проект (в Visual Studio) собирался бы?

Геон
Студия же при создании проекта (консольное приложение, винформс) сама генерит шаблонное приложение. Там, в частности, есть файл Program.cs, который выглядит так:
метод Main - это application entry point, точка, откуда начинается исполнение кода. В него вы и можете вставлять вызов своих примеров.
Могут, конечно, быть нюансы (например, в WPF всего этого нет - там всё это делается в встраиваемых компилятором методах класса App) - но, думаю, тут не тот случай.

leonid555
Я пишу
[DllImport("User32.dll")]
public static extern int GetSysColor(int nIndex);

хороший сайт для референции: https://www.pinvoke.net
для Вашего случая:
https://www.pinvoke.net/default.aspx/user32.getsyscolor
http://www.pinvoke.net/default.aspx/Constants/COLOR_.html

Lucy
хороший сайт для референции: https://www.pinvoke.net
Есть еще вот такая штука: https://github.com/jaredpar/pinvoke
Помогает в тех случаях, когда чего-то нет на pinvoke.net (а там далеко не всё), плюс умеет переводить нативные сниппеты в managed-код (сама программа - реинкарнация P/Invoke Interop Assistant, обитавшего на почившем в бозе кодеплексе).

https://docs.microsoft.com/ru-ru/windows/uwp/devices…nsors/gatt-client
В параграфе "Отправка запросов для ближайших устройств", пример кода на C#.

В VS2017 создал заготовку проекта "Консольное приложение (.NET Framework)", вставил код, вот так:
Код не компилируется, выдает кучу ошибок. Возможно, какой-то библиотеки не хватает. Либо я не туда код вставил. Либо - не тот тип проекта.

Подскажите, пожалуйста, как приведенный по ссылке код грамотно вставить в проект C# так, чтобы он компилировался.

Геон
В VS2017 создал заготовку проекта "Консольное приложение (.NET Framework)"
Неправильно. Изложенное по ссылке - для UWP, соответственно, тип проекта должен быть Blank App (Universal Windows) или Console App (Universal Windows). Такие проекты можно создавать только в windows версии >=8.0 (и использоваться они могут тоже только с windows>=8.0). Как создать простейший хелловорлд изложено, например, здесь. Если нет шаблона для Console App (Universal Windows), то его нужно установить отдельно (см. здесь).

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

Подскажите, пожалуйста, такой момент:
Допустим, есть форма с кнопкой. Надо чтобы все события от кнопки обрабатывались в одном месте.
К примеру, в событиях кнопки на MouseDown и на MouseUp прописываю один и тот же обработчик Button_Action.
Получаю автоматически сгенерированный код:
Как теперь внутри написать что-то вроде:

rex2701
1. В winforms из MouseEventArgs нельзя получить сведения о том, нажата или отпущена кнопка мыши (в WPF можно, но я сильно подозреваю, что речь именно про winforms). Можно, конечно, залезть куда-нибудь вглубь системы, и получить такую информацию, но зачем нужен этот велосипед, если
2. Требование обработки в одном месте вовсе не означает, что этим местом обязательно должен быть метод хэндлера события. Вполне можно сделать вот так:

ash of mind
Да, речь про Windows Forms.
Мне не нужно получать состояние физических кнопок, это просто условный пример.
В общем задача выглядит так: если взять любой стандартный контрол и в его свойствах открыть события - практически все они должны быть заведены на один обработчик, потому что сначала должна быть выполнена куча общего кода, и только потом конкретная логика по каждому событию. Поэтому надо как-то определить имя события.
Так же есть задача, чтобы обработчик был один не только для всех событий, но и для разных контролов. С этим проблем нет, на sender всё нормально завязывается и обрабатывается.
Можно, конечно, не е....ть себе мозг и сгенерировать кучу отдельных обработчиков и в каждом из них сделать вызов некой CommonTask(), куда запихнуть всё общее. Но это приведёт к дикому распуханию исходного текста, что видится некрасивым.

У Form есть метод, который можно переопределить:

rex2701
Мне не нужно получать состояние физических кнопок, это просто условный пример.
Однако надо разделять события MouseDown и MouseUp. У хэндлеров этих событий одинаковая сигнатура, поэтому разделить их можно только по признаку, нажата клавиша мыши, или нет. Но с состоянием клавиши в винформс см. выше.

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

ErmIg
На первый взгляд - то, что нужно. Хоть и не полностью ".NET style".
Спасибо, покопаюсь в этом.

ash of mind
То есть опять, каждое событие расписывать отдельно? Те же яйки, только в профиль.
Ещё раз: открываем у контрола (любого, неважно) список всех его возможных событий. У каждого события есть имя. Это имя как-то можно получить? Если нет - то на этом вопрос будет закрыт.

rex2701
То есть опять, каждое событие расписывать отдельно?
А вы думаете, оно не расписывается отдельно, когда вы его навешиваете в дизайнере, даже если используется один хэндлер на всё? Все ваши события, навешанные через дизайнер, прописаны в классе формы в его partial-части. Вас смущает, что это будет в основной части? Это можно вынести в ещё одну partial-часть, или спрятать под регион.

Ещё раз: открываем у контрола (любого, неважно) список всех его возможных событий. У каждого события есть имя. Это имя как-то можно получить?
Да легко:
- 71 строка в консоли. Только как это поможет внутри обработчика события? Он в общем случае понятия не имеет, какое событие его вызвало.
Переопределение WndProc - это будет ещё больше работы с расписыванием каждого события, и приведёт к абсолютно ненужному распуханию кода, т.к. придётся расписывать вручную и раскладывать по обработчикам все возможные варианты Msg, в зависимости от него - lParam/wParam, аккуратно возвращать результат, итд. Всё это уже корректно реализовано в базовых классах, и заново всё это велосипедить - как минимум пустая трата времени.

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


не совсем то, что Вы хотите (одного обработчика не получите, будет 3-4), но позволяет обрабатывать события от элементов на уровне Form:
источник с примером: https://docs.microsoft.com/en-us/dotnet/api/system.w…s_Form_KeyPreview
переведено на русский: https://docs.microsoft.com/ru-ru/dotnet/api/system.w…s_Form_KeyPreview

Lucy
Да, это немного не то.

ash of mind
Только как это поможет внутри обработчика события? Он в общем случае понятия не имеет, какое событие его вызвало.

Вот! Что и требовалось узнать.
Теперь зайдём с другой стороны: "понятия не имеет в общем случае", а в частном? Как-то можно ему передать эту информацию? Есть вообще такой функционал в .NET?
Ещё я вижу, что автоматически сгенерированный код для формы и контролов с их событиями всегда выглядит примерно так:
Т.е. конструктор для EventArgs ничего не создаёт.

Можно ли это изменить, допустим, так:
Если, вдруг, EventArgs нельзя менять на другой тип, то как в него запихнуть имя события?