Задали вопрос, а можно ли в C# программными средствами наложить 2 изображения друг на друга. И даже сами потом предложили какое-то жуткое решение с привлечением WinAPI, и чуть ли не ассемблера со злыми духами.

На самом деле, задача вполне себе решается стандартными средствами.

Итак, предположим, что у нас есть 2 изображения, оба они PNG с прозрачностью, и лежат в ресурсах нашего приложения. Например, флаг:

и герб:

под именами, соответственно Properties.Resources.flag и Properties.Resources.trizub_small

Сначала сделаем из изображений два объекта Bitmap:

//Берем целевое изображение
Bitmap TargetBitmap = Properties.Resources.flag;

//Берем накладываемое изображение
Bitmap OverlayBitmap = Properties.Resources.trizub_small;

Теперь надо создать результирующее изображение (оно будет пока пустым) нужного размера:

//Создаем результирующее изображение (пока пустое)
Bitmap ResultBitmap = new Bitmap(TargetBitmap.Width, TargetBitmap.Height,
            PixelFormat.Format32bppArgb);

Откуда взяли высоту и ширину — понятно, третий параметр PixelFormat берется в зависимости от исходных изображений. Желательно, чтоб они совпадали по глубине цвета, иначе получится некрасиво, может потеряться прозрачность или произойти еще какая-нибудь бяка. Я сделал 2 изображения с прозрачностью (ARGB) и глубиной цвета 32 бита.

Теперь нужно создать объект Graphics, который и будет заниматься совмещением изображений. Раз мы будем рисовать в пустом Bitmap ResultBitmap, то и объект Graphics создаем из него, воспользовавшись методом Graphics.FromImage():

//Создаем объект Graphics из результирующего изображения
Graphics graph = Graphics.FromImage(ResultBitmap);

Далее объект graph надо настроить:

//настраиваем метод совмещения изображений
graph.CompositingMode = System.Drawing.Drawing2D.CompositingMode.SourceOver;

Если вместо SourceOver установить SourceCopy, то потеряется вся прозрачность у накладываемого изображения, и будет некрасиво:

Далее, производим отрисовку:

//рисуем основное изображение
graph.DrawImage(TargetBitmap, 0, 0);

//рисуем накладываемое изображение
graph.DrawImage(OverlayBitmap, (TargetBitmap.Width-OverlayBitmap.Width)/2,
(TargetBitmap.Height-OverlayBitmap.Height)/2,
OverlayBitmap.Width,OverlayBitmap.Height);

Думаю, откуда взяты все координаты и размеры, понятно.

Осталось только присвоить Bitmap'ы PictureBox'ам

Тут тоже ничего сложного и сверхъестественного нет.

Чтоб два раза не вставать, возьмем полученное выше изображение и уменьшим его:

//задаем новые размеры
int NewWidth = ResultBitmap.Width / 2;
int NewHeight = ResultBitmap.Height / 2;
//Настраиваем PictureBox для вывода уменьшенного изображения
pbResize.Size = new Size(NewWidth, NewHeight);

Создадим новый Bitmap для будущего уменьшенного изображения:

//создаем новый Bitmap для измененного изображения
Bitmap ResizeBitmap = new Bitmap(NewWidth,
NewHeight);

Опять создадим объект Graphics, который будет заниматься отрисовкой:

//создаем объект Graphics, который будет изменять размер
Graphics ResizeGraph = Graphics.FromImage(ResizeBitmap);

Поставим повыше качество изображения:

//ставим высокое качество
ResizeGraph.InterpolationMode =
System.Drawing.Drawing2D.InterpolationMode.High;

И делаем отрисовку:

//рисуем изображение с измененным размером
ResizeGraph.DrawImage(ResultBitmap, 0, 0, NewWidth, NewHeight);

В заметке я пропустил вывод изображений в PictureBox'ы, но он и так очевиден (в исходнике есть).

Вот, что получилось:

Исходник примера на GitHub

Решил побороть еще одно узкое место в коде, которое приводит к невероятному количеству ручного кодинга, а именно — загрузка данных из записи DataSet или произвольного объекта в форму, для изменения/ввода данных пользователем, а потом обратная выгрузка.

Вообще, долго думал и гуглил, как сей неприятный процесс автоматизировать, но почему-то везде предлагали либо встроенные, либо сторонние генераторы кода, т.е. ответ был «генерируй!». Но меня такой ответ не устроил, неужто, никак нельзя все это более-менее автоматизировать, не прибегая к внешним инструментам.

Оказывается, можно. Все инструменты для этого есть — есть System.Reflection, через инструменты данного пространства имен можно получать имена свойств или полей нужного класса, а также тип данных, и есть методы для поиска нужных контролов на форме, чтобы загрузить или сохранить данные в/из объекта.

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

Опять же, тут будет краткое рассуждение, а пример кода в конце.

Основные компоненты это:
— текстовые поля, куда можно ввести либо строку, либо число (фильтрацию ввода оставим форме)
— checkbox’ы, хранящие булево значение
— radiobutton’ы/переключатели — ограниченный выбор из определенного набора вариантов.

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

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

public enum NetConnectionType
{
    NoProxy = 0,
    SystemProxy = 1,
    ManualProxy = 2
}

Для радиокнопок (переключателей) имя формируется по следующему принципу: префикс rb+НазваниеСвойства+ЗначениеВEnum, т.е., например, радиокнопка, указывающая на прямое соединение, будет называться rbConnectionNoProxy

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

Получение списка радиокнопок и поиск контрола на форме Копия

Получение значения Enum из состояния RadioButton:

private string GetEnumValFromRb(string PropName)
{
    string EnumVal = string.Empty;
    string rbName = "rb"+PropName;            
    
    foreach (RadioButton rb in RadioButtons)
    {                
        if (rb.Checked)
        {
            if (rb.Name.StartsWith(rbName))
            {
                EnumVal = rb.Name.Substring(rbName.Length);
            }
        }
    }

    return EnumVal;
}

На GitHub

Если нам нужно найти контрол на форме, зная его имя, то все решается довольно просто — у массива контролов Controls есть метод Find, который найдет нам что нужно, если указать правильное имя контрола:

private Control FindControl(string ControlName, Form form)
{
    Control ctrl = null;

    Control[] buf = form.Controls.Find(ControlName, true);
    if (buf.Length == 0) return null;
    if (buf.Length > 1) return null;

    ctrl = buf[0];

    return ctrl;
}

Вот тут уже сложнее, особенно с переключателями. Они обычно сидят на форме в контейнерах, например в GroupBox'ах, и функция Find тут не поможет. Необходим другой подход, если мы хотим получить список контролов определенного типа. А именно — надо сделать рекурсивную функцию поиска. Кто боится рекурсии и связанных с ней переполнений, скажу, что ничего страшного нет.
Мне удалось уронить студию на 5 000 однотипных компонентов, а подобное число компонентов вряд ли может быть в реальности, только если вы не радиокнопочный маньяк 🙂

Функция такая вот:

private List FindAllRadiobuttons(Control.ControlCollection collection)
{
    List  result = new List();
    foreach (Control ctrl in collection)
    {
        if (ctrl.HasChildren)
        {
            result.AddRange(this.FindAllRadiobuttons(ctrl.Controls));
        }
        if (ctrl is RadioButton)
        {
            result.Add((RadioButton)ctrl);
        }
    }

    return result;
}

Т.е. если мы просто наткнулись на переключатель, при переборе контролов из массива Controls, то добавляем переключатель в массив, если же, мы наткнулись на контрол-контейнер (ctrl.HasChildren == true), то вызываем функцию перебора массива уже для массива Controls контейнера.

В прошлой части Копия я рассказывал, как с помощью инструментов из пространства имен System.Reflection, можно сохранить свойства объекта, например, в таблицу DataSet, или наоборот, загрузить из DataSet данные в свойства соответствующего объекта. Таким образом, решалась проблема автоматизации работы с конфигурационными файлами.

Есть способ еще более уменьшить количество кода, воспользовавшись стандартным механизмом .NET Framework — сериализацией. Сериализация, это, по рабоче-крестьянски говоря, именно что сохранение состояния объекта (он же пафосно называется «экземпляром класса») в некий передаваемый формат. Доскональное объяснение, что это такое, в статью не влезет, потому оставим.

Итак, переходим к сериализации.

В .NET Framework сам себя класс сериализовать не может, точнее, сериализовать-то может, а вот десериализовать — нифига. Класс и его экземпляр, получается, как Штирлиц с раненой радисткой Кэт, передать могут, а обратно нет, без дружественной помощи.

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

Итак, создадим класс-хранилище, вот такой вот, например:

[Serializable]
public class AppSettings
{
    public string DataUrl { get; set; }
    public FormatType DataFormat { get; set; }
    public string IPColumn { get; set; }
    public string FieldSeparator { get; set; }
    public string FlagColumn { get; set; }
    public string TrueValue { get; set; }
    public string FalseValue { get; set; }
    public bool LoadUpdate { get; set; }

    public AppSettings()
    {
    }
}

Если нужно, чтобы класс сериализовался, то перед описанием класса нужно обязательно установить атрибут «сериализуемый»:

[Serializable]

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

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

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

Если какое-то публичное свойство не надо сериализировать, т.е. в нашем случае, сохранять в конфиг, то такому свойству надо установить атрибут [XmlIgnore], для публичных полей устанавливается атрибут [NonSerialized].

Например:

[XmlIgnore]
public string DataUrl { get; set; }

Последняя особенность сериализации в XML — сериализируемому классу необходим конструктор без параметров, причем, практически выявлено, в этом конструкторе лучше вообще ничего не делать, особенно того, что может привести к ошибкам времени выполнения. Иначе получите гадскую невыявляемую ошибку, поскольку в отладке у вас будет всякая фигня, кроме того, чего нужно.
Я так понимаю, конструктор без параметров вызывается во время XML-сериализации, и наверняка, в нем что-то можно и нужно делать, но пока я не нашел, как и где это подробно расписать.

Само дерево жужжать не может
Значит, кто-то тут жужжит
(Вини-Пух)

Это самая гадская особенность сериализации в .NET, а именно, если в прошлом случае могли параметры конфига, и функции для их сохранения-загрузки объединить в один класс, то в подходе с использованием сериализации не можем:

this = (Data)readerRr.Deserialize(fileRr);
this - переменная только для чтения, по крайней мере до .NET 4.0 включительно.

И такой подход считается «плохим дизайном», хотя на мой нескромный взгляд, плохой дизайн — это разносить части одного и того же по разным классам.

Но раз уж надо, значит надо. Делаем класс-менеджер:

Далее такой условный класс-менеджер с возможностью сохранения и загрузки:
Читать далее

AppSettings.cs

Киберфорум
Сериализация в XML. XmlSerializer

Навел на мысль steinkrauz@ljr

Можно сказать, по многочисленным просьбам зрителей. Итак, спрашивали, как устроено в наших программах окошко «О программе» с «эффектом титров». Т.е. список разработчиков и прочее медленно выплывает снизу, проползает по форме и исчезает наверху, часть всплывающих строк останавливается в центре формы, в конце выплывает слоган, так же останавливающийся на некоторое время в центре.

На самом деле, форма была устроена ужасно, написана совсем другими людьми для другого проекта, а у нас кочевала из программы в программу без особых изменений, строки добавлялись в 3 ArrayList в коде формы, в функции рисования были какие-то непонятные жестко заданные поправочные коэффициенты, подобранные на глаз, и т.д.
Решили немного поправить и все переделать. Не знаю, насколько получилось лучше, но понятнее и универсальней точно. Далее будет не столько код с пояснениями, сколько попытка показать, как мы рассуждали, переделывая форму.

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

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

Параметры шрифта это FontFamily (Arial, Times New Roman и т.д.), размер и начертание или стиль (жирный, курсив, подчеркнутый, зачеркнутый, или все вместе). Для того, чтобы связать шрифт со строкой, пришлось добавить еще один параметр внутреннее имя, по которому программа будет узнавать, какой шрифт к какой строке применить.

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

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

...
команда;параметр1;параметр2;параметр3 [...]
команда;параметр1;параметр2;параметр3 [...]
команда;параметр1;параметр2;параметр3 [...]
...

Формат команд следующий (в квадратных скобках необязательные параметры):

Шрифт:
addfont; FontFamily; Размер (pt, float); [Стиль]; Внутреннее_имя
Например:
addfont; Arial;9;Bold;Group;
addfont; Microsoft Sans Serif;8;;Names;
addfont; Arial;14;Bold italic;Slogan;

Строка:
addstring; Строка; [Имя_шрифта]; [цвет_текста];
Например:
addstring;Make code, not war! C# like you.;Slogan;FF FF 00;

Сцена:
scene; [цвет_фона];[скорость_таймера_прорисовки ms];[пауза ms]
Например:
scene;20;3000;

Цвет текста задается в шестнадцатеричном формате через пробел(ы): R G B [Alpha]
Например:
FF FF 00 — желтый
FF 00 00 80 — красный с прозрачностью

Начертания (стили) шрифта перечисляются через пробел(ы), от регистра не зависят.

Шрифты:
Генерируются при анализе «скрипта», и помещаются в приватный Dictionary, где строковый ключ — заданное «внутреннее имя» шрифта.

Строка:
Текст и параметры хранятся в специальной структуре:

private struct AboutString
{
    public string Text;
    public string FontName;
    public Color TextColor;
    public int SceneNumber;
}

А все строки в private List Strings

Сцена:
Для описания сцены так же создана структура:

private struct AboutScene
{
    public int PauseTimeout;
    public int StringsHeight;
    public int StringsCount;
    public Color BackColor;
    public int DrawTimeout;
}

И описания сцен так же хранятся в private List Scenes

— последняя точка с запятой является необязательной
— пустые строки, или строки, содержащие только пробельные символы, пропускаются
— команды приводятся к нижнему регистру (т.е. они регистронезависимы)
— есть возможность оставить однострочный комментарий, начинающейся с ~ (тильды). Все, что после знака ~ считается комментарием и пропускается при анализе «скрипта».
— если первая (нулевая) сцена явно не определена, то создается сцена с параметрами по умолчанию

Команды, благо их немного, последовательно анализируются с помощью конструкции switch/case и передаются в функции добавления шрифта, строк, или сцены, где анализируются далее.
Параметры и команда разбираются с помощью string.split(';');

Размер шрифта должен быть float, поэтому надо сделать функцию-обертку над Convert, так, как я писал об этом ранее:

private float ConvertToFloat(string Number)
{
    NumberFormatInfo format = new NumberFormatInfo();
    format.NumberDecimalSeparator = ".";
    return (float)Convert.ToDouble(Number, format);
}

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

private string RemoveDupSpaces(string s)
{
    while (s.Contains("  "))
    {
        s = s.Replace("  ", "");
    }

    return s;
}

Естественно, весь функционал не стоит реализовывать прямо на форме, потому вся работа вынесена в отдельный класс AboutDrawer, который парсит переданный скрипт и занимается отрисовкой строк на форме.
На форме строки отображаются в компоненте PictureBox, который передается в конструктор класса. Конструктор также устанавливает некоторые параметры по умолчанию.
Поскольку, класс все равно работает с компонентами формы, то спокойно подключаем пространство имен System.Windows.Forms, и пользуемся всеми его возможностями. Например, в классе создаются два таймера (Timer). Внутри обработчика события Tick одного из них, происходит отрисовка, а другой используется для эффекта паузы.
В классе созданы открытые свойства для установки цвета фона, цвета текста по умолчанию, и размера расстояния между строк.

Подробнее ознакомиться с кодом примера можно на Github:

Код на GitHub