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

Если я прохожусь циклом foreach

Не стОит удалять что-либо из коллекции, по который вы В ДАННЫЙ МОМЕНТ проходитесь foreach. Чревато исключениями по причине умерших енумераторов.

как уничтожить объект из массива, если имеется только его копия

Взять обычный for, определить критерии сравнения двух объектов (чтобы собственно выяснить, какой объект является "копией" - по ссылке не сравнишь, т.к. это уже другой самостоятельный объект) - по каким-либо свойствам или еще как-то, найти этот объект и удалить его смещением остальных элементов массива на его место. Если бы у вас был список, достаточно было бы RemoveAt.

разработка остановилась 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-объекты.