-_\\

ещё и не читает

кроме того ты можешь увеличить количество коннектов которые могут так висеть

что ему пишут

еще года два после его увольнения ошибки в нем хитрые искали

но httpClient тут при чём

не спасает

приходится штуки типа SO_REUSEADDR выставлять

если ты будешь через один httpClient дёргать каждый раз разные хосты, а не один, у тебя будет тоже подобное

ну говорю вам, держите либо статический экземпляр дефолтного хэндлера

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

я какую то фигню пишу да?

либо свого с нужными политиками

я какую то фигню пишу да?

да

я какую то фигню пишу да?

а что мешает подписаться на событие этого объекта? задача не очень понятна.

хочет, чтобы коллекция сама аггрерировала события всех элементов

хочет, чтобы коллекция сама аггрерировала события всех элементов

что то типа этого

так ты передай ему свой хэндлер

спасибо, ты мне сейчас открыл глаза на HttpClient. я че-то не задумывался, что мы ему передаем хэндлеры всегда для работы.

а как же ТА САМАЯ статья где срывают покровы насчет HttpClient?

что за статья?

хочет, чтобы коллекция сама аггрерировала события всех элементов

ну можно написать обертку чтобы при добавлении элемента происходила автоподписка

что за статья?

выше немного кинули уже ее

https://aspnetmonsters.com/2016/08/2016-08-27-httpclientwrong/

вот она

ну вот там игнорируются фичи клиента с дефолтными хидерами, поддержкой кук, вот этого всего

в чудо-статье вашей

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

можно хандлер вешать на каждый при добавлении в коллекцию

или свою коллекцию, которая делает это-же под капотом

в люом случае подписка явная нужна

Кто тут про телеграм говорил и голосовые звонки?)

http://telegra.ph/Predstoyashchie-obnovleniya-Telegram-Instant-View-platezhi-multi-akkaunt-i-golosovye-zvonki-02-28

можно айтемам подсовывать интерфейс и реализовать обсервабл

Кто тут про телеграм говорил и голосовые звонки?)

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

@tg_girl ты поясни чё делаешь точно

http://telegra.ph/Predstoyashchie-obnovleniya-Telegram-Instant-View-platezhi-multi-akkaunt-i-golosovye-zvonki-02-28

>платежи Теперь соли и миксы можно оплатить прям в телеег

"всегда диспозьте"

@nikita_tsukanov, таски тоже диспоузишь? PS: я не спорю, что HttpClient нужно диспоузить после использования, хотя нет смысла, если Singleton

@tg_girl ты поясни чё делаешь точно

есть базовый класс устройства, от него унаследованы классы DeviceX и DeviceY, они получают байтовый поток от устройств полключенных к COM-порту, я детектирую что устройства подключены к компьютеру, и создаю соответствующий объекты ObjDeviceX_1, ObjDeviceX_2, ObjDeviceY_1 например. Кладу их в коллекцию. Теперь мне нужно обработать события, когда от устройства в COM порт приходит пакет. Т.е. в каждом классе должно быть событие например DeviceReceive. Че дальше делать мне как-то малопонятно

<sarcasm>В любой непонятной ситуации делай Dispose</sarcasm>

в общем да

есть базовый класс устройства, от него унаследованы классы DeviceX и DeviceY, они получают байтовый поток от устройств полключенных к COM-порту, я детектирую что устройства подключены к компьютеру, и создаю соответствующий объекты ObjDeviceX_1, ObjDeviceX_2, ObjDeviceY_1 например. Кладу их в коллекцию. Теперь мне нужно обработать события, когда от устройства в COM порт приходит пакет. Т.е. в каждом классе должно быть событие например DeviceReceive. Че дальше делать мне как-то малопонятно

лучше в объект в конструкторе, или в сеттере прокидывай делегат(Action<> Func<> или свой) и дергай изнутри объекта, если делегат не null, тогда можно зависимости развязать будет, и параметр, где делегат прописывается, если параметр не один, то default value не забудь, чтоб можно было не указывать

лучше сразу поймать ObjectDisposedException

чем потом искать утечку ресурсов

Лучше почитать документацию

Чем потом ругать шарп за тормоза

правильно ли я понимаю работу try catch try { some code} catch (OneException) { do this } catch (AnotherException) { do that } catch (Exception ex) { Console.WriteLine(ex.Message) } либо отработает без исключений, либо будет обработан код, соответсвующий одному из указаных исключений, либо любое из остальных исключений будет выведено в консоль?

правильно ли я понимаю работу try catch try { some code} catch (OneException) { do this } catch (AnotherException) { do that } catch (Exception ex) { Console.WriteLine(ex.Message) } либо отработает без исключений, либо будет обработан код, соответсвующий одному из указаных исключений, либо любое из остальных исключений будет выведено в консоль?

д

лучше в объект в конструкторе, или в сеттере прокидывай делегат(Action<> Func<> или свой) и дергай изнутри объекта, если делегат не null, тогда можно зависимости развязать будет, и параметр, где делегат прописывается, если параметр не один, то default value не забудь, чтоб можно было не указывать

как все сложно...

правильно ли я понимаю работу try catch try { some code} catch (OneException) { do this } catch (AnotherException) { do that } catch (Exception ex) { Console.WriteLine(ex.Message) } либо отработает без исключений, либо будет обработан код, соответсвующий одному из указаных исключений, либо любое из остальных исключений будет выведено в консоль?

При условии, чтоAnotherException не наследует OneException

правильно ли я понимаю работу try catch try { some code} catch (OneException) { do this } catch (AnotherException) { do that } catch (Exception ex) { Console.WriteLine(ex.Message) } либо отработает без исключений, либо будет обработан код, соответсвующий одному из указаных исключений, либо любое из остальных исключений будет выведено в консоль?

ток учти что по порядку проверка идет, потому наиболее общее идет всегда последним

как все сложно...

ща экзампл накидаю)

лучше в объект в конструкторе, или в сеттере прокидывай делегат(Action<> Func<> или свой) и дергай изнутри объекта, если делегат не null, тогда можно зависимости развязать будет, и параметр, где делегат прописывается, если параметр не один, то default value не забудь, чтоб можно было не указывать

можно проще

ток учти что по порядку проверка идет, потому наиболее общее идет всегда последним

да, потому такой порядок и указал (иначе студия15 ругается)

есть базовый класс устройства, от него унаследованы классы DeviceX и DeviceY, они получают байтовый поток от устройств полключенных к COM-порту, я детектирую что устройства подключены к компьютеру, и создаю соответствующий объекты ObjDeviceX_1, ObjDeviceX_2, ObjDeviceY_1 например. Кладу их в коллекцию. Теперь мне нужно обработать события, когда от устройства в COM порт приходит пакет. Т.е. в каждом классе должно быть событие например DeviceReceive. Че дальше делать мне как-то малопонятно

ну можно сделать как написала. Описать в базовом классе или в наследниках событие, потом на них подписать нужные обработчики и всё

class ItemEventList : List<Device> { public event EventHandler ItemEventTriggered; public new void Add(Device item) { base.Add(item); item.DeviceReceive += ItemOnDeviceReceive; } private void ItemOnDeviceReceive(object sender, EventArgs eventArgs) { ItemEventTriggered?.Invoke(this, EventArgs.Empty); } } class Device { public event EventHandler DeviceReceive; public void FireEvent() { DeviceReceive?.Invoke(this, EventArgs.Empty); } }

то есть непонятно, зачем тебе какие-то события от коллекции вообще нужны нужны.

спасибо! я все записываю)

а потом кто-нибудь вызовет Clear

а потом кто-нибудь скастует к IList

в общем, это, не надо наследовать ничего

то есть непонятно, зачем тебе какие-то события от коллекции вообще нужны нужны.

ну а как еще? Несколько сходных устройств подключено к компу, как мне кажется логично сложить классы которые их обслуживают в коллекцию

а потом кто-нибудь вызовет Clear

естественно, это не готовое решение

положить список в поле и пробросить наружу энумератор

это не "не готовое" решение, это неправильное решение

ну а как еще? Несколько сходных устройств подключено к компу, как мне кажется логично сложить классы которые их обслуживают в коллекцию

ну я вижу смысла что-то куда-то складывать только за тем, чтобы сделать некоторого "менеджера соединений", в задачи которого будет входить отслеживание времени жизни и реюз этих объектов.

а где хранить - пофиг. ну сложила ты в список, что от этого меняется? события у каждого объекта свои

ну я вижу смысла что-то куда-то складывать только за тем, чтобы сделать некоторого "менеджера соединений", в задачи которого будет входить отслеживание времени жизни и реюз этих объектов.

да менеджер нужен, чтобы устройства можно было подключать нагорячую, без перезагрузки программы, нужен какой-то список устройств которые сейчас доступны

а где хранить - пофиг. ну сложила ты в список, что от этого меняется? события у каждого объекта свои

я еще плохо шарпы знаю, до этого приходилось писать на Си

приходится все изучать на ходу

ERROR: S client not available

если знаешь си, то пиши в стиле си. ооп-огород появится сам собой)

ну руководство хочешь хороший проект на С# в ООП стиле, потому что старый написан на билдере в си стиле, ужасно глючный и кривой

ну а как еще? Несколько сходных устройств подключено к компу, как мне кажется логично сложить классы которые их обслуживают в коллекцию

https://gist.github.com/dron247/4f94a36a3ac8310bc1cb40da439f63f1 Намутил, делал в блокноте, но должно вродь скомпилиться

https://gist.github.com/dron247/4f94a36a3ac8310bc1cb40da439f63f1 Намутил, делал в блокноте, но должно вродь скомпилиться

спасибо!

class ItemEventList : List<Device> { public event EventHandler ItemEventTriggered; public new void Add(Device item) { base.Add(item); item.DeviceReceive += ItemOnDeviceReceive; } private void ItemOnDeviceReceive(object sender, EventArgs eventArgs) { ItemEventTriggered?.Invoke(this, EventArgs.Empty); } } class Device { public event EventHandler DeviceReceive; public void FireEvent() { DeviceReceive?.Invoke(this, EventArgs.Empty); } }

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

class ItemEventList : List<Device> { public event EventHandler ItemEventTriggered; public new void Add(Device item) { base.Add(item); item.DeviceReceive += ItemOnDeviceReceive; } private void ItemOnDeviceReceive(object sender, EventArgs eventArgs) { ItemEventTriggered?.Invoke(this, EventArgs.Empty); } } class Device { public event EventHandler DeviceReceive; public void FireEvent() { DeviceReceive?.Invoke(this, EventArgs.Empty); } }

а почему тут выпросительные знаки? ...DeviceReceive?

посоветуйте пожалуйста справочник по c#, кроме msdn и google )

а почему тут выпросительные знаки? ...DeviceReceive?

Это типа поверки на null

ну ничего не известно же. я узнал только то, что обработчиков может быть много. известно про 2 сценария 1. пишем стрим в файл 2. пишем стрим подключившемуся пользователю. теперь представим, что сидим и штатно пишем в файл. тут приходит юзер, который хочешь послушать в риалтайме. как нам быть есть мы инжектим какие-то хендлеры или делегаты в конструкторе? А если ничего не городить вообще, то можно зробить что-то вроде var deviceObj = deviceObjects.Single(d => d.Identity == "some_id"); var handler = (sender, data) => SendToUser(sender, data, user, ...); deviceObj.DataRevieved += handler; .... //когда закончили deviceObj.DataRevieved -= handler;

ну ничего не известно же. я узнал только то, что обработчиков может быть много. известно про 2 сценария 1. пишем стрим в файл 2. пишем стрим подключившемуся пользователю. теперь представим, что сидим и штатно пишем в файл. тут приходит юзер, который хочешь послушать в риалтайме. как нам быть есть мы инжектим какие-то хендлеры или делегаты в конструкторе? А если ничего не городить вообще, то можно зробить что-то вроде var deviceObj = deviceObjects.Single(d => d.Identity == "some_id"); var handler = (sender, data) => SendToUser(sender, data, user, ...); deviceObj.DataRevieved += handler; .... //когда закончили deviceObj.DataRevieved -= handler;

ловить эти данные забота контейнера, иначе - это нарушение инкапсуляции. Ну, это если нужно в хорошем стиле с правильным ООП, Di и прочими умными словами, проброс из воркера мимо менеджера - хороший шорткат, но если проект большой - будет пиздец в поддержке, правильнее черный ящик иметь и даже внутренние дата-объекты не экспозить, а переоборачивать в дата-объекты следующего слоя абстракции

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

Вы щас начинающему разработчику C# насоветуете)

ловить эти данные забота контейнера, иначе - это нарушение инкапсуляции. Ну, это если нужно в хорошем стиле с правильным ООП, Di и прочими умными словами, проброс из воркера мимо менеджера - хороший шорткат, но если проект большой - будет пиздец в поддержке, правильнее черный ящик иметь и даже внутренние дата-объекты не экспозить, а переоборачивать в дата-объекты следующего слоя абстракции

А потом, продираясь через 5 слоев абстракций, пытаешься со всем этим взлететь

вместо того чтоб формы писать за 15$/h

несут хуйню какую-то

акторы-хуякторы

А потом, продираясь через 5 слоев абстракций, пытаешься со всем этим взлететь

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

акторы-хуякторы

+++

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

Их придумали, чтобы твой говнокод никто не нашёл)

вместо того чтоб формы писать за 15$/h

ты скажы, что в сеть в Button1Click еще ходишь)

ты скажы, что в сеть в Button1Click еще ходишь)

Звучит как труп десктопа

Я не некрофил

ты скажы, что в сеть в Button1Click еще ходишь)

синхронно

Их придумали, чтобы твой говнокод никто не нашёл)

Так и есть, вот смотришь на мульён файла с красивыми абстракциями и анжинерными решениями, но потом докапываешься до кода который делает **экшуал ворк**...

А потом, продираясь через 5 слоев абстракций, пытаешься со всем этим взлететь

+

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

и в каждом ебаном методе по перевызову другого метода, но зато энтерпрайзненько

1. Пишешь говнокод 2. Прячешь его за 5 слоями абстракций, чтобы никто его не нашел 3. Выкладываешь на гитхаб, все восхищаются твоими абстракциями 4. Тебя зовут выступать на конференциях

1. Пишешь говнокод 2. Прячешь его за 5 слоями абстракций, чтобы никто его не нашел 3. Выкладываешь на гитхаб, все восхищаются твоими абстракциями 4. Тебя зовут выступать на конференциях

чет ржанул

и в каждом ебаном методе по перевызову другого метода, но зато энтерпрайзненько

Типы то все завернули в свои? Вот пример сииильно сокращённого интероп хелпера, к нему в итоге обращается вагон красивых абстракнтых айтемов, БЛЛ там всякие, вьюмодели, в итоге в сборщике тупо руками создается/генерится лист и туда вписывается лямбда с вызовом апишки https://gist.github.com/dron247/5e3df3b69fe6f595bf9a3aed1774fa7d