Станислав Макаров

разработка остановилась 5 лет назад и тому подобное

Да, есть некоторый застой, основные силы переброшены на .net core и asp.net

Правда ли, что WPF ждет судьба WinForms?

Что конкретно вы имеете в виду под "судьбой WinForms"?

Есть ли альтернатива WPF?

Под .Net нету, под WinRT есть аналогичная подсистема, во многом скопированная с WPF, вообще под десктоп есть еще Qt, но это C++ (если не считать биндингов на другие языки)

Что сейчас Microsoft предлагает для разработки GUI?

Universal Windows Platform для Windows 10 - их основное направление, для классического десктопа - ничего нового.

что WPF уходит в прошлое

Альтернативы под .net нету, никуда он уходить не может (не все пока хотят связываться с Metro и UWP приложениями).

1) определитесь, что у вас будет базовым документом. Т.е., чего у вас будет много. Сейчас, я так понимаю, это заказ. Итак, это документ и он будет множиться. Советую его сделать табами.
2) информационная панель и список пользователей вполне могут быть сделаны док-панелями справа и слева. Причина проста - на них придется часто смотреть, следить за ними. Постоянно переключаться не вариант. Правда, тогда они должны быть не так обильно наполнены элементами, как панель заказа, но мне кажется у вас как раз так и будет. Если у вас на инф. панели в основном сообщения, а на вкладке "список пользователей" - только этот список, ты выделять под такое весь экран нет смысла.

Итого: слева инф. панель (15-20%), справа список пользователей (15%), оставшееся по центру - таб-контрол для заказов, по принципу табов в браузере (можно даже плюсик сделать для создания нового заказа). Альтернативный варинт - инф. панель снизу, под таб-контролом для заказов

Windows Azure Table Storage

Для меня очевидно, что это писали бывшие разработчики на C/C++. Это древняя нотация, многие называют ее венгерской, только тут какой-то извращенный вариант (надо сказать, что и саму венгерку правильно применяли единицы в свое время, большинство не понимало до конца ее смысла). Сейчас так не пишут и на самих плюсах, для шарпа же это моветон. Выдает нотацию n перед именем индекса (это значит именно "индекс", а не int, правда обычно пишут nUnit или nEmployee, а не nIndex) и C перед именемами классов.

Если есть нормальная IDE, то венгерская нотация нафиг не нужна, код превращается в рябь из смеси сокращений, которые только раздражают

Совершенно согласен с вами.

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

Почти все классы в основном проекте лежат, никаких папок и соответствия им нэймспэйсов (за редким исключением).

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

А у вас было подобное? Вы как-то решали эту проблему?

А это кроме вашей команды во главе с тимлидом и даже с привлечением менеджеров никому не решить. Если вы готовы отрефакторить половину продукта - вперед. Не готовы - лучше не трогайте. Пишите новый код в адекватном стиле. Если бы это был C++, я бы даже вам посоветовал новый код оформлять по правилам проекта, но ЭТИ правила в рамках C# неадекватны совершенно.

Резюмирую: если нет ресурсов на переработку кода - терпите. Терпение и способность работать с legacy кодом не самого высокого качества - вероятно самая важная черта "программиста в команде". Старый и не самый симпатичный код - это реальность, это так же реально, как и ветхие здания, которые просто так не перестроишь без серьезных вложений.

Работал в одной организации полтора года, написал сам несколько проектов. код в плане оформления просто чуть ли не идеален. Без всякой чуши типа венгерской нотации и т.д.

Вам везло в плане качества кода. Теперь не очень повезло. Как сказал AtomKrieg, хорошо что не Кобол (хотя б тогда вам платили еще больше).

Над методами простые комментарии, а не XML или их вообще нет

Нормальные XML-комментарии в C# коде это вообще роскошь. Я их вижу только в серьезных библиотеках, а во всяком корпоративном треше так комментятся только самые важные классы в программе (штук 10-15). Радуйтесь, что вообще есть документация. Если есть желание и время - переносите в код, это наверняка будет полезно.

ORDER BY и LIMIT в SQL-запросе

> Хотел задать вопрос к опытным программистам.

Ну раз опытным, то думаю разумно поделиться своим опытом. Итак, в чем участвовал за последние 5-6 лет, где были плюсы или шарпы. Три места работы, три команды:
- десктопная софтинка наподобие 2ГИС - база данных услуг и предприятий с привязкой на карту. C#, карту отрисовывали сами с помощью Direct3D;
- TCP-сервер GPS-трекеров (такие фиговины, отправляют по GRPS/SMS свои текущие GPS/ГЛОНАСС координаты + всякие плюшки для транспорта - уровень топлива, скорость движения и т.д. - зависит от модели). C++ и обыкновенные сокеты. Сервер небольшой, принимал именно данные от трекеров и писал в базу. Отображалось все на обыкновенном сайте с PHP в бэкенде.
- веб-сервис, принимающий платежи по WebMoney Merchant и поддерживающий балансы на счетах клиентов. Открывал урл для серверов вебмани, плюс давал простейшие отчеты (проведена транзакция или нет, текущий баланс, транзакции на списание). C# (WCF), данные писались в PostgreSQL.
- десктопное приложение для проходной - по отпечаткам пальцев входящих/уходящих сотрудников регистрировалось их время пребывания на предприятии. Ну и разумеется - отчеты, агрегации (время отработанное за неделю, опоздания, переработки и т.д.). C# + некоторые части на С++, соединяющие драйвер сканера отпечатков и библиотеку их распознавания по образцам.
- здоровенное декстопное приложение на C++ + Qt, трейдинговый терминал (более 10к файлов исходников, команда из 30+ человек);
- довольно объемный ГИС-проект на C#, клиент десктопный (WPF+SharpMap), серверная часть - ASP.NET WebAPI (JSON API).
- планируется новый ГИС-проект с клиентом уже на C++ и Qt, т.к. существует нереально крутые рендереры на OpenGL от MapBox (тык), а большинству участников текущего проекта плевать - C++ или C#. Qt сейчас развивается очень серьезно, поэтому на сегодняшний день он выровнялся с C#+WPF, а т.к. рендерер на плюсах - то и клиента будем писать на плюсах. На сервере по-прежнему ASP.NET, вероятно новой версии (пока начнем писать, должна успеть выйти в релиз); тех, кто считает, что с ним "сложно в вебе" - аргументы в студию;
- небольшой сайд-проект - рендер сложного 3D объекта для внедрения в рекламный ролик новой фантастической книги. С++ и OpenGL, написано быстро, дешево и сердито, отрисовано покадрово в PNG-шки, смонтировано в After Effects, все довольны.

Вывод: поверьте, если инструмент подчиняется вам, то вам открыто много способов решения различных задач. Конечно, для Web-бэкенда C++ будет очень странным выбором, но лично у меня хватает задач и без бесконечных мелких сайтиков.

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

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

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

Я представляю решение вашей задачи как мини-IDE + шелл для работы с базой (непонятно кстати, какой лучше - SQL или, например, документной) в одном флаконе. Такие решения в общем-то существуют и имеют смысл - достаточно вспомнить про 1C с его конфигурациями и средствами разработки, или, например, про Лексему. Однако, я не уверен, что вы хотите и сможете получить подобное решение, раз задаете такой вопрос). Мне все-таки кажется, что ваша проблема более частная, а желание дать возможность администратору клепать формочки - острый недостаток в проработанном техническом задании и/или нежелание вашего клиента платить вам в последствии за развитие и техническую поддержку продукта, которое выливается в попытку переложить рутинные задачи (эти самые "новые поля", "новые формы и лэйблы" и прочие вещи) на дешевые кадры. В общем-то в этом есть смысл, однако чтобы это организовать, нужно довольно много стартовых затрат.

Спасибо за суммон.
В Висте и выше архитектура аудио подсистемы была переработана, поэтому современным API считается WASAPI, а WINMM считается устаревшим.
Можно разобрать следующий пример: blogs.msdn.com/b/larryosterman/archive/2007/03/06/...

Необходимые хедеры:

#include <windows.h>
#include <mmdeviceapi.h>
#include <endpointvolume.h>

Запустим COM:
CoInitializeEx(NULL, COINIT_MULTITHREADED);

Создадим перечислитель устройств:

IMMDeviceEnumerator *deviceEnumerator = NULL;
hr = CoCreateInstance(__uuidof(MMDeviceEnumerator), NULL, CLSCTX_INPROC_SERVER, __uuidof(IMMDeviceEnumerator), (LPVOID *)&deviceEnumerator);

Вытащим дефолтовый девайс:

IMMDevice *defaultDevice = NULL;
hr = deviceEnumerator->GetDefaultAudioEndpoint(eRender, eConsole, &defaultDevice);
deviceEnumerator->Release();
deviceEnumerator = NULL;

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

IAudioEndpointVolume *endpointVolume = NULL;
hr = defaultDevice->Activate(__uuidof(IAudioEndpointVolume), CLSCTX_INPROC_SERVER, NULL, (LPVOID *)&endpointVolume);
defaultDevice->Release();
defaultDevice = NULL;

Получим предыдущее значение громкости:

float currentVolume = 0;
endpointVolume->GetMasterVolumeLevel(&currentVolume);

Установим новое значение громкости:

hr = endpointVolume->SetMasterVolumeLevel((float)newVolume, NULL);

P.S. Не сразу обратил внимание, что у вас C#, постараюсь скорректировать ответ вечером.

Посмотреть бы на код, который регулярно считывает progressVal из модели и пихает в прогресс-бар. Иными словами, SetValProg откуда еще вызывается, кроме как при старте? Лично я пока не вижу никакой проблемы с потоками, про которую говорит tex0, т.к. из другого потока устанавливается только интовое поле у Model.

Console.KeyAvailable

"SELECT * FROM 'peoples';"

select name, year, age, city from peoples
Делать плановые запросы со звездочкой - моветон, оставьте звездочку для административной консоли.

object getname = people[0];

string name = peopleReader.getString(peopleReader.getOrdinal("name"));

Есть еще либа на свете - NAudio. Можно ей попробовать. Возможно, она сама не умеет качать по урлу, тогда скачайте сами WebClient-ом и отдайте либе.

> PersonsList
советую форму назвать PersonsListWindow.

Потом вам надо создать еще одну вьюмодельку - PersonsListViewModel, которая будет вьюмоделью для ВСЕЙ ФОРМЫ в целом, и у которой будет свойство Persons/PersonViewModels типа IObservableCollection. В этой коллекции у вас будут все вьюмодельки для каждого человека. Тогда вы вашей форме PersonsListWindow должны будете назначить PersonsListViewModel в качестве DataContext, а уже ваш контрол списка (ListView например, или DataGrid, смотря что там у вас) забиндить на свойство Persons/PersonViewModels. Это будет что называется, "по паттерну". Итого:
1) personsListWindow.DataContext = new PersonsListViewModel();
2) в XAMLе контрол-список (его свойство ItemsSource) биндите на свойство PersonViewModels
3) каждый элемент списка автоматически сопоставляется с вьюмоделькой из ObservableCollection.

Если потом на форму добавите еще контролы, то и во вьюмодельку для формы (PersonsListViewModel) сможете добавить еще данные для показа/модификации. Например, захотите в этом списке выбирать ответственного за работу человека - тогда можно сделать в PersonsListViewModel свойство Leader типа PersonViewModel. Или если у вас там будут кнопки Создать/Удалить - то можно выставить соответствущие ICommand-объекты.

А доки почитать? FindWindow, FindWindowEx (ищет также и дочерние)