1. Серія контенту:
2. Цей контент є частиною серії: Працюємо з Mono
3. Введення в WinForms
4. Реалізація WinForms в Mono
5. Використання інструменту MoMA для перенесення додатків
6. Проблеми, що виникають при перенесенні додатків на Mono
7. Лістинг 1. Використання макросу для умовної компіляції
8. Лістинг 2. Перевірка типу платформи під час роботи програми
9. Малюнок 1. Короткі результати аналізу збірки за допомогою MoMA
10. Малюнок 2. Докладні результати аналізу збірки за допомогою MoMA
11. Лістинг 3. Конфігураційний файл для заміни бібліотек
12. Обмеження інструменту MoMA
13. Візуальне редагування форм
14. Малюнок 3. Головне вікно MWF-Designer c новим проектом
15. Малюнок 4. Форма з елементами управління
16. Ресурси для скачування

Працюємо з Mono

Серія контенту:

Цей контент є частиною # з серії # статей: Працюємо з Mono

https://www.ibm.com/developerworks/ru/library/?series_title_by=**auto**

Слідкуйте за виходом нових статей цієї серії.

Цей контент є частиною серії: Працюємо з Mono

Слідкуйте за виходом нових статей цієї серії.

Введення в WinForms

MonoDevelop IDE - вільна мультиплатформенна середовище розробки, призначена для створення додатків на мовах C #, C, C ++, Java, Visual Basic.NET, CIL, Nemerle, Boo. На даний момент середовище є частиною проекту Mono і є однією з найкращих IDE для розробки проектів на базі Mono.

Бібліотека Windows Forms - це один з компонентів Microsoft .NET Framework, що відповідає за реалізацію графічного інтерфейсу користувача на платформі .NET. Хоча зараз вже представлена ​​бібліотека Windows Presentation Foundation, яка повинна її замінити, Windows Forms все ще широко використовується при розробці додатків для Microsoft Windows. Windows Forms є керованою надбудовою над стандартним графічним інтерфейсом Windows GDI і реалізує всі його можливості.

Форма - це одне з ключових понять в Windows Forms. Під формою мається на увазі простір, яке використовується для взаємодії з користувачем (висновок інформації та / або збір даних). Для створення програми на основі Windows Forms потрібно:

• створити форму;
• додати в форму елементи управління;
• реалізувати обробку дій користувача.

Елемент управління (control) - це GUI-компонент, який використовується для відображення інформації або введення даних користувачем. До складу бібліотеки Windows Forms входить безліч різних елементів управління. До них відносяться:

• області для введення тексту (TextBox);
• кнопки (Button);
• випадають списки (ComboBox);
• перемикачі (CheckBox, RadioButton);
• клас UserControl для створення власних елементів.

Також існують елементи-контейнери, що дозволяють управляти розміщенням GUI-компонентів у формі.

Коли користувач виконує будь-яку дію з формою або елементом управління, то створюється відповідна подія (event). Додаток може «підписатися» на доставку повідомлень про певні події, і при виникненні події буде викликатися код для його обробки.

Реалізація WinForms в Mono

В останніх версіях Mono підтримується практично повний набір класів простору імен System.Windows.Forms і System.Drawing. При цьому дана реалізація не спирається на інші бібліотеки типу Gtk #. Це пов'язано з тим, що у кожної GUI-платформи (GNome, KDE, Windows) є відмінності в реалізації елементів управління, їх відображенні і функціональності. Наприклад, перемикач (CheckBox) в Gtk # відрізняється від перемикача в Win32 GDI. Бібліотека Windows Forms в Mono розроблялася з таким розрахунком, щоб максимально уніфікувати поведінку додатків при запуску під Linux, Windows або Mac OS X.

Використання інструменту MoMA для перенесення додатків

В першій статті цієї серії розглядався інструмент Mono Migration Analyzer (MoMA), який дозволяє проаналізувати бінарну збірку на сумісність з різними версіями Mono. Так як в жовтні 2010 року вийшла нова версія Mono 2.8, оновлена ​​версія MoMA доступна по цією адресою . Ця версія виконує аналіз збірки на сумісність з Mono 2.8. Для перевірки сумісності з попередніми версіями на сторінці архіву MoMA можна завантажити файли визначень для попередніх версій і скопіювати їх в каталог defs встановленої версії MoMA.

Проблеми, що виникають при перенесенні додатків на Mono

Бібліотека Windows Forms - не найвдаліший вибір для розробки додатків, які повинні запускатися на різних ОС. Навіть при розробці Mono-додатки в ОС Windows, щоб забезпечити запуск програми в Linux або Mac OS X, краще скористатися Gtk #. Однак, якщо потрібно перенести вже готову програму, то переписувати її з нуля буде не самим правильним рішенням. В такому випадку краще внести в програму деякі зміни, щоб забезпечити можливість запуску під Mono.

Поточні версії Mono (на даний момент актуальними вважаються версії 2.6 і 2.8) пропонують практично повну підтримку Windows Forms, але при перенесенні програми на більш старі версії Mono можуть виникнути проблеми. Щоб забезпечити додатком на Windows Forms можливість запуску під управлінням Mono, вже при його розробці потрібно врахувати кілька факторів.

Іноді виникає проблема, пов'язана з відсутністю реалізації того чи іншого методу. У разі якщо не реалізований обов'язковий метод, потрібно змінити код і видалити всі звернення до цього методу. Але найчастіше нереалізованими виявляються необов'язкові методи. Наприклад, в Windows Forms існує стандартне діалогове вікно налаштувань друку PrintDialog, у якого є властивість UseExDialog. Це властивість визначає, чи має діалогове вікно відображатися в стилі Windows XP, і з точки зору функціональності не несе ніякого навантаження, тому в поточній версії Mono його зміна ні на що не впливає. У попередніх версіях Mono реалізація для цього властивості була відсутня, що могло призвести до помилки і закриття програми. Обійти це можна трьома шляхами:

1. закомментировать виклик нереалізованого методу;
2. умовної компіляцією в залежності від системи;
3. перевіркою в процесі виконання програми.

У першого способу є один недолік. Буває, що метод або властивість не несуть функціонального навантаження, але в Windows вони можуть вплинути на зовнішній вигляд призначеного для користувача інтерфейсу. Тому можна розглянути другий спосіб, коли вибір використовуваної функціональності залежить від цільової платформи. Для цього досить визначити будь-якої макрос (наприклад, USE_MONO, як показано в лістингу 1), і в залежності від його значення збирати різні версії додатка.

Лістинг 1. Використання макросу для умовної компіляції

#if! USE_MONO // викликаємо підтримуваний в Mono метод #endif

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

Найкращим є третій спосіб, при якому є одна збірка для різних платформ, але в процесі виконання виконується перевірка, на якій платформі був проведений запуск, як показано в лістингу 2:

Лістинг 2. Перевірка типу платформи під час роботи програми

// метод, який перевіряє, що додаток запущено на платформі Mono public static bool IsOnMono () {return Type.GetType ( "Mono.Runtime")! = Null; } // в іншому місці коду if (! IsOnMono ()) {// виклик методу, непідтримуваного в Mono}

Більш серйозною проблемою при перенесенні додатків в Mono може стати використання в додатку викликів функцій з некерованого коду (так звані P / Invokes). Справа в тому, що в бібліотеці Windows Forms (входить до складу .NET Framework) закладена тільки базова функціональність і деяких функцій для роботи з призначеним для користувача інтерфейсом, що існують в Win32 GDI, в керованому коді немає. Для цього розробники використовують механізм виконання функцій з некерованого коду, імпортувавши їх безпосередньо з динамічної бібліотеки (DLL), де вони реалізовані.

Як приклад можна розглянути open-source елемент управління Ribbon , Який реалізує функціональність стрічки і вперше з'явився в Microsoft Office 2007. Аналіз збірки в MoMA показує, що в коді елемента управління проводиться 37 викликів з некерованого коду, як показано на малюнку 1.

Малюнок 1. Короткі результати аналізу збірки за допомогою MoMA

На малюнку 2 в докладних результатах аналізу вказується, з яких методів виробляються виклики, а також які функції викликаються і з яких бібліотек.

Малюнок 2. Докладні результати аналізу збірки за допомогою MoMA

Обійти цю проблему можна декількома способами.

По-перше, якщо виклик не є критично необхідним, з ним можна поступити, як було описано вище: закомментировать або викликати тільки за умови, що програма запущена в середовищі, де не існує некерованою бібліотеки, звідки здійснюється виклик. При цьому не можна виконати тільки перевірку на наявність Mono, так як в середовищі Microsoft Windows можуть співіснувати Mono і необхідні бібліотеки.

По-друге, якщо виклик необхідний, можна розглянути можливість його заміни на функціональність, доступну з керованого коду. У цьому допоможе як знання класів .NET Framework, так і досвід, вже накопичений в Mono-співтоваристві. На сайті PINVOKE.NET зібрана добірка функцій, які не мають прямої реалізації в .NET Framework, розбитих по бібліотеках. Знайшовши потрібну функцію можна подивитися її опис, приклад виклику з керованого коду, а в деяких випадках і варіант заміни на реалізацію на основі керованого коду.

Ще існує можливість підібрати необхідну функціональність серед бібліотек, доступних в середовищі, відмінному від Windows, завдяки тому, що Mono, як і .NET Framework, допускає виклики з некерованого коду. Для пошуку функцій в різних бібліотеках використовується спеціальний конфігураційний файл, який повинен мати ім'я як у виконуваного файлу (повністю) і додаткове розширення .config. Наприклад, якщо файл програми називається app.exe, то його конфігураційний файл повинен називатися app.exe.config. Для підміни бібліотеки з потрібною функцією в конфігураційному файлі прописується замінна бібліотека (атрибут dll) і замінює (атрибут target), як показано в лістингу 3.

Лістинг 3. Конфігураційний файл для заміни бібліотек

<Configuration> <dllmap dll = "gdi32.dll" target = "libgdi32.so" /> </ configuration>

При цьому пошук некерованих методів, що імпортуються з бібліотеки gdi32.dll, буде проводитися в бібліотеці libgdi32.so. Більш детально цей прийом буде розглядатися в одній з наступних статей циклу.

Якщо функція не має аналогів в системі, де запускається додаток, то існує ще одна можливість не реалізовувати її з нуля. Для цього використовується набір бібліотек WINE , Призначений для запуску Windows-додатків в середовищі Linux та інших вільних операційних систем. Якщо потрібно функція з набору стандартних бібліотек Windows, то її вихідний код можна знайти в WINE і скопіювати в окрему бібліотеку, яка буде підключатися через конфігураційний файл.

Обмеження інструменту MoMA

Інструмент MoMA не зможе виявити всі проблеми, що виникають при перенесенні додатки на іншу платформу, наприклад, проблеми, пов'язані з написанням імен файлів і шляхів до них.

Для нормальної роботи програми на різних ОС необхідно враховувати регістр при найменуванні файлів, так як в Windows регістр не має значення при написанні імен файлів, на відміну від Linux-систем. Також є і відмінності в символі, що розділяє каталоги в шляху до файлу. У Windows роздільником є ​​зворотна коса риска (\), а в Linux - пряма (/). Щоб уникнути створення різних збірок для різних систем необхідно використовувати метод Path.DirectorySeparatorChar.

Є шлях до файлу - ./Res/Img/Img.jpg, в вихідному коді його можна представити наступним рядком:

string strFilePath = Application.ExecutablePath + string.Format ( "{0} Res {0} Img {0} Img.jpg", Path.DirectorySeparatorChar);

Візуальне редагування форм

Хоча використання Windows Forms для мультиплатформових додатків - це не найкраща ідея, але при необхідності можна створювати і редагувати форми в візуальному редакторі навіть в середовищі Linux.

У Windows при розробці для платформи Mono можна використовувати open-source інтегроване середовище розробки (IDE) Sharp Develop з вбудованим інструментарієм для візуального побудови інтерфейсу Windows Forms. В MonoDevelop IDE подібний інструмент відсутній, але можна використовувати MWF-Designer . Хоча цей проект розвивається не дуже активно і має деякі недоліки, його можна використовувати для проектування форм. Для запуску MWF-Designer необхідно завантажити свіжу версію з сайту і розпакувати її в окремий каталог.

Для складання MWF-Designer використовується команда make, а вийшов виконуваний файл буде поміщений в каталог build. Звідти його можна буде запустити командою: mono mwf-designer.exe.

На малюнку 3 показано вікно MWF-Designer після створення нового проекту. З лівого боку - палітра стандартних елементів управління, в центрі - шаблон форми, праворуч - набір властивостей і подій для елемента форми або самої форми.

Малюнок 3. Головне вікно MWF-Designer c новим проектом

На малюнку 4 показана форма, в яку вже додано кілька елементів управління. Після настройки їх властивостей і збереження MWF-Designer згенерує файли з вихідним кодом, який можна буде додати в проект.

Малюнок 4. Форма з елементами управління

висновок

Як показує практика, поточна версія Mono забезпечує підтримку Windows Forms на рівні, достатньому для запуску більшості додатків. При перенесенні додатків, написаних з використанням .NET Framework, на Mono необхідно врахувати кілька моментів, які можуть привести до проблем. Однак, як розповідається в цій статті, цих проблем можна легко уникнути, якщо приділити їм додаткову увагу при розробці програми та використовувати спеціальні інструменти, такі як MoMA.

Ресурси для скачування

Схожі теми

Підпишіть мене на повідомлення до коментарів