pi314

Как сделать, чтобы получаемые символы на определенных местах записывались в, например, заранее оглашенные переменные?

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

Сделать это можно регулярками, циклами или любым другим замысловатым способом, но, прежде, чем это делать, нужно понять, что именно делать. А тут возможны варианты.

1. Строка именно такая, как описано в вопросе, и изменить ее нет возможности, т.к. ее посылает "чужой" код.
Тогда нужно описать структуру разделителей интересующих частей регулярным выражением (если она вообще регулярна) и выделять их регуляркой, например, так:

string[] tokens = Regex.Split("Change position: F1-F2", @"(: )|(-)", RegexOptions.ExplicitCapture);

if( tokens.Length == 3 && string.Equals(tokens[0], "Change position") )
{
  curPos = tokens[1];
  newPos = tokens[2];
} else {
  // прислали какую-то непонятную хрень...
}

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

2. Строку можно определить самостоятельно.
Тогда лучше придумать протокол (конкретнее, формат строки), который было бы легко разбирать. Например:

event:cur-position:new-position

т.е. для данного примера посылать:

"Change position:F1:F2"

Такую строку можно разобрать элементарным

string[] tokens = "Change position:F1:F2".Split(':');

if( tokens.Length == 3 && string.Equals(tokens[0], "Change position") )
{
  curPos = tokens[1];
  newPos = tokens[2];
} else {
  // прислали какую-то непонятную хрень...
}

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

Что конкретно значит "помог бы"? Однозначного хака, который сам собой все решит, скорее всего нет. Самый грязный хак, какой можно навскидку придумать - в БД добавить constraint на уникальность комбинации всех вставляемых полей, типа:

CREATE TABLE example (
    a integer,
    b integer,
    c integer,
    UNIQUE (a, c)
);

Подробности: Раз - Два.

Это исключит на уровне БД саму возможность повторной вставки, однако, сильно просадит перформанс вставок вообще (и, заодно, может полoмать другие кривые места, если такие есть). "Поможет" ли это - вопрос неоднозначный, т.к., если проблема действительно в повторной вставке, в коде наверняка где-то (скорее всего, в недрах NpgsqlCommand), всплывет Exception (constraint violation). Возможно, это поможет найти кривое место :) Заодно это поможет выяснить, нет ли в БД уже дубликатов, т.к. если они есть, добавить constraint просто не удастся до тех пор, пока их не вычистить.

А кроме того, "в БД оказывается два экземпляра данных" cамо по себе требует уточнения. Если Вы смотрите в БД какой-нибудь независимой тулзой, то это одно, а если с помощю самого "кривого проекта", то проблема запросто может быть на самом деле не в БД, a в запросе, которым он выбирает данные из БД, или вообще в архитектуре (когда второй экземпляр появляется не из БД, а из какого-нибудь внутреннего списка, куда он тупо вставляется). В таком случае добавление constraint ничего не даст, но, опять же, этим и поможет локализовать проблему.

UPD: В любом случае, самое правильное - с помощью этого (или подобного) хака найти проблему, после чего хак убрать! :)

UPD2: Судя по тому, как передаются значения полей для вставки (в конструктор), этот "проект" - Эльдорадо для любителей SQL Injection. Так что, не удивляйтесь, когда в один не самый прекрасный день хакеры пришлют вам поздравительную открытку :)

XP / 2003

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\WZCSVC\Parameters\Interfaces\{xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx}

Vista / 7 / 8

C:\ProgramData\Microsoft\Wlansvc\Profiles\Interfaces\{xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx}\{Random-GUID}.xml

где ххх - GUID соотв. интерфейса.

Однако, они хранятся там в зашифрованом виде, и для расшифровки нужно воспользоваться соотв. функциями Windows Cryptography, в частности CryptUnprotectData. Однако, (чтоб жизнь не казалась малиной!) сделать это можно только в системном контексте, так что, код придется инжектить через NtCreateThreadEx или выполнять в установленном системном сервисе.

Учитывая все эти подскоки, не думаю, что имеет смысл детально разбирать, как это все сделать, ибо, если Ваш уровень понимания это позволяет, приведенных данных достаточно для самостоятельного движения в нужном направлении, а если нет, то это все равно не поможет. Тогда лучше воспользоваться готовыми рабочими тулзами, которых на просторах Инета тонны.

Вам поможет только ProcessBuilder.

Подробные примеры.

Никакой "официальной" жесткой конвенции на этот счет нет. Как уже указал RGV, какую конвенцию использовать - личное дело команды / фирмы / техдира.
Я сам в свое время пришел к Java из Pascal и .NET, и тоже придерживаюсь нотации с I, т.к. это позволяет в коде визуально отличить интерфейс от класса. Просто для примера:

...
  IProducer simpleProducer = new Producer();
  IProducer sofisticatedProducer = new SpecialProducer();
...
  public void produceSomething(IProducer producer);

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