Здравствуйте, adontz, Вы писали:
A>Здравствуйте, _d_m_, Вы писали:
A>>>System.IO.Ports.SerialPort ___>>Есть огромное желание поставить тебе минус. Догадаешься за что?
A>У тебя что-то не работало и виноват класс FCL. Угадал? Лично у меня всё ОК, хотя и не скажу что с первого раза.
Нет, гадать не надо. Надо читать что я написал в исходном посте — благо там все четко и ясно расписано, и поэтому остальные "ответчики" дали четкие и ясные ответы. Вобщем получи "-", заслужил.
Здравствуйте, _d_m_, Вы писали:
___>А что там может быть не так? Ведь всего делов-то было портировать набор необходимых ф-ций Win API в класс SerialPort.
Ключевое слово "WinAPI".
Вы не забывайте, что .NET какбэ в идеале кросплатформенный, а (есть ли / обладает ли подобным поведением) функционал, аналогичный CreateFile, на *nix-системах, например? Может Вы какие-нить виндовые mailslot юзать будете, которыми в линуксах и не пахнет, что тогда?
Нужен функционал WinAPI — так используйте его, какие проблемы...
Framework содержит более переносимый и абстрагированный от системы набор инструментов, не стоит удивляться тому, что там нету всего WinAPI...
Есть принтеры штрихэтикеток, печать на этих принтерах осуществляется напрямую без участия драйвера (т.е. используется язык управления принтера). Для этого до настоящего времени используется ActiveX написанный на C++ мной еще в 2002 году. Вобщем принцип такой — на входе имеем унифицированный параметризованный шаблон этикетки (XML), XSLT трансформацию в язык принтера для разных производителей принтеров, на выходе получаем поток который валим на: LPTx, COMx, USBx, дисковый файл, сетевой пайп (для сетевых принтеров). Для этого используется внутрях ф-ция WinAPI CreateFile. Одна на все случаи.
Хотели поменять на сборку .Net. Но! Что за чушь? Я не могу открыть как файл как минимум LPT или COM. Любые классы потоков внутрях зовут конструктор FileStream-а и ошибка везде одна :
FileStream не открывает устройства Win32, такие как логические диски и ленточные накопители. Избегайте использования "\\.\" в пути.
Они что — в микрософте там совсем охренели?
Это что же это, мне надо экспортировать из WinAPI CreateFile, WriteFile? Ну гон...
A>>У тебя что-то не работало и виноват класс FCL. Угадал? Лично у меня всё ОК, хотя и не скажу что с первого раза.
___>Нет, гадать не надо. Надо читать что я написал в исходном посте — благо там все четко и ясно расписано, и поэтому остальные "ответчики" дали четкие и ясные ответы. Вобщем получи "-", заслужил.
Это ты мне своими клонами минусов понатыкал? Ну если это хоть как-то утешит твои комплексы...
Здравствуйте, _d_m_, Вы писали:
___>Они что — в микрософте там совсем охренели?
"Бобер, выдыхай". (С)
По сабжу — да, только через интероп.
SerialPort — дрянь редкостная, настоятельно не рекомендую даже для RS-ных устройств, не гворя уже о том, что только с ними и умеет работать...
Здравствуйте, HowardLovekraft, Вы писали:
HL>Здравствуйте, _d_m_, Вы писали:
___>>Они что — в микрософте там совсем охренели? HL>"Бобер, выдыхай". (С)
Не, ну а чо? Это называется регресс. Когда CreateFile может работать c COM, LPT, USB, файлы, пайпы. А FileStream почему-то никак. Да и вообще с LPT в фрамворке никак.
HL>По сабжу — да, только через интероп. HL>SerialPort — дрянь редкостная, настоятельно не рекомендую даже для RS-ных устройств, не гворя уже о том, что только с ними и умеет работать...
А что там может быть не так? Ведь всего делов-то было портировать набор необходимых ф-ций Win API в класс SerialPort.
Здравствуйте, _d_m_, Вы писали:
___>А что там может быть не так?
Лень искать свой пост где-то двух-трехгодичной давности.
В кратце — попытка сделать нечто универсальное породила монстра, который некоторые вещи делать просто не умеет, а те, которые делает, делает довольно своеобразно, с большим количеством ненужных телодвижений.
Здравствуйте, HowardLovekraft, Вы писали:
HL>Здравствуйте, _d_m_, Вы писали:
___>>А что там может быть не так? HL>Лень искать свой пост где-то двух-трехгодичной давности. HL>В кратце — попытка сделать нечто универсальное породила монстра, который некоторые вещи делать просто не умеет, а те, которые делает, делает довольно своеобразно, с большим количеством ненужных телодвижений.
Но все-таки какой-никакой функционал есть. А вот зачем отрезать функционал? Как-быть с LPT Тока интероп. У кого есть более ранние фрамворки, попробуйте плиз открыть FileStream("com1").
Здравствуйте, Пельмешко, Вы писали: П>Вы не забывайте, что .NET какбэ в идеале кросплатформенный, а (есть ли / обладает ли подобным поведением) функционал, аналогичный CreateFile, на *nix-системах, например? Может Вы какие-нить виндовые mailslot юзать будете, которыми в линуксах и не пахнет, что тогда?
В никсах точно так же есть "специальные файлы" (в /dev, /proc, например) и с ними можно работать как с обычными. Т.е. портирование програмы потенциально могло было заключаться в замене "LPT" на какой-нить "/dev/lpt".
Так нет же. Порезали возможность пользоваться "специальными файлами" — и это уж никак не ради кроссплатформенности.
Здравствуйте, Mr.Cat, Вы писали:
MC>Здравствуйте, _d_m_, Вы писали: ___>>Они что — в микрософте там совсем охренели? MC>Сдается мне, решили таким образом "закрыть" какой-нить баг.
Здравствуйте, Пельмешко, Вы писали:
П>Здравствуйте, _d_m_, Вы писали:
___>>А что там может быть не так? Ведь всего делов-то было портировать набор необходимых ф-ций Win API в класс SerialPort.
П>Ключевое слово "WinAPI". П>Вы не забывайте, что .NET какбэ в идеале кросплатформенный, а (есть ли / обладает ли подобным поведением) функционал, аналогичный CreateFile, на *nix-системах, например? Может Вы какие-нить виндовые mailslot юзать будете, которыми в линуксах и не пахнет, что тогда?
Что-то я сильно сомневаюсь, что в МС озабочены данной проблемой. Это во первых.
Но даже если и так, отвечаю на вопрос "что тогда?" — выбросить исключение.
Более того, скажу что в *nix системах абстракция "устройства как файлы" развита более чем в Windows. Так что все даже проще.
Ты не путай две вещи: 1) набор классов, так сказать интерфейс FCL для моей проги, и 2) саму реализацию FCL, так сказать, что из WinAPI или какого другого API она вызывает. У меня как раз претензии ко второму.
П>Нужен функционал WinAPI — так используйте его, какие проблемы...
Ага, аналогия:
"
-В России нарушают права человека, что делать?
-Ну не нравится тебе жить в России езжай за бугор...
"
П>Framework содержит более переносимый и абстрагированный от системы набор инструментов, не стоит удивляться тому, что там нету всего WinAPI...
Удивительно непонимание.
Я как раз и требую переносимости и абстрагирования. Я открываю файл, а что за файл меня не волнует — дисковый, паралелльный порт или что еще. Причем все это реализуется через CreateFile — там это все есть. Вопрос: нахрен это отрезать?
В итоге код который мог бы быть таким:
var s = new FileStream(myFile);
превращается в анализ имени файла, выбор класса соответсвующего устройства, открытие потока для этого устройства.
Либо в интероп монстра CreateFile.