Есть принтеры штрихэтикеток, печать на этих принтерах осуществляется напрямую без участия драйвера (т.е. используется язык управления принтера). Для этого до настоящего времени используется ActiveX написанный на C++ мной еще в 2002 году. Вобщем принцип такой — на входе имеем унифицированный параметризованный шаблон этикетки (XML), XSLT трансформацию в язык принтера для разных производителей принтеров, на выходе получаем поток который валим на: LPTx, COMx, USBx, дисковый файл, сетевой пайп (для сетевых принтеров). Для этого используется внутрях ф-ция WinAPI CreateFile. Одна на все случаи.
Хотели поменять на сборку .Net. Но! Что за чушь? Я не могу открыть как файл как минимум LPT или COM. Любые классы потоков внутрях зовут конструктор FileStream-а и ошибка везде одна :
FileStream не открывает устройства Win32, такие как логические диски и ленточные накопители. Избегайте использования "\\.\" в пути.
Они что — в микрософте там совсем охренели?
Это что же это, мне надо экспортировать из WinAPI CreateFile, WriteFile? Ну гон...
Здравствуйте, _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").
Здравствуйте, _d_m_, Вы писали:
___>А что там может быть не так? Ведь всего делов-то было портировать набор необходимых ф-ций Win API в класс SerialPort.
Ключевое слово "WinAPI".
Вы не забывайте, что .NET какбэ в идеале кросплатформенный, а (есть ли / обладает ли подобным поведением) функционал, аналогичный CreateFile, на *nix-системах, например? Может Вы какие-нить виндовые mailslot юзать будете, которыми в линуксах и не пахнет, что тогда?
Нужен функционал WinAPI — так используйте его, какие проблемы...
Framework содержит более переносимый и абстрагированный от системы набор инструментов, не стоит удивляться тому, что там нету всего WinAPI...
Здравствуйте, Пельмешко, Вы писали: П>Вы не забывайте, что .NET какбэ в идеале кросплатформенный, а (есть ли / обладает ли подобным поведением) функционал, аналогичный CreateFile, на *nix-системах, например? Может Вы какие-нить виндовые mailslot юзать будете, которыми в линуксах и не пахнет, что тогда?
В никсах точно так же есть "специальные файлы" (в /dev, /proc, например) и с ними можно работать как с обычными. Т.е. портирование програмы потенциально могло было заключаться в замене "LPT" на какой-нить "/dev/lpt".
Так нет же. Порезали возможность пользоваться "специальными файлами" — и это уж никак не ради кроссплатформенности.
Здравствуйте, adontz, Вы писали:
A>Здравствуйте, _d_m_, Вы писали:
A>>>System.IO.Ports.SerialPort ___>>Есть огромное желание поставить тебе минус. Догадаешься за что?
A>У тебя что-то не работало и виноват класс FCL. Угадал? Лично у меня всё ОК, хотя и не скажу что с первого раза.
Нет, гадать не надо. Надо читать что я написал в исходном посте — благо там все четко и ясно расписано, и поэтому остальные "ответчики" дали четкие и ясные ответы. Вобщем получи "-", заслужил.
Здравствуйте, 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.
A>>У тебя что-то не работало и виноват класс FCL. Угадал? Лично у меня всё ОК, хотя и не скажу что с первого раза.
___>Нет, гадать не надо. Надо читать что я написал в исходном посте — благо там все четко и ясно расписано, и поэтому остальные "ответчики" дали четкие и ясные ответы. Вобщем получи "-", заслужил.
Это ты мне своими клонами минусов понатыкал? Ну если это хоть как-то утешит твои комплексы...
:
Тока интероп. У кого есть более ранние фрамворки, попробуйте плиз открыть FileStream("com1").
