Тяжелый конечно вопрос, но таки об этом задумался.
Думаю о Windows Forms Application VB.NET и о С (#.NET ???)
Вкратце(если получится вкратце):

1) VB6 - для меня USER интерфейс.
Придерживаюсь строго стиля текущей WIN OS без самодеятельностей, как правило модифицирую имеющиеся контролы (реже создаю) через API - хитрости, манифесты - для стиля, 32-битные иконки через ResHacker, всякие там WinProc и т.п. Ну в целом все красоты решаются -большим объемом нестандартных работ.
2) Использую API для решения ряда других прикладных вопросов. В частности очень много GDI+/-
3) В основном приложение VB6 состоит из форм и кучи модулей, классы терпеть не могу (использую наверно 2-3шт CMultiFrameImage от Бенедикта, ClsText, Splitter) и плохо в них разбираюсь, хотя в том же сплиттере и CMultiFrameImage модифицировал немало. OCX-ов никогда не писал, чужими (включая от Microsoft ) стараюсь не пользоваться, ActiveX.EXE не понял и не хочу, люблю CreateObject и оч. не люблю раннее связывание.
4). Использую БД аля MS Access через MS ADO и не о каких SQL и прочем слышать не хочу, мне достаточно.
5). Оч. люблю использовать Shell(proga.exe) и ShellAndContinue(proga.exe) -модификация Shell с контролем ожидания завершения вызванного процесса - как с системными, так и с нек. другими утилитами.

Ну, топиков моих тут много даб все это проиллюстрировать.

Если я правильно понимаю, новые VB/C(#?).NET + Windows Forms Application сильно облегчат создание красоты в части п.1.
Но при этом совсем без API все же думаю не обойтись. Ну т.е. все API, приемы и т.п. что я использую в VB хотелось бы иметь возможность также красиво использовать при необх.
Потом новые всякие прибамбасы. Какие-нибудь Ribbons (родные, от Win7) на VB6 небось при всем желании не вставишь -просто пример привел.

В пользу VB.NET думаю то, что язык хоть и отличается, но примерно такой же, т.е. если тупо пытаться переписывать имеющиеся чисто-VB6 проекты на VB.NET, то это сильно проще чем на C++#.

Но есть ряд подводных камней. Я много работаю с телефонией и использую в частности OpalVoip , при этом уж не знаю хвастаться или стыдиться, даже перечислен в списке разработчиков и имею доступ к репозиторию(сам правда править коды на сайте через SVN так и не научился - мож оно и к лучшему, а то еще понапорчу).
Стыдиться, это потому что C++ практически не знаю. Хотя умею тестировать и модифицировать имеющийся код библиотеки или консольного приложения.
Но стоит вопрос как пририсовать "морду" к приложению.
Если что-то запускаю из под VB6, генерирую из под VB6 "командный" файл и в зацикленном C++ консольном приложении использую конструкции типа:



Ну, аналогично, если C++ генерирует событие, то пуляет файл в сторону VB6, а VB6 ждет файл по таймеру и отображает что-нибудь на форме:


Попытки установить прозрачное взаимодействие между VB6 и C++ давно закончились ничем, и до сих пор к этому не возвращался. Пока "пуляем файлы".
Жить конечно можно, живу, но все это сильно "тормозит развитие", и если нагрузка большая, то надежность приложения сильно снижается. Любой нормальный программист-профи обсмеет.
Если например, писать софтфон (идея как бы есть) с кучей кнопок и действий типа play/record/dial/hangup, то "форма-морда" и "интеллект-начинка" должны быть реализованы в рамках одного exe.
Т.е. по идее и в идеале хотелось бы (Я нарочно смешал C++ и VB6 код для иллюстрации желаемого решения типичной задачи):


Начинка на C, значит наверно нужен C(#).NET для формы. Это в пользу C.

Хотя Windows Forms Application в VC2005 EE на дурака даже в примитиве с одной кнопкой типа Dial пока прикрутить не удалось.
В примерах есть OpenPhone но он использует WxWigest -так понял "левая морда", слышал еще про MFC, но сдается что это не то и для виндов (чтоб просто и по стандарту) нужен WinForms.
===
Еще проблемы, которые периодически всплывают - уж не знаю насколько относится к вопросу - многопользовательская среда, запуск приложения под обычным юзером (я злоупотребляю админом), при этом настройки приложение хранит в CURRENT_USER и в HKEY_USERS\.DEFAULT\Software (для WIN Service кот. скажем прямо не совсем настоящий), данные прога хранит в /Program Files/Proga/etc. что подозреваю неправильно. Пользователей у кот. возникают иногда проблемы (в основном на серверах, куда лазют разные юзеры под своими терминалами), кормлю советами-затычками, что в прочем обычно помогает.
===

Таковы в общих чертах "проблемы мировой революции".
Ну т.е. в каком направлении мне посоветуете двигаться. C ? VB ? NET?
Для C стоит VC2005EE. Я так понимаю это называется C#. Не?

Если VB.NET, то чего ставить? Рабочая система - XP и думаю надолго, от вистов глаза рябит. Но проги должны работать (ну это рынок) соотв. up to WIN7 x64 и выше со всеми Themes (что впрочем худо-бедно и с VB6 правдами и неправдами достигнуто).
Крайняя попытка более менее серьезно ставить VB.NET была этак году в 2005, восторгов VB.NET не вызвала, правда стоит чего-то на нотебуке.

Чего не хочу, так это глубоко закопаться в что-то новое а потом понять что это не то что надо.

Ух0отсыпь мне немного курева своего)
Да, кури пожалуйста .
Только я вообще-то жду не ответов в духе "дискриминация VB6", а рекомендаций от людей хорошо знающих VB6, но при этом знакомых с разными системами програмирования.

Konst_Oneсложно что-то посоветовать. я так понимаю, что ты ищешь замену для своей конкретной программы....переделки твоего текущего решения ... VB.NET , как это не прискорбно, совсем не VB6 по простоте
Вот смотри. Что касается своих "чисто VB6 приложений", я как-то не сомневаюсь, что попотев и аккуратно переписав их заново, я смогу их переписать на VB.net (ну естественно наивно рассчитывать на "горе-мастеров"). Ну, допустим набью руку, научусь делать "красоту" меньшей ценой, заплатив б'ольшую цену за переделку/обучение но будет тоже самое. В принципе, мои VB6 проекты на достаточно хорошем уровне и можно пока об этом не думать.

Более интересна вторая часть, где я привожу пример как у меня "форма-морда" (на VB6) общается с "начинкой-консольным приложением C++" и чего бы мне хотелось.
Я хочу создать форму, нарисовать на ней кнопку и вызвать функцию из Opal.
На VB.NET я этого не сделаю. Так? API отдыхают - тупиковый вариант.

Konst_Oneработа с неуправляемым кодом в том же NET (а у тебя это C dll) достаточно запутана и C# совсем не C/C++.советую сразу переходить на C#.

Разжуй пожалуйста.
У меня есть ptlib.dll/opal.dll . Это C/C++. Так? Думаю ДА. Практически все имеющиеся примеры -консольные приложения.
Все это компилируется в Visual C++ 2005 Express Edition.
Там же можно создать
File -> Add new Project -> CLR -> Windows Form Application
Windows Form Application - это что C#.NET ???
Что мне надо сделать, чтоб начать чего-то понимать?
Я хочу создать форму, нарисовать на ней кнопку и вызвать функцию из Opal.
Это возможно?
И что это будет? Сборная солянка из C#.NET(для WinForm) и C/C++ для начинки? Или я чего-то не догоняю
в смысле
Konst_One C# совсем не C/C++.
Примеров с Windows Form Application в Opal нет, есть пример с mfc (на VC++ 2005 EE естественно не компилируется), причем структура файлов проекта очень похожа на структуру Windows Form.
М.б. попытаться по аналогии c mfc проектом пристыковать тестовый Windows Form к Opal?
Ну т.е. мне не от чего пока оттолкнуться.

Да еще.
У меня рабочий комп XP. VC++ 2005 EE Для моих тек. целей он работает "как надо".
Если я установлю VC++ 2010 EE параллельно (как выяснилось, для новых версий того же Opal 2005-й уже не поддерживается), то работа VC++ 2005 EE не нарушится? Типичные нарушения, это когда отлаженные проги при компиляции лезут не туда, а при переносе на другой комп почему-то перестают запускаться и т.п.

Konst_Oneв VB6 для использования API ф-й используется Declare , в C# для этого используется DllImport
Это я все понимаю.
Но к теме отношения не имеет, я не хочу использовать API, я считаю что в Opal нормальных нет. Попытки 2-х летней давности использовать эти API с VB6 закончились ни чем.

Если есть консольное приложение, компилируемое в VC++ 2005, то оно не использует API .
Оно использует
1) Tools -> Options -> Project and Solutions -> VC++ Directories -> ccылки на include и Library Files (ведут в директории Opal и PtLib)
2) всякие там
#include <ptlib.h>
#include <opal/console_mgr.h>
в файлах самого exe.

Я хочу сделать приложение, но не консольное, а Windows Forms Application(с мордой). В этом собственно и вопрос.

Konst_Oneв .NET можно в одном проекте делать винегрет из C++ и C#. надо пробовать.
Вот это я наверно и хотел услышать.


Вот это попробовать? Разумно?
Konst_OneЯ хочу создать форму, нарисовать на ней кнопку и вызвать функцию из Opal.
VC++ 2005 EE
Там же можно создать
File -> Add new Project -> CLR -> Windows Form Application
Windows Form Application - это что C#.NET ???
...
попытаться по аналогии c mfc проектом пристыковать тестовый Windows Form к Opal?
Потому как если это получится, то уже есть что-то под ногами.
И тогда можно потихоньку изучать WinForms + C#. Видимо методом перегонки наработок на VB6 в новую среду.

Konst_Oneлучше VS 2010 , т.к. 3.5 FW
3.5FW у меня и так стоит, хотя мало чего в этом понимаю.
Волнует вот это:
Дмитрий77Да еще.
У меня рабочий комп XP. VC++ 2005 EE Для моих тек. целей он работает "как надо".
Если я установлю VC++ 2010 EE параллельно (как выяснилось, для новых версий того же Opal 2005-й уже не поддерживается), то работа VC++ 2005 EE не нарушится? Типичные нарушения, это когда отлаженные проги при компиляции лезут не туда, а при переносе на другой комп почему-то перестают запускаться и т.п.
Думаю сначала надо смухлевать хоть что-то на рабочем VC++ 2005 EE, а потом уже думать об VC 2010

Ну, смухлевать чего-нибудь на VC++2005 "самому" не получилось:
Все попытки кончаются так:
1>c:\ptlib\include\ptlib\msos/ptlib/contain.h(289) : error C2373: 'WinMain' : redefinition; different type modifiers

AntonariyНо лучше начинать их устанавливать по старшинству.
В смысле? Сейчас стоит VC++ 2005 EE, хочу установить 2010

В OPAL сейчас узрел вот это:
Added .NET sample,
Так понимаю есть только проект для VS2010
Из описания следует:
TO USE OpalDotNET:

Simply reference the OpalDotNet.dll or the project inside your .NET project. You must compile the opal and ptlib
dlls yourself, and put them in the executing directory of your application using OpalDotNet.dll.

Also, it is not necessary to use the Opal_API structures directly. The OpalContext.cs file contains the wrappers and context for your to use.
These classes will handle marshaling the data back and forth between managed and unmanaged types.

Happy Coding!

М.б. то что нужно, надо пробовать.
Гм, м.б. даже для VB.NET прокатит?

OK, хочу установить 2010.
Konst_Oneв .NET можно в одном проекте делать винегрет из C++ и C#. надо пробовать.
Пошел типа посмотреть чего качать, и теперь вообще в ступоре.
http://www.microsoft.com/visualstudio/ru-ru/products/2010-editions/visual-cpp-express (вкладка "загрузка")

CLIPs для Visual Studio поддерживает следующие продукты:
...
•Visual Basic 2010 Express
•Visual C# 2010 Express
•Visual C++ 2010 Express...

Я вообще-то думал что есть "Visual C++" компилятор и в нем можно делать вышеобозначенный винигрет из C, C++ и C#.
Теперь вообще ничего не понимаю, чего устанавливать, куда иттить.
Так понимаю для компиляции Opal мне нужен C++.
При этом VC++ net. win формы тоже поддерживает.
А коим боком тогда VC#?

Antonariy,
>Express вряд ли позволит делать винигреды
А что тогда есть винигред?
М.б. их тогда сразу делать из "VB.NET & C++" а не "C# & C++"?

Я так теперь понял, C++.NET тоже есть и именно он используется в VC++ для WinForms...? так зачем мне тогда C#?

А вот кричат красивости-красивости в .NET

Нужен например UpDown + TextBox.
NumericUpdown -классно!
Опа - а высота не регулируется - НИКАК.
DateTimePicker - о, есть, супер.
- а высота не регулируется - НИКАК
TextBox -та же песня.

А 20px -это извините даже не стандарт, это очень низко и похабно (при стандартном шрифте имею ввиду).
И решение?
Сабклассить все это местными методами?
Или опять же рисовать через API?
Неудобства налицо...
А в чем тогда преимущество?

Не, пока никуда не перехожу. Так, к слову.

ОзверинИз того списка, который вы не хотите знать, .
Это что это за список такой, про который я во первых не знаю (о чем речь?), а во вторых не хочу знать (как вы утверждаете).
ОзверинПрограммирование. скорее всего, не ваше занятие.
Оч. даже мое. Мне 1) интересно 2) доход неплохой.
Ну, да, я не "профи" и умничать на вашем админско-програмерском жаргоне не умею.

Что дальше?
Вам просто что-то написать захотелось?

Озверин,

Если везде рисовать Custom Draw, то наверно, вы правы, надо заняться рисованием.

Но у меня здесь другая точка зрения. Есть операционная система со своими стандартными окнами, внешними видами и стилями, о внешнем виде которых можно судить, установив систему и посмотрев на стандартные программы и на поведение контролов в них.
И мое мнение, чтобы программа выглядела действительно прилично, ее интерфейс должен следовать стилю системы. Т.е. использовать "системный GUI". Потому как все нарисованное в фотошопе (кнопки и т.д.) выглядит в большинстве случаев самопально и похабно. Ну, в большей или меньшей степени в зависимости от таланта художника и криво/прямо рукости программиста.

Все это говоря грубо делается через API.
Что касается VB6, то это делается путем использования стандартных контролов + куча тонкостей типа:
-допиливание в VB6 созданных контролов через API
-создание каких-то контролов полностью через API
Плюс всякие манифесты, 32-битные иконки вставленные хакер-тулами и т.п.
Здесь у меня опыт достаточно большой, не спорьте.

И в общем-то получаются вполне-таки WIN-стандартизированные приложения неплохо смотрящиеся.

Если бы на VB6 не забили с созданием .NET, то думаю все бы было доведено и кучи хитростей делать было бы не надо.

Возникает ощущение, что .NET эти вопросы типа решает.
Т.е. правильная обертка над всем что только можно, все иконки-стили-манифесты автоматом и т.п.
Но вот смотришь на эти .NET контролы, и понимаешь, что до стандарта там очень далеко. Т.е. если не задумываться, то выглядеть будет далеко не по "стандарту". М.б. по ".NET-стандарту", но не по "WIN"-стандарту. Ибо для Textbox обычно используется высота 23px, а для DTPicker кажетя 24 или 25, и в VB6 с такой элементарщиной проблем нет, а в .NET как выясняется есть, и это несколько дико.

Или надо опять же сабклассить, или рисовать через API, но спрашивается что мне этот .NET тогда дает, кроме того что его надо таскать за приложением + изучать новый синтаксис и новые приемы неважно C# или VB.NET.

А вот логику приложения в отличии от GUI (что с чем складывать и что делать потом) можно писать любым "говнокодом"(как Antonary выразился) и на VB -главное чтоб не глючило и сам понимал (сейчас и потом) чего делаешь.

AntonariyВсе это не актуально....
wpf ...штатные возможности wpf-элементов
поставить 2012ю студию и посмотреть .
И...и...и
даже не знаю чего тебе ответить.
Пол-года назад советовали 2010-ю..WinForms
Полгода назад (в августе) начал писать свое новое приложение.
И посмотрев на эти студии начал писать его на VB6.
И пишу его до сих пор, все "сроки" прошли -это с учетом того что базовая функциональная начинка (С++) не моя и в VB6 большинство фишек я знаю.
Но по крайней мере уже виднеется финал первой версии.
И для меня актуально его дописать, и я на этот project делаю большие ставки (в том числе и денег заработать, что немаловажно, пока в эти .NET-ы врубишься глядишь и жизнь стороной пройдет).

А представляю, сколько сил и лет я бы угрохал, если б все таки позарился на .NET.

Потом этот WPF к примеру на XP небось и не работает.
А по опыту общения с буржуйскими клиентами, они там в основном на 2003-х серверах сидят, и редко когда на 2008-х.

Не, ну по идее тек. проект доделаю, надо будет попробовать перевести чего-нибудь существующее на .NET, хоть бы и на те же WinForms, с учетом соблюдения всех уже "осознанных" красивостей, а там уж смотреть как к этим WinForms всякие WPF прикручивать.
С другой стороны, насмотрелся я при тестах на этот Win8 и честно вообще даже в мозгах не представляю как интерфейс моего приложения можно воткнуть в метро-клетки - вот честно, даже образно.
Хотя смутно догадываюсь что WPF и метро это не одно и то же. WPF это я так понимаю все таки "окна", кот. может быть много на одном экране, а не по сути одно, как в "метро". Ибо как работать с одним окном в серьезном приложении? Это как во времена DOS -нортон коммандер для навигации и умные вычисления на черном экране. Ток. вместо них 2 больших картинки намалеванные в фотошопе на весь "современный супер-графический" экран?

Ну, если
WinForms -это не Common Controls
WPF -это не Common Controls

и при этом
большинство штатных программ образующих OS (включая Win 7 и Win 8 -отбросим квадратики в сторону)
и большинство приличных программ от сторонних разработчиков
используют все таки именно Common Controls (отбросим плакаты - все в .Net, за WPF будущее)
-а это видно невооруженным взглядом,
то

Какая современная система програмирования дает легкий способ работать именно с Common Controls?
Т.е. набросал кнопки, Listview и прочие штатные штуки с максимумом возможностей сделать это из конструктора
и потом читаешь MSDN и подправляешь чуть через хитрые API если нужно.

Ну т.е. то что в VB6 все-таки реализовано достаточно хорошо. Потому как даже если брать VC++ 6.0 того же года выпуска, то там черт ногу сломит.

Т.е какая современная система (не 98г. выпуска) позволит просто и ясно набросать
именно Win32 (а не .Net, не WPF, не MFC или чего там еще изобрели) приложение?

MSDN (который с припиской Windows а не с набором .матерных суффиксов) то извините обновляется, во всех ф-циях пояснения: вот это для Win8, это устарело, эта версия только начиная с висты. Это все для кого извините делается?
Для пользователей VB6 которые любят API? Сомневаюсь. Или для C++ программистов "высокого уровня", которые с нуля делают
CreateWindowEx для каждой кнопки.

P.S. Ногами не пинать. Я нормально вопрос поставил.

PPS. Я на .Net (не считая самих Visual Studio) видел очень мало прог.
Единственное чем пользуюсь - IcoFX 1.6 -выдает ее нестандартное (с точки зрения Win32) нет-овское меню (с голубой подсветкой).

Antonariy,

Я наверно неправильно сформулировал.
Я делаю в VB6 меню, да оно без картинок, но оно "Windows", а не .NET.
Я делаю в VB6 Toolbar, но он "Windows" а не "голубой Strip", кот. одинаково выглядит про любых OS и "темах".
В .Net я могу сделать "(Windows) - MSDN - Microsoft" а не "класс (System.Windows.bla-bla-bla) - MSDN - Microsoft"?

И ты утверждаешь что это не Common Controls. Хотя в .Net панели они вроде именно так называются.

Т.е. какая современная система позволяет делать в конструкторе именно "Windows 32" application?
Хотя бы также как в в VB6? (ну пусть с минимальными штатными возможностями).

AntonariyДа. Через CreateWindow и т.д.
...
Только у них нет Windows Common Controls.
Ну, тогда получается что удобнее VB6 ничего нет.
Если конечно хочется чтоб приложение имело стиль "Windows" а не вычурный стиль крашеных менюшек "Strip.Порно.Net".

Несмотря на то что многое приходится допиливать через Манифесты, API, сабклассинги и т.п,
штатный ввод (то что можно сделать в конструкторе VB6 + штатные обработчики) это очень и очень не мало.

Неудобство с API относительно C++ видимо в том, что постоянно гуглишь константы для VB, + всякие Union и прочие "непереводимые" типы, с кот. приходится извращаться.
Ну и конечно в C++ все подключается через заголовочные .h-файлы автоматом, а в VB6 все выписывается "ручками в модуль".
Но это с лихвой компенсируется штатными удобствами конструктора VB6.
Замечу кстати, что когда что-то (как пишут невозможное) в VB6 уже сделано "методом трактора", то тиражировать это потом уже относительно несложно.

Не спорю, Net-овские менюшки и Strip-ы смотрятся неплохо, но это "вещи в себе".

WPF я глянул в 10-й студии правда, ну идею понял, типа любые "размеры" и "цвета" через "web-разметку" . Но думаю пока рано.

AntonariyДмитрий77В .Net я могу сделать "(Windows) - MSDN - Microsoft" а не "класс (System.Windows.bla-bla-bla) - MSDN - Microsoft"?Да. Через CreateWindow и т.д.

Дмитрий77И ты утверждаешь что это не Common Controls. Хотя в .Net панели они вроде именно так называются.
Название библиотеки "Windows Common Controls" и название панели "Common controls" это похожие названия разных вещей.

Дмитрий77Т.е. какая современная система позволяет делать в конструкторе именно "Windows 32" application?

А кто мне помешает в .Net
сделать
Панель элементов -> Выбрать элементы

Послать местный Listview
и
добавить
->COM-компоненты -> Microsoft Listview Control, version 5.0 (SP2) COMCTL32.OCX
шаблон + API наверно применятся
и работать также как в VB?

Вместо MenuStrip (выигрыш в "красоте" только на классике) добавить MainMenu -оно хоть и .NET но стили поддерживает, API видимо то же. А картинки правильно я знаю как добавлять.

То же например с Toolbar (.NET) вместо ToolStrip.

Я смотрю они первые "нормальные" .NET контролы -которые базируются на настоящих, а не на стрип-муляжах, хорошо спрятали(Toolbar,MainMenu)

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

с COM+COMCTL32.OCX (чтоб не CreateWindow c нуля) + API для более сложных (где стрипы меня не устраивают).

Т.е. по сути я могу тупо использовать весь полезный ф-ционал VB6 из .NET

Я прав? Тогда почему мне никто про это не сказал?
Или это очень дурной тон? Пристыковка VB6 привычных контролов к WinForm приложению?

Кстати WPF по ходу тоже можно мешать с WinForms.

Antonariy,

Против этого аргумента возражу.

А чем указанная ситуация отличается в худшую сторону (сложнее и т.д.) от ситуации когда

все контролы - контролы (.Net или ActiveX в VB6), а часть API+CreateWindow?

AntonariyПопробуй для начала сделать свой софтофон в казённом дизайне, чтобы хоть работал. Для ускорения процесса можно 2008й студией конвертировать проект и копипастить из него куски, не связанные с графикой. :)
Чувствую там такой бардак после конвертации будет, даже без учета графики.
Счас ничего пробовать не буду. Просто help писать скушно и долго, вот я для разгрузки и залез в .Net.
AntonariyКстати, а его скриншот увидеть можно?Ну, как нибудь не сейчас.

Короче, засел пока как школьник за штудирование примеров из книги
Зибиров В.В Visual Basic 2010 на примерах (с воспроизведением оных с нуля в VB2010 EE)
Пока дошел до 20-го примера.
Насколько меня хватит и насколько правильный путь пока не знаю.
Но вроде осваиваюсь потихоньку.

Потом попробую что-нибудь свое переписать.

P.S. VS2012 -глюкота какая-то. На Win7 на ноут установил - вообще работать отказывается. В баню.

Ну, TextBox и Combobox по крайне мере там настоящие, это радует.
Так решил, потому что этот код применился почти в лоб:


Просто не мог спокойно читать бред на 3-х страницах, где автор с пеной у рта расписывал муть, что закомментирована.

1. Кстати, в чем разница между A и W(Юникод) на конце API-шек?
В .net лучше везде писать W? (коль он такой об-юникодиный).

2. Еще вопрос. API также декларируются? Разница с VB6 только в замене Long на IntPtr/Int32. Там вроде какие-то слова еще должны быть. Но у меня вроде по старинке все прокатило.

Порадовал также TabControl -нормально там все с XP/Vista стилем (цвет вкладок правильный).

Progressbar в Net настоящий судя по работоспособности кода:




Делаю такие проверки чтоб понять что контрол НАСТОЯЩИЙ.
Хотя в данном примере все это можно сделать без API (включая PBM_SETBARCOLOR).