Здравствуйте, AndrewVK, Вы писали:

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

Ура! Наконец дождался самого интересного для меня лично мнения о моём "творчестве". И трёх лет не прошло.

Долго ждал, и как и предполагал, оно весьма критичное. Всегда, если сразу не отвечают, значит, что-то не так.

Но давай по-порядку.

Надеюсь, никто не ожидал увидеть от меня идеальный код, да ещё такой, чтобы Андрею по вкусу пришёлся.

Мы бы тут долго ещё мусолили вопрос про индикацию процесса — я просто взял и сделал один из вариантов. Не идеальный, но работающий, выполняющий вполне конкретные инструментальные функции, которые есть потребны пользователям Януса.

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

Первым делом я сделал регистрацию переданных/принятых байт в лог. Надежда на то, что я буду заранее знать объём данных с сервера, не оправдалась после опыта. Таким образом индикация прогрессами (показывающими изменения от начала и до конца) стала невозможна. Убирать индикатор я не стал, просто переделал ему метод Next(). И добавил накопительные поля для собствеено переданных/принятых байт.

В данном контретном случае индикатор может показывать только "наличие движения в канале". Этого можно достичь авишкой из эксплорера с летящими из папки в папку файлами, этого можно достичь секторным индикатором, который после заполнения голубенькими секторами пойдёт на второй круг с иным (более голубым) цветом, а затем на третий круг с голубым и так далее. Можно целый диапазон цветов расписать, чтобы визуально было понятно, какую сотню КБт сейчас снимает Янус. Мне править и делать такой индикатор не захотелось.

Индикатор я оставил просто для красоты, функционал умещается в двух лабелах.

А вот события в лог бессмысленными не считаю. Возможно, их стоило делать одно. Но показать разные картинки на принятые/отправленные байты тогда нельзя. А мне очень хотелось. Потому что так удобно, так делают другие программы (качалки), так визуально различимо для человека... Много ещё "почему". Плюс образовательная, т.к. я изучаю Янус на примере.

У меня свой взгляд на лог и протоколирование событий, но как я понял, Андрей тоже имеет на него свой взгляд и не считает необходимым его обсуждать с кем-либо. Ну и ладно. Можно заменить это на обычные (сливающиеся в сингл) информационные сообщения.

Что же до правки автогенерённого кода, то мне известен только один способ перехвата трафика СОАП-экстендерами — назначение атрибутов. Других пока не знаю. Возможно, следует указать атрибуты перехвата вебсервису, и тогда Студия будет автогенерить правильные файлы с нужными атрибутами. Но доступа к вебсервису у меня нет, проверить эти предположения я не могу. Так что малой кровью.

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

AVK> От принципиальной возможности путем кучи подкруток и подправок до реальной фичи очень большой путь, но большинство его просто не проходят, потому что ковыряться и править баги и недоделки скушно и неинтересно. Проблема только в том что править и дописывать за вами некому.

Хотя я и в чём-то согласен с отдельными словосочетаниями, всё-же напоминает брюзжание преподователя на студента: "Блин, вот взял и сделал, а я же знал, что и как сделать, но влом было делать, да и коряво всё сделал, не по правильному, не по моему... Хоть больше с лабой никто и не справился, поставлю-ка я ему три с плюсом, а остальным двойки..."

Уже сейчас можно заменить сообщения в лог на LogInfo(), индикатор убрать, лабелы оставить, кнопки вернуть на линию с лабелами, развернуть верхний список обратно вправо и заставить его скроллироваться, чтобы было видно последнее сообщение — и будет функционально. Люди будут видеть, кому надо — в логе увидят трафик Януса. Чего ты упрямишься-то? Это же очевидно. И люди (пользователи Януса) этого просто жаждют.

Ну тяжёлый же ты на подъём...

Здравствуйте, akasoft, Вы писали:


A>Что же до правки автогенерённого кода, то мне известен только один способ перехвата трафика СОАП-экстендерами — назначение атрибутов. Других пока не знаю. Возможно, следует указать атрибуты перехвата вебсервису, и тогда Студия будет автогенерить правильные файлы с нужными атрибутами. Но доступа к вебсервису у меня нет, проверить эти предположения я не могу. Так что малой кровью.

Наследование. И мало того там есть специально для этого уже отнаследованный класс.

A>Уже сейчас можно заменить сообщения в лог на LogInfo(), индикатор убрать, лабелы оставить, кнопки вернуть на линию с лабелами, развернуть верхний список обратно вправо и заставить его скроллироваться, чтобы было видно последнее сообщение — и будет функционально. Люди будут видеть, кому надо — в логе увидят трафик Януса. Чего ты упрямишься-то? Это же очевидно. И люди (пользователи Януса) этого просто жаждют.

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

С Уважением, Andir!

Здравствуйте, Andir, Вы писали:

A>Наследование. И мало того там есть специально для этого уже отнаследованный класс.

Предлагаешь отнаследовать все методы? Наверное, я чего-то не понимаю...

A>>... И люди (пользователи Януса) этого просто жаждют.

Эта фраза смущает?

A>Никогда не говори за других, это раз.

Говорю о тех, кто про индикатор постил в форум, раз; о тех, кто ставил мне баллы за пост, два. Имею право? Или перечислить линки на сообщения as доказательство? Выделенное заметно? Я говорю "о тех", обобщая (собирая, выделяя, напоминая, подчёркивая, ...) их слова, на которые могу привести линки. И что за привычка ярлыки вешать, теперь кто прочитает, будет считать меня демагогом, подавляющим мысли других и несущих отсебятину...

A> Во вторых недоделанные вещи на самом деле всегда производят "неизгладимое" впечатление на продукт. И тебе как программисту это следует знать очень и очень хорошо.

Ты код Януса видел, я тоже. Не бросается в глаза разный стиль в одном модуле, а например, в MainForm.cs или DatabaseManager.cs ?

Ну вот, ты меня наждачком по головке. А за что? Не написал. Ну и надо было тогда отвечать?

За возможную резкость фраз приношу извинения. Заранее. Мои фразы надо читать в резком тоне, если кто его не заметил.
И ещё. Употребляя имя "Андрей" я имею ввиду вполне конкретного Андрея Корявченко...

Здравствуйте, akasoft, Вы писали:


A>Предлагаешь отнаследовать все методы? Наверное, я чего-то не понимаю...

Предлагаю твои атрибуты вынести в отнаследованный класс и перекрыть (override) методы базового класса.

A>>Никогда не говори за других, это раз.

Эта фраза смущает ?

A>Говорю о тех, кто про индикатор постил в форум, раз; о тех, кто ставил мне баллы за пост, два.

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

A>Имею право? Или перечислить линки на сообщения as доказательство? Выделенное заметно? Я говорю "о тех", обобщая (собирая, выделяя, напоминая, подчёркивая, ...) их слова, на которые могу привести линки.

Зачем? Тебе совета мало показалось? Я обратил внимание, что ты некорректно выражаешься от имени других и всё. Конкретно мне не понравилось, что ты в общем то и от моего имени повесил свою фразу. Я не прав?

A>И что за привычка ярлыки вешать, теперь кто прочитает, будет считать меня демагогом, подавляющим мысли других и несущих отсебятину...

Опять за чужое мнение пытаешься уцепится ...

A>> Во вторых недоделанные вещи на самом деле всегда производят "неизгладимое" впечатление на продукт. И тебе как программисту это следует знать очень и очень хорошо.
A>Ты код Януса видел, я тоже. Не бросается в глаза разный стиль в одном модуле, а например, в MainForm.cs или DatabaseManager.cs ?
A>Ну вот, ты меня наждачком по головке. А за что? Не написал. Ну и надо было тогда отвечать?

Долго думал, что ты хотел сказать, и в резком тоне и не в резком ... но всё равно не понял. Есть стандарт написания кода в проекте, вот его и придерживайся. А то что разный стиль — это осталось от ранних версий, просто руки туда ещё не добрались.
То что недоделана вещь, тебе сказал AVK. Думаю стоит прислушаться и доделать.
Сразу говорю, что идеи твои очень привлекательны и про фич-трекинг не просто так WFrag сказал, не хотелось бы чтобы утонули твои мысли в общем потоке. У кого-нить время освободится и реализует, если ты к тому времени не сделаешь. Так что тебе и карты в руки.

A>За возможную резкость фраз приношу извинения. Заранее. Мои фразы надо читать в резком тоне, если кто его не заметил.

Даже не намекай. Хочешь что-то сказать — говори прямо, а вуалировать нечего.

С Уважением, Andir!

Здравствуйте, AndrewVK, Вы писали:

AVK>Я тебя предупреждал, между прочим. Толку от того что ты перебил запросы никакого. В релиз вариант, для которого нужно полчаса править руками mssql и текстовые конфиги не пойдет. Если бы проблема была только в запросах уже давно бы переделали.

Андрей, ты нифига не слушаешь что я тебе тогда говорил и что сейчас говорю.
Запросы в любом случае придется переписывать. Переписывать не в том смысле, что там что то не правльно, а в том смысле что практически везде сейчас стоят знаки % как обозначение параметров. MSSQL их не просекает !! Нужно везде будет на "?" переписывать. Плюс к этому "inline" построения запросов тоже придется переписывать на параметризованные. К примеру маркер чтения пишется в базу запаросом типа "UPDATE... SET isread = " + isread.ToString()... Ну не КАТИТ это в MSSQL.
Если бы тогда из моих искодников переняли хотя бы исправленные запросы, то уже делать бы пришлось на 70% меньше.

AVK>И заодно придумать механику переключения между источниками и создание БД. Это задач5и посложнее будут. А переписывать запросы особо не надо, SQL у акцесса и mssql очень похож, практически одинаков.

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


HD>Едиственное неудобство (и я так понял именно поэтому сейчас все так и ползает под Access) это отсутсвие механизмов модификации структуры баы данных.

AVK>Это не неудобство, это фатальный недостаток твоего варианта, из-за которого никто твои изменения в релиз не втаскивает

Блин... я же говорю... структуру MSSQL можно так же легко изменять как и акцесс. Все делается обычным MSSQL скриптом, т.е. теми же SQL запросами, что и все селекты и апдейты. Просто этот скрипт тоже кто то должен написать (или в профайлере сдампить)

AVK>Ты заметил что твоим вариантом так практически никто и не воспользовался?

Заметил, но меня это не огорчает, так как несколько месяцев назад я был чуть ли не единственный кого больше прельщала MSSQL база чем Access. Возможно сейчас появилось еще 2-3 человека. Но большая часть народа все равно останется сидеть на mdb, так как MSSQL база по любому требует больше административной работы, полность на автомате все равно не возможно это сделать.

Здравствуйте, akasoft, Вы писали:

A>Надеюсь, никто не ожидал увидеть от меня идеальный код, да ещё такой, чтобы Андрею по вкусу пришёлся.

Идеальный нет, но тот что у тебя придется дорабатывать напильником.

A>Мы бы тут долго ещё мусолили вопрос про индикацию процесса — я просто взял и сделал один из вариантов. Не идеальный, но работающий, выполняющий вполне конкретные инструментальные функции, которые есть потребны пользователям Януса.

А что этот вариант дает? Показывает одну из возможностей сделать это? Ну так статьи на мсдн вполне достаточно.

A>Я не обсуждал, то что сделал, ни с кем, потому что это бы затянулось на долгие дни и "принципиальные" вопросы, типа цвета секторов.

Это бы не затянулось.

A>В данном контретном случае индикатор может показывать только "наличие движения в канале". Этого можно достичь авишкой из эксплорера с летящими из папки в папку файлами, этого можно достичь секторным индикатором, который после заполнения голубенькими секторами пойдёт на второй круг с иным (более голубым) цветом, а затем на третий круг с голубым и так далее. Можно целый диапазон цветов расписать, чтобы визуально было понятно, какую сотню КБт сейчас снимает Янус. Мне править и делать такой индикатор не захотелось.

Вот о том и речь. Тебе доведением до ума заниматься не хочется, а больше некому, никто добровольно неинтересной работой заниматься не будет.

A>А вот события в лог бессмысленными не считаю.

Я не про события вобще писал, а про то что ты ввел два новых типа. Это неверно.

A> Возможно, их стоило делать одно. Но показать разные картинки на принятые/отправленные байты тогда нельзя.

И не нужно.

A>А мне очень хотелось.

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

A>У меня свой взгляд на лог и протоколирование событий,

При чем тут взгляд? Тип события отвечает критичности этого события. А ты внес абсолютно нелогичное дополнение.

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

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

A>Что же до правки автогенерённого кода, то мне известен только один способ перехвата трафика СОАП-экстендерами — назначение атрибутов. Других пока не знаю. Возможно, следует указать атрибуты перехвата вебсервису, и тогда Студия будет автогенерить правильные файлы с нужными атрибутами. Но доступа к вебсервису у меня нет, проверить эти предположения я не могу.

Проверять предположения надо не правкой сервиса, а чтением мсдн. Оно быстрее и безопаснее.

A>Хотя я и в чём-то согласен с отдельными словосочетаниями, всё-же напоминает брюзжание преподователя на студента: "Блин, вот взял и сделал, а я же знал, что и как сделать, но влом было делать, да и коряво всё сделал, не по правильному, не по моему... Хоть больше с лабой никто и не справился, поставлю-ка я ему три с плюсом, а остальным двойки..."

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

A>Уже сейчас можно заменить сообщения в лог на LogInfo(), индикатор убрать, лабелы оставить, кнопки вернуть на линию с лабелами, развернуть верхний список обратно вправо и заставить его скроллироваться, чтобы было видно последнее сообщение — и будет функционально.

ИМХО надо добавлять. То что ты предлагаешь может многим не понравится.

A>Люди будут видеть, кому надо — в логе увидят трафик Януса. Чего ты упрямишься-то? Это же очевидно. И люди (пользователи Януса) этого просто жаждют.

Говори только за себя, ОК?

A>Ну тяжёлый же ты на подъём...

Мужик, тебе же ясно написали — я в отпуске. Во-первых нет никакого желания ковыряться еще и с втоим кодом, во-вторых инет здесь дорогой.

Здравствуйте, HotDog, Вы писали:

HD>Андрей, ты нифига не слушаешь что я тебе тогда говорил и что сейчас говорю.
HD>Запросы в любом случае придется переписывать. Переписывать не в том смысле, что там что то не правльно, а в том смысле что практически везде сейчас стоят знаки % как обозначение параметров.

Слушай, мужик, на замену имен параметров нужно полчаса и это не та работа, о которой нужно сильно заботится, поскольку особого напряжения мозгов не требует. Знаки % в качестве обозначения параметров вобщ0е не используются. Используетося знак @ перед именем в mssql и ? у джета.

HD>Если бы тогда из моих искодников переняли хотя бы исправленные запросы, то уже делать бы пришлось на 70% меньше.

Не на 70, а процентов на 10, не больше. Более того — в новой версии очень большое количество запросов просто переписано.

HD>Механику я тогда предложил, возможно не очень удобный вариант,

Это жутко неудобный вариант.

AVK>>Это не неудобство, это фатальный недостаток твоего варианта, из-за которого никто твои изменения в релиз не втаскивает

HD>Блин... я же говорю... структуру MSSQL можно так же легко изменять как и акцесс.

Ну предположим я тебе верю. Дальше что? Опять надеешься что кто то сделает?

HD>Все делается обычным MSSQL скриптом, т.е. теми же SQL запросами, что и все селекты и апдейты. Просто этот скрипт тоже кто то должен написать (или в профайлере сдампить)

Вот именно что кто-то. Вот только такой простой вариант не прокатит — нужна еще реструктуризация БД при изменении ее структуры.

AVK>>Ты заметил что твоим вариантом так практически никто и не воспользовался?

HD>Заметил, но меня это не огорчает,

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

HD>так как несколько месяцев назад я был чуть ли не единственный кого больше прельщала MSSQL база чем Access. Возможно сейчас появилось еще 2-3 человека. Но большая часть народа все равно останется сидеть на mdb, так как MSSQL база по любому требует больше административной работы,

Это неверная предпосылка. Если БД будет создаваться автоматически то ее будет столько же, сколько и с джетом. Что же касается установки mssql то у многих он уже есть. А в следующих виндах будет у всех по дефолту.

HD>полность на автомате все равно не возможно это сделать.

Возможно.

Здравствуйте, Andir, Вы писали:

A>Предлагаю твои атрибуты вынести в отнаследованный класс и перекрыть (override) методы базового класса.

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

A>>>Никогда не говори за других, это раз.

A>Эта фраза смущает ?

Скорее да, чем нет. Дело в том, что вверху письма написано "От <чьё-то имя>", и я не вижу большого смысла строить фразы, начиная их с "По моему, ...". Мне ясно и так, что когда кто-то пишет и не приводит ссылку на то, что он повторяет чьи-то слова, это и означает мнение этого человека.

A>Не имеешь, или в этом случае уточняй, что не все этого хотят, и что не все хотят себе недоделку, которую за тобой ещё и доделать кому-то придётся ...

Моя недоделка функционирует, и альтернативы ей пока нет. Это не значит, что я не хочу обсуждать, как её доделать. Наоборот. Потому и постил.

A>Зачем? Тебе совета мало показалось? Я обратил внимание, что ты некорректно выражаешься от имени других и всё. Конкретно мне не понравилось, что ты в общем то и от моего имени повесил свою фразу. Я не прав?

Ники у нас на одну букву начинаются, может путаешь? Ещё раз подчеркну, что во всех моих постах, за исключением тех, где это прямо указано, я выражаю своё мнение, основанное на моём видении мира сего. И не вижу смысла это каждый раз подчёркивать.

A>...Есть стандарт написания кода в проекте, вот его и придерживайся.

Где прочитать про стандарт, которого придерживаться?

A>То что недоделана вещь, тебе сказал AVK. Думаю стоит прислушаться и доделать.

А я согласен с ним. Более того, хочу обсудить и доделать. Всё ещё.

Здравствуйте, AndrewVK, Вы писали:

AVK>Идеальный нет, но тот что у тебя придется дорабатывать напильником.

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

AVK>А что этот вариант дает? Показывает одну из возможностей сделать это? Ну так статьи на мсдн вполне достаточно.

Не достаточно. Изложен подход начинающего и изготовлен работающий прототип, который выполняет нужные функции

AVK>Вот о том и речь. Тебе доведением до ума заниматься не хочется...

Неправда ваша, хочется. Потому и пишу. Что не нравится, конкретнее?

Согласен ли с " индикатор может показывать только "наличие движения в канале" "?

Надо ли оставить красивый секторный индикатор, который доработать до " который после заполнения голубенькими секторами пойдёт на второй круг с иным (более голубым) цветом, а затем на третий круг с голубым и так далее "?

Устраивает ли макет формы "Синхронизация", при которой верхний прямоугольник занят сообщениями в лог о текущей деятельности, внизу него расположен прямоугольник, отражающий накопительные количество принятых/отправленных байт и содержащий кнопки "Прервать/Закрыть" и "Детально", при нажатии на "Детально" открывается дополнительный прямоугольник внизу, обычно содержащий сообщение об исключении?

Или же макет с индикатором секторным так как сейчас на скриншоте, см. мой пост root?

AVK>Я не про события вобще писал, а про то что ты ввел два новых типа. Это неверно.

Как будт верно?

Сейчас есть три категории, на которые завязаны заодно и картинки. Это: информационное сообщение, сообщение об ошибке и некое промежуточное предупреждение. Где место сообщениям о количестве переданнополученной информации?

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

A>> Возможно, их стоило делать одно. Но показать разные картинки на принятые/отправленные байты тогда нельзя.
AVK>И не нужно.

Но это же показывает входящий и исходящий трафик. Картинки человеком воспринимаются быстрее, чем текст, который надо прочитать и понять.

AVK>Значит надо было приделывать парраллельную маркировку событий. То, что ты сделал выглядит криво и абсолютно нелогично.

Как сделать не криво и абсолютно логично?

AVK>При чем тут взгляд? Тип события отвечает критичности этого события. А ты внес абсолютно нелогичное дополнение.

Как измерить критичность сообщения о трафике программы?

AVK>Из чего ты сделал такой вывод?

Из твоих иногда безапеляционных заявлений, из которых я затрудняюсь сделать вывод, как сделать правильно.

A>>Уже сейчас можно заменить сообщения в лог на LogInfo(), индикатор убрать, лабелы оставить, кнопки вернуть на линию с лабелами, развернуть верхний список обратно вправо и заставить его скроллироваться, чтобы было видно последнее сообщение — и будет функционально.

AVK>ИМХО надо добавлять.

Ежу понятно, что это моё предложение раз я его написал и запостил под своим именем вверху, раз.

AVK> То что ты предлагаешь может многим не понравится.

Ежу понятно, что может. Где высказывания других? Еле удержался от желания тыкнуть тебя туда же, чтобы добавлял "По моему, ..."

A>>Люди будут видеть, кому надо — в логе увидят трафик Януса. Чего ты упрямишься-то? Это же очевидно. И люди (пользователи Януса) этого просто жаждют.

AVK>Говори только за себя, ОК?

Хорошо, людям вообще это пофигу, не пофигу мне и ,возможно, тебе. Но я не оставляю надежды подарить людям хороший, функциональный и удобный инструмент в Янусе — индикатор прогресса.

Дисклаймер: здесь и везде, если не указано иное, следует все предложения читать со слов "По моему, ...". Что, в общем-то, не удобно, и нить рассуждений теряется...

Здравствуйте, akasoft, Вы писали:

A>Первым делом я сделал регистрацию переданных/принятых байт в лог. Надежда на то, что я буду заранее знать объём данных с сервера, не оправдалась после опыта. Таким образом индикация прогрессами (показывающими изменения от начала и до конца) стала невозможна. Убирать индикатор я не стал, просто переделал ему метод Next(). И добавил накопительные поля для собствеено переданных/принятых байт.

Возможна. Засунь кусок в JanusSvcEx, сравни полученные и предсказанные длины.

protected override WebResponse GetWebResponse(WebRequest request)
{
    WebResponse resp = base.GetWebResponse (request);
    long length = resp.ContentLength;
    Logger.Instance.LogInfo("Response length is " + length);
    return resp;
}

protected override WebResponse GetWebResponse(WebRequest request, IAsyncResult result)
{
    WebResponse resp = base.GetWebResponse (request, result);
    long length = resp.ContentLength;
    Logger.Instance.LogInfo("Response length is " + length);
    return resp;
}

Вот такой вот грязный хак. С запросом вроде так же можно поступить.

Единственная проблема — передать эту длину SOAP-расширению. Я сильно не углублялся, но что-то не видно возможностей связать SOAP-расширение и JanusSvcEx . Можно через статическую переменную, но это некрасиво. Короче, надо подумать.

Еще надо учесть, что эта длина не обязательно должна быть (я так понимаю, она из http-шного Content-Length берется, а оно необязательное).

Здравствуйте, akasoft, Вы писали:

A>Согласен ли с " индикатор может показывать только "наличие движения в канале" "?

Я не согласен. Смотри один из моих ответов.

Здравствуйте, akasoft, Вы писали:

AVK>>Идеальный нет, но тот что у тебя придется дорабатывать напильником.

A>Ну и замечательно, мой напильник простаивает.

Вот и доведи до рабочего состояния.

AVK>>А что этот вариант дает? Показывает одну из возможностей сделать это? Ну так статьи на мсдн вполне достаточно.

A>Не достаточно. Изложен подход начинающего и изготовлен работающий прототип, который выполняет нужные функции

Зря ты думаешь что это так сложно. Принцип и так известен, а на рабочий твой код не тянет.

AVK>>Вот о том и речь. Тебе доведением до ума заниматься не хочется...

A>Неправда ваша, хочется. Потому и пишу. Что не нравится, конкретнее?

Я тебе по моему конкретно 3 пункта указал. Вот их и исправляй.

A>Согласен ли с " индикатор может показывать только "наличие движения в канале" "?

Не такой. Допиши индикатор чтобы просто показывал вращающийся сектор в количестве 1 штука или вобще убери. Animation контрол заместо индикатора я тебе дам.

A>Устраивает ли макет формы "Синхронизация", при которой верхний прямоугольник занят сообщениями в лог о текущей деятельности, внизу него расположен прямоугольник, отражающий накопительные количество принятых/отправленных байт и содержащий кнопки "Прервать/Закрыть" и "Детально", при нажатии на "Детально" открывается дополнительный прямоугольник внизу, обычно содержащий сообщение об исключении?

Честно говоря пофигу, лишь бы не выглядело по уродски.

AVK>>Я не про события вобще писал, а про то что ты ввел два новых типа. Это неверно.

A>Как будт верно?

Сообщения твои имеют тип Information. Либо откажись от выделения иконками, либо добавь еще один атрибут события, его отображай иконкой, а тип события отображай как нибудь иначе. Например как в reget цветом фона — белый инфо, бледно-желтый — варнинг, бледно-розовый — ошибка.

AVK>>Говори только за себя, ОК?

A>Хорошо, людям вообще это пофигу, не пофигу мне и ,возможно, тебе. Но я не оставляю надежды подарить людям хороший, функциональный и удобный инструмент в Янусе — индикатор прогресса.

Люди твой подарок скорее всего не оценят, зато по поводу кривизны твоего индикатора, как показывает практика, воплей будет предостаточно.

A>Дисклаймер: здесь и везде, если не указано иное, следует все предложения читать со слов "По моему, ...". Что, в общем-то, не удобно, и нить рассуждений теряется...

Известный приемчик. Только не прокатывает. Когда ты делаешь заявления, никакими фактами не подтвержденные и очень спорные все таки добавляй имхо.

Здравствуйте, WFrag, Вы писали:


WF>Возможна. Засунь кусок в JanusSvcEx, сравни полученные и предсказанные длины...

И при этом я получу-таки поле Content-Length до того, как начнут поступать порции xml-части ответа?

Было-бы здорово... Я долго за такой момент боролся — выцепить Content-Length и отталкиваться от него. Даже приблизительный размер позволил бы сделать оценку. Но силёнок-знаний не хватило.

WF>Вот такой вот грязный хак. С запросом вроде так же можно поступить.

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

WF>Единственная проблема — передать эту длину SOAP-расширению.

А зачем? Его задача — читать, пока не перечитать, а затем обработать полученный xml-пакет (распаковать, расшифровать, так оставить) и отдать десерелизатору.

WF>Я сильно не углублялся, но что-то не видно возможностей связать SOAP-расширение и JanusSvcEx . Можно через статическую переменную, но это некрасиво. Короче, надо подумать.

А как же атрибуты-то? Вот

public override object GetInitializer(LogicalMethodInfo methodInfo, SoapExtensionAttribute attribute)

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

public override void ProcessMessage(SoapMessage message)

тип SoapMessage для перехватываемого сообщения можно привести к SoapClientMessage (т.к. Янус есть клиент вебсервиса), а там уже есть свойство Client, которое "Gets an instance of the client proxy class, which derives from SoapHttpClientProtocol". По моему , это то, что надо...

Здравствуйте, akasoft, Вы писали:

A>Здравствуйте, WFrag, Вы писали:


WF>>Возможна. Засунь кусок в JanusSvcEx, сравни полученные и предсказанные длины...

A>И при этом я получу-таки поле Content-Length до того, как начнут поступать порции xml-части ответа?

Да.

A>Было-бы здорово... Я долго за такой момент боролся — выцепить Content-Length и отталкиваться от него. Даже приблизительный размер позволил бы сделать оценку. Но силёнок-знаний не хватило.

Reflector — это сила.

WF>>Единственная проблема — передать эту длину SOAP-расширению.

A>А зачем? Его задача — читать, пока не перечитать, а затем обработать полученный xml-пакет (распаковать, расшифровать, так оставить) и отдать десерелизатору.

Точно, оказывается это и не нужно. Тому же SyncForm-у скормить, а он — синглетон.

Здравствуйте, akasoft, Вы писали:

A>А так, действительно будет "конкурент" RSDN Proxy...

Кстати, а что с ним?

Здравствуйте, akasoft, Вы писали:

A>2 часа не так уж и много...

Это когда языком.

A>Как по твоему, что нужно сделать, чтобы было просто и удобно поддерживать обе платформы? Как бы ты сделал? Вот, маленькая идея появилась, но у меня MSSQL нет и поставить/проверить пока не на чем...

Там основная работа — это переписывание реструкторизатора БД. Дело в том, что на сегодня при изменении структуры БД в новой версии Хоума происходит автоматическая рестуризация базы. Насколько мне известно в его версии как раз это и небыло сделано.

A>С Access такое тоже можно. Правда, менее прозрачно, и защита на уровне ОС.

Это нельзя ни под Эксесом ин под сиквилом просто потому, что информация о нечитанных сообщениях и о текущем пользователе локальна. Два пользователя на одной БД на сегодня будут мешать другдругу.

A>А это уже хороший аргумент.

Офигительный. Не ясно зачем нужен. Ниодной неиспровимой ошибки БД пока небыло. А копирование 300-меговой БД (это у меня... а у меня она одна из самых крупных) занимает несколько секунд и может производиться при открытом хоуме.

A>Прикрутить что-ли автосжатие/бэкап к Янусу...

В Хоуме уже есть фича производить сжатие при закрытии. На 300 метровой БД это выливается в 10 минут.

Здравствуйте, WFrag, Вы писали:

WF>Для поддержки нескольких типов баз SQL-запросы все равно придется дублировать. Поэтому, имхо, лучшее, что можно сделать — это собрать всю работу с базой обратно в одно место и просто писать несколько реализаций.

Плохая идея. Запросы будут отличаться очень незначительно. Я кода переделывал работу с БД специально делал так чтобы они минимально отличались от ANSI SQL 89. Основная разница в использовании IIF() из Эксеса вместо CASE из ANSI SQL 93 (Эксес сабака поддерживает только 89 да и то не полностью).

Как я уже говорил тут рядом — проблема не в запросах. Их на обычном string.Format-е легко оттюнить. Проблема в реструкторизаторе БД.

Здравствуйте, HotDog, Вы писали:

HD>1. Параметры обозначить через "?" а не через "%". MDB принимает оба типа, а вот MSSQL только первый вариант.

Ты что-то путаешь. Наверно не через %, а через @. Так это как раз сиквел-сервер понимает сабаку. Процент же в обоих случаях является знаком подстановке (вилдкартом).

HD>2. Переписать все "inline" значения на параметризованные. Т.е. переписать те места где написано что то типа "SELECT... WHERE ID=" + mID.ToString();

Это вообще бессмысленно. Там где используются даты — да, нужно переписывать. Но таких мест попросту нет, ну, или они минимальны. А int он и в африке инт.

HD>А в остальном SQL диалект аналогичен (майкрософт же)

Не совсем. Основная проблема в использувании условных выражений. Эксэс не совместим с CASE-ом из SQL 93 и неподдерживает простенькую функцию IsNull(...) (кстати нестандартную). Прихотится использовать ривейшую конструкцию IIF(...) которая приводит к дублированию подзапросов. Но все это обходится путем создания простенького макроязыка. Просто будет такие запросты выполнять через некую функцию которая бдет разворачивать наш макрос. Например, "#IsNull(a, b)" в "IsNull(a, b)" для mssql, и в "IIF(a, a, b)" для эксеса.

Здравствуйте, AndrewVK, Вы писали:

AVK>...поскольку дергающийся туда-сюда прогресс-индикатор это нонсенс...

Ну, почему же? Я вот как-то смотрел на навигатора там внизу нечто похожее на прогресс-бар бежит во время загрузки страницы... добегает до 100 процентов и... бежит обратно.

AVK>, новые типы событий в логе ты ввел совершенно необосновано, править автогенереный код прокси бессмысленно, потому что все изменения грохнутся при первом же изменении сервиса и т.д. В общем посмотрел я на твой код и пока отложил его внимательное изучение на потом. От принципиальной возможности путем кучи подкруток и подправок до реальной фичи очень большой путь, но большинство его просто не проходят, потому что ковыряться и править баги и недоделки скушно и неинтересно. Проблема только в том что править и дописывать за вами некому.

Да. Полностью согласен. Вот тут один товаришь прикрутил новый тулбар. Так он постоянно скукоживается в две строки. Но я этого товарища понимаю. Ведь учить дургих действительно интереснее чем править баги и недоделки.

Здравствуйте, akasoft, Вы писали:

A>Мы бы тут долго ещё мусолили вопрос про индикацию процесса — я просто взял и сделал один из вариантов. Не идеальный, но работающий, выполняющий вполне конкретные инструментальные функции, которые есть потребны пользователям Януса.

A>Я не обсуждал, то что сделал, ни с кем, потому что это бы затянулось на долгие дни и "принципиальные" вопросы, типа цвета секторов.

Полностью согласен. Но и с АВК я тоже частично согласен. Если уж взялся за дело, то доводи его до блеска. Пусть не сразу но доводи.

A>Хотя я и в чём-то согласен с отдельными словосочетаниями, всё-же напоминает брюзжание преподователя на студента: "Блин, вот взял и сделал, а я же знал, что и как сделать, но влом было делать, да и коряво всё сделал, не по правильному, не по моему... Хоть больше с лабой никто и не справился, поставлю-ка я ему три с плюсом, а остальным двойки..."

Смешно... но что-то в этом есть.

ЗЫ

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