new_year

Форум

Главнаяtwo_oceans

two_oceans

Форум

Дата создания

Выбрать дату в календареВыбрать дату в календаре

Тема

Сообщение

Упорядочить

Выбрать дату в календареВыбрать дату в календаре

Шаблон МКД-УО. Версия 10
 
[QUOTE]AlexRed пишет:
Может у кого было такое, что делать то?[/QUOTE]Написал простенький макрос сравнения - так он мне показывает, что значение на листе 10 (Жилые помещения) в ячейке A5 (строка загрузилась) отличается от значения в ячейке A6 (в строке ошибка). Чем именно отличается еще посмотрю, но скорее всего Вам всего лишь нужно скопировать значение в первом столбце из загрузившихся строк в ошибочные.

[SIZE=85px][COLOR=greenpt]Отправлено спустя 13 минуты 5 секунды:[/COLOR][/SIZE]
Хм, будете смеяться, но похоже, что обработанные строки неправильны. У них в конце после дом 15 идет пробел, как и в адресе на листе "Информация о МКД". У необработанных строк пробела в конце нет.
Вопросы по формату ЕЛС и ИЖКУ
 
[QUOTE]AlcorVol пишет:
Ув. burmistr, Вы не могли бы объединить три последних темы товарища suineg в одну?[/QUOTE]Полагаю, этого не позволяет стандартный функционал движка форума. Можно исправить прямо в базе данных, но для этого нужно знать, что и где править. В общем случае, нужно "всего лишь" изменить привязку сообщений на одну тему, объединить начальные сообщения в одно, исправить счетчик сообщений автора, потом убрать лишние "опустевшие" темы. Плюс зайти в базу данных на сервере тоже задача нетривиальная - для безопасности внешний доступ обычно отключен или разрешен только с определенных адресов в панели администратора хостинга. Еще можно скопировать текст со всех тем и вставить в одно сообщение, потом удалить лишние темы. Еще вариант - добавить функцию объединения тем в движок. В любом случае, слишком много движений.
[QUOTE]AlcorVol пишет:
Номера ЕЛС присваивает ГИС ЖКХ. Ваша задача - их запомнить.[/QUOTE]Поддерживаю.[QUOTE]AlcorVol пишет:
Ваш вопрос по контрольным разрядам в составе ЕЛС (удалённый администратором) - тоже из той же серии. Не Вы должны их вычислять. Это дело ГИС ЖКХ.[/QUOTE]А вот это более интересно - лишний раз проверить отправляемые данные и "подстелить соломку" не помешает. Алгоритм проверки я не смотрел (скажу сразу), но (судя по вопросу) весьма удивляет, что снова кто-то "гениально" предложил использовать символы кириллицы, похожие по начертанию с латинскими. Это наводит мрачные подозрения, что кто-то будет вбивать латинские. Учитывая возможные проблемы с кодировками, я бы вообще кириллицу использовал как можно реже и тем более не в идентификаторах. Видимо, снова считают среднестатистического пользователя дураком, не способным элементарно переключить язык.
В случае аналогичной системы ГИС ГМП (штрафы ГИБДД, в частности) там можно использовать и латинские и кириллицу, да еще и алгоритм проверки (там определяется не системой, а тем, кто начисляет, то есть ГИБДД) их не отличает! Но, при этом, при написании латиницей и кириллицей считаются разными идентификаторами. Банки это решили запросом данных протокола, из которых формируется идентификатор и переформируют его заново. В некоторых случаях получается правильней чем в квитанции  :lol:Так что, возвращаясь к ГИС ЖКХ, лишний раз проверить, что, скажем, не вбили буквы другого алфавита не помешает.
ГИС ЖКХ: Предложения по информационному обмену
 
[QUOTE]Sergey Cheban пишет:
Так что увы, строгий порядок нас ждёт только на кладбище (квартал такой-то, ряд такой-то, могила такая-то), а пока мы живём, нам придётся бороться с беспорядком. Так этот мир устроен.[/QUOTE]Увы, в реальности и кладбища далеко не везде упорядочены рядами и кварталами.
[QUOTE]Sergey Cheban пишет:
Если Вы считаете, что эта штука действительно нужная, то попробуйте сами её сделать, а потом продать. Ну или хотя бы прикиньте, сколько времени и людей потребуется на разработку, и сколько экземпляров по какой цене можно продать. Если получается не выгодно, то и государству не стоит этим заниматься.[/QUOTE]Да, считаю что нужна. Федеральных ГИС все больше. В принципе, меня одного хватит, только в одиночку это может затянуться надолго. А вот продавать - смысла не вижу, так как это потянет ответственность за дальнейшую поддержку. Максимум - добровольные пожертвования.[QUOTE]Sergey Cheban пишет:
А написание портабельного кода - дело хоть и не невозможное, но всё же не тривиальное, и граблей на этом пути разложено значительно больше, чем хотелось бы. Тот же __stdcall - не стандарт, а расширение языка, gcc его не поймёт.[/QUOTE]Согласен. Однако, наверняка можно использовать средства, которые понимают.
[QUOTE]Sergey Cheban пишет:
паскаля не миновал[/QUOTE]Прошу простить в таком случае.[QUOTE]Sergey Cheban пишет:
Проблемы с std::string и прочими не-сишными типами в том, что двоичная совместимость гарантируется только тогда, когда всё собрано одним и тем же компилятором с одними и теми же настройками. Обычно двоичную совместимость стараются сохранять в пределах мажорной версии компилятора, хотя даже из этого правила бывают исключения. И нет, конкретно в случае std::string у Вас не будет указателя на таблицу виртуальных методов, потому что эти методы не виртуальные.[/QUOTE]Какой ужас, тогда мне вообще не ясно почему Си++ и более поздние версии так популярны. В любом случае, передавать методы как бы не обязательно, важны данные, в том же дельфи есть тип, в котором в начале длина строки (вариации тоже разные, до 8 байт на длину), потом само значение, для гарантии еще #0 в конце. Все это (и функции работы с ним) можно описать в Unit на Паскале или соответственно в заголовочном файле Си.[QUOTE]Sergey Cheban пишет:
__stdcall как раз и оставит нам интерфейс на голом Си. С небезопасными строками, без поддержки исключений (exceptions), с проблемами освобождения переданной памяти, с проблемами использования из языков, отличных от си-подобных.[/QUOTE]Что ж поделать, если с безопасными такая неприятность из-за двоичной несовместимости.[QUOTE]Sergey Cheban пишет:
Паскаль, насколько я понимаю, застрял в девяностых, и поэтому у него с SOAP проблемы. Но в более современных языках всё уже есть. Либо в виде внешних библиотек, либо прямо в составе языка.[/QUOTE]Что застрял, не отрицаю. Однако с SOAP в целом никаких проблем нет, есть стандартные Unit ("диалекты" Паскаля можно адаптировать, так что насобирать их не проблема). Проблемы начинаются, когда SOAP нужно подписать ЭП вообще (из-за не очень верной каконикализации в стандартных Unit (и даже в старых системных com-объектах), не совпадающей с новейшими каноникализаторами С#, использованными в ГИС), и невнятно определенной стандартом ГОСТ ЭП в частности. С отправкой на веб-сервис тоже не все гладко - модули есть, но в них нужно добавить "вкус шифрования ГОСТ". Итого - Unit, добавляющий к SOAP "вкус ГОСТ", как раз бы пригодился. Реализации этого естественно уже есть на Паскале, но, к сожалению, готового решения не нашел, ни бесплатно ни за деньги. На форумах активно обсуждались проблемы написания, но потом авторы написали и замолчали, на попытки связаться не отвечают. Естественно, можно попробовать перенести с других языков - но для этого нужно знать язык источника и тогда собственно проще писать именно на нем. А библиотека - способ не переписывать весь код с другого языка, а только интерфейсы - это проще.
С другой стороны, смены версий форматов запросов SOAP тоже сильно действуют на нервы и вынести функционал SOAP вне "основного кода" своей ИС в "модуль генерации SOAP" было бы логично. Начать с присвоения хранимым в своей ИС данным неких однозначных имен. Дальнейшие шаги по сопоставлению этих имен с тегами в запросах SOAP не потребуют изменения ИС, а простой смены настроек "модуля генерации SOAP". А вот если понадобятся передавать данные, которых нет в ИС - собственную ИС все равно придется дорабатывать: добавлять таблицы/поля для хранения данных, формы ввода и определять новые имена, но это не так сложно, по сравнению с чтением огромной, меняющейся и частично неверной документации к запросам. И снова в этом случае код  "модуля генерации SOAP" менять не придется, а только его настройки. Если посмотреть шире, то "модуль генерации SOAP" будет в общих чертах одинаков практически у всех. Какой смысл тратить человеко-часы на написание его снова и снова разными разработчиками. С моей точки зрения, библиотека DLL как раз такой способ вынести общий, редко обновляемый функционал вне "основного кода" ИС.
Кроме того, если не ограничиваться ГИС ЖКХ, то, например, СМЭВ требует сохранять все запросы и ответы в базе данных (так порой сделаешь неправильный запрос, обнаружишь тестом, что в нем ошибка еще [U]до отправки[/U], а нет - удалять нельзя даже неотправленный запрос, так и висит как памятник глупости), а это в свою очередь пересекается с импортозамещением баз данных. То есть, по-хорошему, нужна вообще платформа включающая формирование SOAP из XML, подписание, отправку и отечественную базу данных (ясно что это уже не бесплатно, но хотелось бы за приемлемые деньги).

[SIZE=85px][COLOR=greenpt]Отправлено спустя 26 минуты 50 секунды:[/COLOR][/SIZE]
[QUOTE]Sergey Cheban пишет:
По-моему, эта функция находится в личном кабинете на самом видном месте и называется "подключить лицевой счёт". Можно указать номер лицевого счёта и адрес, и подключиться к _чужому_ лицевому счёту, если собственник не запретил подключение.[/QUOTE]Спасибо, попробую. Логично, я эту функцию и использовал, но после выбора адреса - выдало, что у меня нет прав. Правда, номер лицевого я не указывал (и мне интересно как я должен был об этом догадаться). С этим тоже проблема - например, у нас счета одной РСО выглядят вроде "01-1089" (особенность местного разработчика ПО, "01-" это номер УО/РСО), но в квитанции банк пишет просто 1089 и реквизиты компании. У другой РСО счет вида "ЧРТ010111111", в квитанции также, но на их сайте, например, нужно вводить без букв, только цифры. Поэтому я и не стал вводить лицевой счет без дополнительной "наводки" - нужно еще догадаться/подобрать, что РСО указало в этом поле.
Средства работы с XLSX-файлами
 
[QUOTE]two_oceans пишет:
закрытый доступ для разработчиков серверов стоит довольно дорого[/QUOTE]Уточню, что если бы продавал услуги, то купил бы. А для "самообразования" и экспериментов 30-50 тысяч за 1 файл как-то многовато.
[QUOTE]AlcorVol пишет:
Умножает тут, кстати, не моя программа, а сама VFP[/QUOTE]Согласен, я имел ввиду, что сама VFP тоже либо по сути программа либо встраивает что-то в твою при компиляции (не работал, так что не знаю детали, но предполагаю так).
[QUOTE]AlcorVol пишет:
с гарантией - если Byte Order Mark в начале влепишь[/QUOTE][QUOTE]Basil пишет:
Far3 умеет работать с файлами в UTF-8.[/QUOTE]Полагаю, замечание о Byte Order Mark в силе и для UTF-8 в Far3? Если да, то это не очень хорошо - как я уже упоминал, составляю веб-странички из нескольких PHP файлов и, если метка есть и попадает в середину страницы, то браузер всякие фокусы выкидывает. В основном, помогает брать начало файла в теги комментарии, но иногда комментарий никак не влепить.
Средства работы с XLSX-файлами
 
[QUOTE]AlcorVol пишет:
Константин, ты не совсем понял.  У меня ширина окна программы - 80 символов, как в ДОСе. (Хотя высота в строках может быть и переменной.) Если задать шрифт поменьше - то и окошко приложения станет поменьше. Я сам прошу тут VFP окошко перерисовать соответствующим шрифтом => соответствующего размера.[/QUOTE]Кхм, а мне кажется наоборот, ты не совсем понимаешь, что шрифт может занимать на мониторе не столько пикселей, сколько было тобой задумано при создании шрифта. Ну смотри. Твой шрифт скажем 10х8 (к примеру, я не смотрел какие там размеры), то есть 8 пикселей в ширину. Предположим что расстояние между символами 1 пиксель, тогда (8+1)*80=720 (для круглого счета опустим, что после последнего промежутка нет). Пусть программа просто умножила, игнорируя масштабирование, известный размер шрифта на 80 и окно занимает эти 720 пикселей в ширину. Но в Винде, допустим, включено масштабирование 150% и твой шрифт, выведенный Виндой, по факту занимает на мониторе 12 пикселей в ширину, а промежуток стал полтора пикселя (дробное значение сглаживается видеоадаптером, так что края могут ужасно выглядеть). То есть войдет в окно 720/(12+1,5)=53,(3) символа. А если запросить у Винды сколько займет в ширину текст длиной 80 символов с таким-то шрифтом (если не моноширинный, то еще и будет учтена ширина каждого символа в конкретном тексте), она вернет правильное значение (12+1,5)*80=1080 пикселей. От изменения базового размера шрифта не изменится соотношение между реальным размером и базовым размером и входить будут все те же 53 символа. Вот о чем я говорю, что надо проверить запрашивает VFP размер 80 символов у Винды или сам умножает. Конечно, есть еще вариант, что запрашивает размер одного символа шрифта, а потом умножает - в этом случае будет ошибка с промежутками на 80*0,5=40 пикселей и не войдет "всего" 2-3 символа.[QUOTE]AlcorVol пишет:
Клавиша Alt-F7[/QUOTE]Огромное спасибо. Хотя про кодировки остается небольшое сомнение (UTF-8, например, в которой веб-страницы или поиск в Word), но если я ищу в исходном тексте программ, то они почти полностью на английском и все отлично.[QUOTE]AlcorVol пишет:
[QUOTE]Дамир пишет:
дыкть, просто шаблоны распоковать и писать 'как там'... не?[/QUOTE]Дыкть, не так всё просто![/QUOTE]Точно! В частности, в этой реализации на PHP вообще пишется только содержимое ячеек, причем перезаписывается весь распакованный файл в котором значения, ничего из бывшего "до этого" не остается, то есть "как там" нужно будет как минимум либо добавить прямо в своем коде (а если шаблон изменится, то изменить, так что не пойдет!) либо считывать файлы в шаблон и совмещать с новыми значениями.
Кроме того, на самом деле, если мы уже имеем веб-интерфейс, получающий данные для размещения из базы данных УО, то нам и XLSX не очень нужен. Во-первых, (не предусмотрено, но реализуемо) можно хитрым скриптом авторизоваться в ЛК и напрямую заполнить значения форм ручного ввода, сохранить, повторить. Работать конечно будет не очень хорошо, но есть и плюсы - при обычном открытии отображается весь ЛК, но скрипт может вырезать из него только форму отправки и она будет работать намного быстрее. Конечно, все равно придется ставить задержку, чтобы было похоже на человека и не порезало защитой - например, отправка новой формы через 5 секунд. Плюс контроль не вышло ли сообщения что технические работы или страница не найдена. Плюс контроль чтобы не забить данные дважды, но и ничего не пропустить. Во-вторых, (предусмотрено разработчиками) до SOAP рукой подать. Правда, с ЭП там будет "вешалка".
С другой стороны, прелесть PHP в том, что веб-интерфейс на самом деле не нужен - можно запустить PHP файл в консоли, а "параметры запроса" страницы передать в командной строке. Вот тут запись в XLSX бы пригодилась. И раз уж возможны целых 3 подхода из PHP, задумался, не перейти ли на PHP для этого проекта. А для ЭП можно написать расширение PHP (на самом деле, оно уже есть от КриптоПро, но не в открытом доступе, а закрытый доступ для разработчиков серверов стоит довольно дорого).
ГИС ЖКХ: Предложения по информационному обмену
 
[QUOTE]Programmer пишет:
shortstring[/QUOTE]Конечно они должны иметь одинаковый тип, точнее одинаково описанный. Хм, никогда не было проблем с этим. Ни со своими DLL, ни с системными. Сейчас перепроверю какой тип использовался, насколько помню pchar и все дела. Точнее, совместимый с ним собственный тип pathstr=array[1..260] of char и запись #0 в конце, от которого брался указатель. Что со мной не так? :D Замечу, что это не был объект и соответственно методы работы с ним реализовались независимо на каждой стороне, операторы не переопределялись. Конечно, так работать неудобно.
Другой вопрос, что типы-объекты нужно правильно (ре)конструировать и правильно передавать - просто положиться на среду программирования не всегда получится. Паскаль обычно использует как ссылку на себя внутри объекта (и она передается в метод в регистре процессора, а не через стек) ссылку на [B][U]данные[/U][/B] объекта (а не на начало памяти объекта ) - с одной стороны от нее (адрес в большую сторону, насколько помню) данные объекта, с другой стороны (в меньшую сторону соответственно) - адреса функций и процедур (методы) объекта. Если описание объекта не совпадает (методы и данные не совпадут после передачи) либо если передать ссылку на данные вместо объекта целиком и наоборот (так при передаче адресов методов может не оказаться в объекте на стороне-получателе), то ничего работать не будет.
Поэтому (если не заморачиваться) обычно и нужно избегать передавать объекты. Но, если я реконструирую объект после получения (исправлю адреса методов и поставлю указатель на нужное место), то проблем быть не должно. В этом смысле общее адресное пространство между программой и библиотекой скорее плюс, ссылки на методы должны быть все еще действительными после передачи. Однако, тут важно помнить, что адрес самой DLL может измениться при загрузке библиотеки, и если реализация объекта находится в DLL, то изменится и адрес реализации метода. Поэтому адрес метода нужно не прописывать конкретной цифрой, а импортировать либо находить системной функцией (GetProcAddress) после загрузки библиотеки.[QUOTE]Programmer пишет:
[QUOTE]two_oceans пишет:
[99427]непонятно, с чего начинать[/QUOTE]Из-за этого очень сильные тормоза![/QUOTE]Ну, в смысле, понятно, что можно получить описания схем и их проанализировать на предмет новых полей, изменений формата, удалений полей. Но далее нужно как-то связать с получаемыми из базы данных УО/ТСЖ данными. Пока придумался такой вариант - после обновления документация анализируется и структура тегов вроде [quote:2glc8wxb]... <soapenv:Body>
<pay:importNotificationsOfOrderExecutionRequest base:version="10.0.1.1">
<pay:NotificationOfOrderExecutionType>

<pay1:RecipientInfo>
<org:INN>3436018361</org:INN>...[/quote:2glc8wxb]преобразуется в имя переменной: в начале и конце строки ставится $, имена тегов (можно без пространств имен, но тогда еще отдельно нужно имена пространств передавать и сопоставлять плюс проверять ссылки на них) соединяются точками согласно иерархии, получится строка вроде$soapenv:Body.pay:importNotificationsOfOrderExecutionRequest.pay:NotificationOfOrderExecutionType.pay1:RecipientInfo.org:INN$ (с пространствами) либо $Body.importNotificationsOfOrderExecutionRequest.NotificationOfOrderExecutionType.RecipientInfo.INN$ (без пространств), формируется и где-то сохраняется шаблон в котором вместо значения подставлена такая строка (и так по всем значениям). Можно конечно как-то сокращать имена до $RecipientInfo.INN$ например, а то в shortstring не впишемся, но тогда нужно сопоставлять сокращенные и краткие имена. Зато попутно можно сопоставлять новое положение переменной в иерархии старому краткому имени и это может делать "опытный пользователь", не обязательно программист.
По запросу от библиотеки программа может получить список массив имен нужных переменных (без $), массив их обязательности и версию для конкретного шаблона SOAP запроса.
При формировании из программы передаются два массива строк для формирования отчета - один с именами переменных (без $), другой со соответствующими значениями переменных (значения уже заранее переведены в строку). Функция проверяет, что все переменные заполнены либо остались незаполнены необязательные (если не хватает выдает ошибку и, допустим, массив нехватающих переменных и их обязательность), убирает пустые необязательные и формирует готовый для отправки SOAP запрос, соответствующий новому шаблону.
Результат программа проверяет, что там нет "Продаю имущество имярек за 1 рубль". Можно, например, выводить пользователю для визуальной оценки (если XML плохо смотреть, то можно в библиотеку еще формирование версии для печати заложить на основе переданного XML и данных о стилях полученных из описания новой версии запроса. Чтобы не привязываться к платформе можно записывать html для печати во временную папку и открывать ассоциированным браузером. Либо выводить в самой программе псевдографикой моноширинным шрифтом как у AlcorVol) и ждать нажатия кнопки "Подписать и отправить".
После этого программа передает запрос в другую библиотеку для подписания/отправки вместе с адресом, портом, сертификатом. Как-то так, но это совсем "просто" получается.

[SIZE=85px][COLOR=greenpt]Отправлено спустя 49 минуты 52 секунды:[/COLOR][/SIZE]
Еще подумалось, что можно в библиотеке подписания просто запретить слова из юридических формул вроде "Продаю" "Дарю" "Завещаю" и возвращать ошибку, если текст их содержит.
ГИС ЖКХ: Предложения по информационному обмену
 
[QUOTE]Sergey Cheban пишет:
Не вижу проблемы. Чтобы подключить лицевой счёт к личному кабинету, не обязательно быть собственником. Достаточно знать адрес и номер лицевого счёта (который, очевидно, должен фигурировать в бумажных квитанциях).[/QUOTE]Что-то я такой опции не увидел. И никаких "наводок" на это тоже. Поищу еще, если получится - премного благодарен.
[QUOTE]Sergey Cheban пишет:
Вообще-то если по уму, то следовало бы требовать подпись и от файлов, передаваемых через ЛК.[/QUOTE]Это да. но раз полагаются на ПЭП Госуслуг, нам проще.
[QUOTE]Sergey Cheban пишет:
Реализации SOAP предлагает не государство, а разработчики[/QUOTE]Согласен, но государство покупает реализации SOAP для центральных узлов СМЭВ - ничего не мешает включить в ТЗ пункт про библиотеку для свободного распространения. Бог с реализацией, но на данный момент каждая ГИС дополняет формат SOAP как в голову придет разработчикам ГИС. Минкомсвязь могло бы утвердить правила, уточняющие как именно дополнять стандарт - в какое место файла располагать ЭП, как стандартно указывать отправителя/получателя и тд. В конце концов, Little Endian или Big Endian использовать в кодировке ЭП. Это явно задача государства, а не разработчиков, которые реализуют только один вариант, но при этом никто не может внятно объяснить, почему нельзя по другому- в ГОСТ это не указано. Тем не менее, другой вариант возвращается с ошибкой - "Неверная ЭП".
[QUOTE]Sergey Cheban пишет:
С ними - ровно те же самые проблемы, что и с виндовыми dll. И по тем же техническим причинам.[/QUOTE]Конечно, но это другая платформа, то есть привязка к Windows - мнимая. Тот же код программы, который напишете на Си будет скомпилирован и упакован в разный формат исполняемых файлов для разных операционных систем.
[QUOTE]Sergey Cheban пишет:
Деньги давать не пробовали?[/QUOTE]Что это изменит? Качество вряд ли будет выше пропорционально сумме. Другой вопрос - кому? Реализация SOAP в ГИС довольно неполная и кривоватая, нет никакой гарантии, что другая неполная же реализация других разработчиков совпадет "по кривизне" и будет работать. В магазине Вам тоже могут предложить Столичный хлеб, когда вы пришли за Бородинским. Даже если с одной ГИС будет, хотелось бы универсальную библиотеку для всех федеральных ГИС. А если тем же, кто разрабатывал ГИС, то их компании и так уже заплатило государство (а государство это взяло из налогов и штрафов, то есть с нас с Вами в том числе) и совершенно немалые суммы. Честно, меня просто жаба задавит [B][U]добавлять[/U][/B] к тем суммам.[QUOTE]Sergey Cheban пишет:
Разные языки программирования - это причина существования в компиляторах от MS ключевых слов __stdcall и __cdecl.[/QUOTE]Знаю. Я в это когда-то вникал и смогу вызвать функцию, хотя возможно это займет время, чтобы разобрать код на Си и подобрать аналогичное описание объекта на Паскале. Либо подключить другую библиотеку того же языка, реализующую этот объект - если не вникать как объект устроен, а просто скормить, что передали и получить, что нужно либо наоборот. Как правило ключевые слова меняют порядок аргументов, так что для функции с одним аргументом мало что изменится, пример неудачен.
(я таки на Си не пишу, но немного разбираю, char * - указатель на буфер сразу, std::string &d вроде бы указатель на объект из которого еще надо получить указатель на буфер через c_str и длину через length/size, в этом смысле достаточно каким-то образом реализовать или подключить c_str и size. Скорее даже не так - объекты обычно хранят указатели на реализованные методы объекта, то есть достаточно найти в объекте нужный указатель на уже реализованную функцию c_str и узнать как ей передать объект). В общем, я не так хорошо знаю Си, а Вы похоже вообще не знаете Паскаль, примеры тут бессмысленно обсуждать.
Для информации - в Паскале таких ключевых слов тоже с десяток, включая вышеназванные - это раз. Если ни одно не подойдет, то никто не отменял возможность сделать "оберточную функцию" и вставить в код на Паскале операторную скобку asm .. end  и написать внутри код ассемблера для передачи параметров и вызова импортируемой функции - это два. Конечно, при этом вся типизация коту под хвост и возможны ошибки. Но, надеюсь Вы не считаете, что разные языки для передачи параметров компилируют какой-то иной машинный код, несовместимый с ассемблером под ту же архитектуру процессора? Можно еще проще, просто используем stdcall - большинство языков умеет работать с системными библиотеками. Итого: остается просто описать заголовки (ну или оберточные функции) на нужном языке, а проблема не стоит выеденного яйца - решаем один раз, потом миллионы раз вызываем функцию.
[QUOTE]Sergey Cheban пишет:
Да и у MS регулярно находят проблемы.[/QUOTE]Да и большая часть из них именно переполнение буфера, то есть по сути именно memory corruption. Это именно болезнь языка Си и прямого использования char * - даже хотя есть вариант функций с указанием размера, многие даже в Майкрософт на это плюют и используют функции без ограничения размера либо неправильно вычисляют ограничение. В Паскале все жестче - например, обычный string (shortstring в моей IDE) ограничен 255 байтами и (используя стандартные функции, без обращения к символам по номеру и махинаций с указателями) 256-ой записать невозможно в принципе - при любой записи берется минимум из ограничения и ожидаемого размера данных. Конечно, 255 байт откровенно сказать мало, но тут ничего не мешает найти исходник встроенного типа по образцу сделать собственный тип скажем на 10 мегабайт и тоже жестко вшить в него ограничение.[QUOTE]Sergey Cheban пишет:
Пока не решены проблемы с интерфейсами, не вижу смысла это обсуждать.[/QUOTE]Учитывая, выше про stdcall, не вижу проблем. Интерфейс всегда можно доработать, если Вам удобнее получать строчку в std::string чем в голом char * то это предмет переговоров о включении дополнительной "оберточной" функции. Либо мне тоже std::string понравится и я портирую объект на Паскаль. Но тут как раз может вылезти что объект не такой уж и std (стандартный), а отличается в разных Си.[QUOTE]Sergey Cheban пишет:
Технически - такие же. Юридически - нет: если нет DLL, то техподдержка ГИС ЖКХ избавляется от разговоров про эту DLL.[/QUOTE]я и не говорил, что это именно техподдержка ГИС ЖКХ будет по DLL по SOAP работу вести, так как федеральных ГИС много, и желательно общую библиотеку. Есть ситуационный центр электронного правительства. Как вариант, сама компания-разработчик библиотеки. А вот конкретно по библиотеке отчетов для ГИС ЖКХ, там конечно техподдержка этой ГИС и тут все понятно (в смысле наоборот непонятно, с чего начинать).
Сторонние организации предлагающие свои услуги по выгрузке данных в ГИС ЖКХ
 
[QUOTE]Александр7272 пишет:
[QUOTE]alik пишет:
компания потеряла все данные за 5 лет и лишилась 30000 руб.[/QUOTE]
Решением для данного вопроса является - регулярное копирование базы, с переносом копии на внешний носитель, можно в тоже облако. В итоге потеря будет не за ... лет, а за период до последнего копирования.[/QUOTE]Все правильно, однако, например у нас где-то 16 баз 1с (4 организации, бухгалтерия и зарплата на каждую плюс еще предыдущие варианты редакций платформы 1с), архивация 15 раз в неделю и объем получается весьма приличный - никаких внешних носителей не напасешься каждую копию сохранять. Частично сохраняем конечно, но большинство копий удаляется через месяц либо при смене версии платформы. С другой стороны, это и плюс - можно восстановлением данных откопать удаленную копию, которую вирус просто не увидит. Ну и можно начать с того, чтобы почта приходила (и вложения открывались там, печатались оттуда) на виртуальный компьютер (xp mode например), с которого нет доступа к базе 1с и файлам физического компьютера, зато есть нормальный антивирус. Еще есть вариант с AppLocker/политиками - запретить выполнять скрипты вообще или разрешить только из определенной папки, в которую доступ "только чтение". Про очевидные меры вроде убедиться что база данных и удаленный рабочий стол и веб-интерфейс 1с не слушает на внешнем айпи и пароли поставить сложнее чем "123456" не стану расписывать.
Средства работы с XLSX-файлами
 
[QUOTE]AlcorVol пишет:
шрифт поменьше станет. А вместе с ним - и окошко.[/QUOTE]Ага, но снова не факт что все войдет, так как размер окна тоже пересчитается. Впрочем, я полагаю, что VFP все же достаточно умен, чтобы спросить ширину текста с учетом всех масштабирований у системы и тогда никаких проблем. Однако протестировать лишний раз не помешает.
[QUOTE]AlcorVol пишет:
Если просто файлы/папки/текст - то лучше в FAR'е искать.[/QUOTE]Да, походу Far это наше всё. Обычно я там только шестнадцатеричные коды смотрю, когда форматы файлов подбираю, но видимо надо снова вспоминать и использовать по полной. Тогда, 1) какой смысл тратить процент системных ресурсов на службу индексирования и службу отслеживания файлов; 2) как искать в Far и в частности по тексту файлов я пока не разбирался. В одном файле знаю, а допустим по тексту файлов с определенным расширением на всем диске, включая поддиректории - нет.
[QUOTE]AlcorVol пишет:
C него же на Hyper-V загружаться?[/QUOTE]Если нужда припадет, то можно и с другого гипервизора виртуальных машин. Родные - VirtualBox и Hyper-V. Там я перечислял функции семерки Про, но практически уверен, они есть и в десятке. Вот, нашел - Hyper-V в 8 и 10 по умолчанию выключен, его нужно включить в списке компонентов ОС, убедится что он не затенен серым и перезагрузить компьютер. Нашел [URL=http://www.download3k.com/articles/How-to-add-an-XP-Mode-Virtual-Machine-to-Windows-10-or-8-using-Hyper-V-00770]вот здесь[/URL], там еще есть всякие тонкости (статья на английском). Так как VHD уже есть, то можно начать с пункта "4. Activate Hyper-V on your Windows 10".[QUOTE]serg_p пишет:
вот нашёл на просторах[/QUOTE]Спасибо, глянул беглым взглядом, это реализация записи на PHP, без чтения, сильно упрощенная и не соответствует шаблонам. В остальном, прекрасное решение на случай, когда нужно записать в XLSX огромные объемы данных, выбранных из базы данных по запросу из веб-формы и не нужно беспокоиться о форматах ячеек. В конце концов, можно еще чем-то обработать результат, чтобы соответствовал шаблону. :D
Средства работы с XLSX-файлами
 
[QUOTE]AlcorVol пишет:
VFP использует этот шрифт, отрисовывая окна[/QUOTE]Ага, то есть к WinApi обращается сам VFP. Удобно.
[QUOTE]AlcorVol пишет:
Этот размер вычисляет VFP[/QUOTE]А вот тут могут быть сюрпризы, если и правда вычисляет сам умножением, а не спрашивает у системы. Например, может оказаться, что на мониторе 1600x900 со включенным масштабированием на 150% входит скажем символов 60 вместо 80. С программами "больших корпораций" такого не встречал, а вот "независимые" разработчики вроде меня и тебя вполне могут попасть под такой глюк - в качестве примера программка, которой бухгалтерия набирает данные по зарплате для сбербанка. Внезапно на одном из компьютеров после обновления Windows XP на Windows 7, программка оказалась с исковерканным интерфейсом, при этом на соседнем компьютере с Windows 7 нормально отображается. Для меня такое актуально, потому что начальники отделов и их заместители почти хит-парад устраивают у кого монитор побольше, а потом начинают ныть когда он показывает или слишком мелко или размазано или мерцает на "родном" разрешении (вот это меня "восхитило" - один из мониторов на "родном" поддерживает только 60Гц и видимо мерцает, на разрешениях поменьше 90 Гц и мерцания практически не видно.
[QUOTE]AlcorVol пишет:
 Не очень-то эти стрелки и нужны.[/QUOTE]Конечно, да и сама подсказка тоже скорее дань "ретро", сейчас подсказки в строке состояния и прямо под указателем мыши всплывают. Кстати, а мышь поддерживается?
[QUOTE]AlcorVol пишет:
Обновился до 10-ки в последний день бесплатного обновления, как это и принято на Руси.[/QUOTE]Молодец, успел. В последний день там наверно сервера работали на износ.[QUOTE]AlcorVol пишет:
Но рабочий стол вернули ещё в 8-ке.[/QUOTE]Ага, но главное меню вернули не на все версии и вызвать поиск у меня получается через раз - приходится долго крутиться у правого края экрана.[QUOTE]AlcorVol пишет:
Больших неприятностей при переходе c 7-ки Pro на 10-ку Pro пока не заметил.[/QUOTE]Как по мне там одна большая неприятность :) Если по деталям, я конечно себе не ставил, а на чужих компах глубоко в настройки не лазил, но мне совершенно не нравится как выглядит список программ в главном меню (при этом само меню смотрится замечательно) - ну зачем, вместо удобных подменю все вывалили в алфавитном порядке в меню, да еще и вставили разделители по буквам. В подменю можно было все компактно сгруппировать и прокручивать не приходилось, теперь очень напряжно листать меню с тачпадов, да и с мышью ненамного лучше. На прошлых версиях русские названия менялись с завидным постоянством (не знаю, может на английском названия одни и те же, а чудили переводчики), поэтому я никогда не учил наизусть названия программ, ориентировался на название подменю и смысл ярлыка. Теперь же приходится мучительно вспоминать как же эти (редиски) обозвали ту или иную программу, поиск конечно помогает, но не всегда, потому что ищет тоже по названию. В итоге времени на диагностику/настройку уходит больше, потому что черт его знает куда засунули и как переназвали.[QUOTE]AlcorVol пишет:
 Юзера всё больше за дебила считают.[/QUOTE]Ох, про это я могу говорить очень долго. Вообще лично мне самым комфортным был интерфейс Windows 2000 - стабильно, без "украшательств" и даже [B][U]возможности[/U][/B] их сделать. Теперь вот и к семерке на работе притерпелся, а дома все еще икспи и виртуальная машина с сервером 2000 (держу на случай совместной работы над каким-то проектом - хоть и серверная ос, но оперативки требует меньше чем икспи). На Windows Xp добавили возможность и сразу в это окунулись - понятно надо было ребятам показать что не зря зарплату получали - иначе на XP бы никто не пошел. Одновременно программы поставили перед выбором - поддерживать 2000 без украшательств или XP с украшательствами. Если бы возможность украшать добавили на 2000 и выпускали обновления безопасности - программы бы до сих пор его поддерживали и на следующие версии никто не пошел. Я не отрицаю внутренних преимуществ архитектуры Windows 7 (более стабильный загрузчик, но он и XP/2000 прекрасно загружает; NTFS эффективнее работает с большими дисками - это улучшение[B][U] драйвера[/U][/B] NTFS - при желании могли включить в XP или 2000; поддержка образов - тоже можно, приложив руки, запихать в образ икспи, наверное и 2000 тоже; зато практически убили интерфейс поиска - теперь ищется всякий хлам из папки Windows, не ищется по содержимому например исходников программ или документов Word, если задать ".ini", то точку проигнорирует и найдет кучу файлов с ini в середине; если перейти из найденного в папку, содержащую объект, а потом перейти на уровень выше - вернется к списку найденного, а не к родительской папке; в профиле пользователя понаставили хардссылок - задумка хорошая, но сам проводник по ним, ****, не переходит! они там с ума посходили?), 8 (поиск вроде подправили - но запихнули изощренно; сделали расположение файлов для быстрой загрузки, отображение часов на экране блокировки - непонятно, что мешало это сделать раньше; поддержка на уровне BIOS - на самом деле семерка тоже прекрасно грузится если поставить вместо восьмерки потом вернуть SecureBoot, но зависит от прошивки BIOS и потому работает не везде) или 10 (обязательная подпись драйверов и неотключаемые обновления - задумано вроде неплохо, но по факту больше проблем), но если посмотреть на список возможностей максимальной редакции (да хотя бы и профессиональной), то сомневаюсь что 90% пользователей вообще знают, что эти названия означают, а из тех кто знает половине они вообще не нужны - единственные полезные функции - поддержка домена и редактор политик, эмулятор икспи, сервер RDP, в максимальной еще AppLocker (правда я его все никак не настрою). Остальное: BranchCache, BitLocker, многоязычный пользовательский интерфейс, поддержка нескольких физических процессоров, подсистема запуска Unix приложений и так далее не используются, зато за них берут деньги. А значит и от того, что их обновляют и улучшают простому пользователю ни тепло ни холодно. Все что нужно, можно было включить еще в windows 2000. Сервера правда все равно пришлось бы обновлять, там действительно есть кардинальные улучшения. Но корпоративный сегмент и сервера от обычного пользователя очень далеки.[QUOTE]two_oceans пишет:
то плитками замостят[/QUOTE]Не то чтобы мне не нравились плитки сами по себе, но это мне сильно напоминает как раньше продвигали Active Desktop во времена windows 98 и Windows 2000 - типа можно скрыть ярлыки, зайти прямо рабочим столом на страничку сайта (то есть смотреть курсы валют, погоду и тп прямо на рабочем столе), а еще только на нем можно было поставить картинки в JPG. Но что-то не припомню случаев, когда кто-то действительно скрывал значки ради просмотра погоды. Даже JPG простые пользователи сохраняли в BMP и прекрасно ставили картинку, игнорируя "замечательный" Active Desktop. На XP стали поддерживаться JPG в обычном режиме и про него перестали вспоминать вообще. На 7 ввели поддержку виджетов и на них откликнулось гораздо больше пользователей - по сути почти у всех одно и тоже, что предлагали на Active Desktop: часы, погода, валюты, но без скрытия значков. Минус - виджеты потребляют много ресурсов и частенько слетают. В 8-10 все это переехало на плитки и наверняка потребляет немало ресурсов. И не отключишь насовсем, так как это теперь основной интерфейс. Прям передергивает когда вижу на плитках содержимое каких-нибудь новостных сайтов, Office 365, магазин Майкрософт или вход через единую учетную запись Майкрософт. И все разного размера плюс перемещивается при удалении плиток.[QUOTE]AlcorVol пишет:
Но, действительно, слегка бесит, что по ночам комп может проснуться без спросу для обновления.[/QUOTE]На сколько я знаком с 10, должно быть минимум два способа с эти бороться - 1) отложить обновления (при этом там настораживающая приписка, что отложить можно максимум на год - потом видимо каааак постааавит) и запускать обновление вручную (варианта совсем отключить в 10 не показывается, может быть сработает, если в реестре поковырять способом для предыдущих ос); 2) настроить другое время для автообновления - но это тоже мало приятного, включаешь например утром, с настроем поработать, а комп пишет - подождите, ставятся обновления. Сразу первая мысль - отключить обновления вообще. И хорошо, если они нормально установятся, а ведь много случаев когда на семерке вылетал синий экран или отказывала подсистема Wow64. В общем, тема не о том, надо завязывывать с оффтопиком.
Средства работы с XLSX-файлами
 
[QUOTE]AlcorVol пишет:
ДОС-овское приложение - это не обязательно чёрно-белый экран консольного вида.[/QUOTE]Это я понимаю, IDE Free Pascal практически так же выглядит, но там консольное приложение. И еще двойная рамка псевдографикой по краю окна. Просто не ожидал, что в Windows цвета тоже перенесешь. Как-то я никогда не задавался вопросом, но без обращения к WinApi (создание кисти определенного цвета либо кисти из системной цветовой схемы, применение ее к фону/шрифту и тп) не представляю как задать цвета. [QUOTE]AlcorVol пишет:
 Какие проблемы - с растровыми-то шрифтами?[/QUOTE]Значит, не тот случай. Тут Windows шрифт использует и рисует? Мои сомнения больше относятся к случаю, когда программа сама шрифт по пикселям рисует. В одном из старых журналов видел программу как это сделать - и в Досе все отлично, так как можно напрямую обращаться к видеопамяти и "зажигать" нужные пикселы. А в Win подозреваю будут жуткие тормоза либо придется с DirectX возиться.[QUOTE]AlcorVol пишет:
1280х1024  в Win 10[/QUOTE]Замечательно, полагаю проблем нет, если шрифт рисует Windows и ширина(высота) окна тоже определяется системной функцией (в смысле, сколько данные 80 символов займут пикселей на экране).[QUOTE]AlcorVol пишет:
Ну, и вот - картинки.[/QUOTE]"Выберите действие клавишами" - кажется, клавиши в шрифте не прорисовалось.[QUOTE]AlcorVol пишет:
Думаю, что такое ретро скоро снова на пике моды будет.[/QUOTE]Хорошо бы, но пока все какие-то "инновации" и "украшательства"- то плитками замостят, рабочий стол уберут, то автообновят на следующую версию ночью. Интерфейс все больше ориентирован на детей - крупные и яркие значки, автонастройка практически всего. Автонастройка это конечно хорошо, но кое-что я бы даже и не стал настраивать потому как функции вообще мне не нужны и, отключив,сэкономил бы немного ресурсов. Про графику игр вообще диву даюсь - системные требования растут катастрофически. Теперь уже каждая игра считает должным тащить минимум 5-10 Гб текстур. Раньше драйвер весил 200 Кб, теперь чтобы поставить некоторые драйвера нужно скачать еще 300 Мб - всяческие фреймворки и тому подобное. Фреймворки задумывались как средство уменьшения размера программы, но сейчас это перевернулось с ног на голову. Так что не знаю, не знаю, доживем ли. Может это ретро будет в моде при наших внуках, когда грянет какой-нибудь апокалипсис и всем временно станет не до "украшательств".
Средства работы с XLSX-файлами
 
[QUOTE]AlcorVol пишет:
Win-1251 - не русская, а кириллическая кодировка. Учитывает одновременно русский, украинский, белорусский, болгарский, сербский и македонский алфавиты.[/QUOTE]Примерно так и предполагал: для расширенной латиницы наверно 5 разных кодовых страниц сделали, а для кириллицы зажались и сделали одну. Больше всего свободных мест в греческой, хотя казалось бы символы с древних времен и похожа на все понемногу.[QUOTE]AlcorVol пишет:
И решение такое я нашёл.[/QUOTE]Спасибо, порадовал! Изящное решение, но с трудом представляю внешний вид. То есть в программе виндовское окно с серым(белым) фоном, а в нем еще текстом нарисована рамка и прочие элементы управления - поля ввода, списки, а сам текст моноширинным шрифтом? Это конечно вариант, но как-то странно должно смотреться среди оформления Windows :) В первую очередь вопрос по быстродействию отрисовки. Во вторую, как оно выглядит на Win 7 с новейшими мониторами и включенным масштабированием. Не так давно видел программу, которая не масштабируется, но говорит Windows 8 что все ОК, перемасштабировать не надо. В итоге размер окна на родном разрешении монитора примерно с пластиковую карту и приходится ставить 1024x768, чтобы разглядеть что-то кроме меню и заголовка (их Windows увеличивает).
У меня такой задачи не стояло - рисование псевдографическими символами прошло стороной. Я бы наверно сделал по-другому, так как у меня другой язык и другая IDE - унифицировал параметры функции, выводящей элемент управления (скажем, поле ввода) шрифтом для DOS (на Паскале есть стандартный Unit) и стандартным элементом управления в Windows (по образцу досовского Unit). Далее подставил разные циферки при формировании окон (на Паскале есть управляющие комментарии для компилятора - то есть сама программа вообще может не проверять в какой среде работает, можно из одного текста сделать несколько версий в зависимости, какие условия передать при сборке, и распространять разные версии для разных сред). Конечно "малой кровью" не назовешь (кроме внешнего вида, стандартные элементы Windows по другой логике работают), но и выглядеть будет по-разному из одного исходника.
[QUOTE]AlcorVol пишет:
Во-вторых, собственноручно разработал семейство растровых шрифтов разных размеров для правильного отображения символов этой кодировки на экране.[/QUOTE]Вот это мне очень интересно. Очень давно есть проблема с отображением кириллицы на синем экране смерти Windows XP. Конечно обычно там стандартный текст и я его уже практически выучил и ориентируюсь на код ошибки, но у некоторых ошибок есть отличия в тексте. Как я понимаю это как раз должно решаться заменой файла шрифтов bootfont.bin Однако нормальной версии вроде бы не нашел и с чего начать ковырять формат тоже непонятно. С Win 7 проблема решается по-другому - в загрузчике указать RU-ru.
Средства работы с XLSX-файлами
 
[QUOTE]AlcorVol пишет:
Хотя и Википедия тут подошла бы. Достаточно часто обновляется.[/QUOTE]Ну нет, Википедия незаменима как источник когда вообще ничего о каком-то явлении/понятии не знаешь, но когда надо какую-то мелочь [B][U]абсолютно точно[/U][/B] узнать, она не авторитет. Спасибо, хотя юникод орг тоже как-то с натяжкой - "Date: 04/15/98", мягко говоря устарело. И это стандарт для преобразования из 1251 в Юникод, а не сама 1251. Норматив от Майкрософт (2014 года или новее, после включения символа рубля в Юникод) был бы убедительней. Я бы вообще выкинул из 1251 символы вроде #CYRILLIC SMALL LETTER LJE, которые в русском не встречаются.
ГИС ЖКХ: Предложения по информационному обмену
 
[QUOTE]МихаилИгоревич пишет:
Готов частично профинансировать разработку веб сервиса для 1с, а также выступить разработчиком ТЗ.[/QUOTE]1c это немного другое, там специфический Visual Basic с русским акцентом. Конечно это достойно отдельного обсуждения, работающих в 1с немало и есть платный модуль для гисгмп, так что есть с чего начать. Кстати, модуль для ГИС жкх вроде бы тоже есть, в соседнем разделе обсуждали как замечательно все синхронизируется с 1с, но кажется выгрузка-загрузка вручную. Вот [URL=http://www.forum.mista.ru/topic.php?id=780234]тут[/URL] начали что-то делать по автоматизации, но похоже пока не очень-то ладится и им посоветовали тоже сделать сервис на C#. Я за 1с не возьмусь - так как там специфическое обновление форм и как представлю что это все править после каждой смены версии форматов гис жкх, становится дурно.
Теоретически,если все же сделать DLL автоматической смены  отчетов, можно подумать как прикрутить к 1с. Пока что проектирую DLL для обертки и отправки уже готовых данных, до подготовки самих отчетов еще не скоро дело дойдет.
Средства работы с XLSX-файлами
 
[QUOTE]AlcorVol пишет:
Ну, если не нравится ¤, [/QUOTE]Дело-то не в том, что нравится или не нравится, а чтобы совпадало с официальным от Майкрософт, а то получится не очень хорошо. Вот где смотришь официальную страницу?
[QUOTE]AlcorVol пишет:
Насколько мне известно, в 1251 только одна пустая позиция - #98. И она ничем не занята до сих пор.[/QUOTE]я смотрю через вот такой файлик, в который выведены последовательно все коды символов с #20 по #FF просто в Блокнотe, шрифт Lucida Console и вижу следущее: На всякий случай проверил основные шрифты использующиеся в Office: Arial, Times New Roman, Tahoma, Calibri, Courier - везде одно и тоже. Странно, похоже #98 вообще пропускает и показывает символ торговой марки со следующей позиции. Правда последнее обновление шрифтов, вышедшее в этом году не установлено - там тоже добавили символ какой-то валюты. Поэтому меня тоже удивило заявление, что в официальной есть свободные места, на рисунке их реально было с десяток. Сейчас искал, пока нашел только такую же как у меня в Блокнтое, но с подписями кодов Юникода:

[SIZE=85px][COLOR=greenpt]Отправлено спустя 14 минуты 37 секунды:[/COLOR][/SIZE]
[QUOTE]AlcorVol пишет:
И как раз такие-то последовательности неплохо было бы "нормализовать" - особенно, при работе со всякими Гос.ИС.[/QUOTE]Согласен.
[QUOTE]Basil пишет:
XML, состоящие из одной длинной строки, приходится предварительно расставлять CRLF [/QUOTE]Собственно, в других программах сравнения не лучше. В ряде случаев расстановки CRLF нужно избегать, например к "нашим баранам" SOAP, это сломает каноникализацию (****, еле выговоришь) и проверку ЭП, там допустимы только LF и в файл на отправку нужно писать именно полученный при каноникализации текст. Но это наверно напишу подробно в другой теме, не будем тут обсуждать.
ГИС ЖКХ: Предложения по информационному обмену
 
[quote:2ry8c0t6]это нужно для жителей[/quote:2ry8c0t6]Я уже тут писал, что на данный момент система авторизации на ГИС ЖКХ заслуживает самое мягкое определения "крайне непродуманная". В стране все еще много тех, кто не зарегистрирован на Госуслугах - в основном это пенсионеры. А пенсионеров - треть населения страны. И они очень часто являются формальными владельцами. Итого, минимум треть квартир даже в принципе (не обращая внимание на то, что Росреестр привязывается как попало) не могут зайти и посмотреть, что же там УО внесли.
[quote:2ry8c0t6]SOAP в ЛК[/quote:2ry8c0t6]Это конечно была шутка, забавное преувеличение. но! в каждой шутке как известно только доля шутки. ЭП на файлы передаваемые в ЛК не ставится, кто отправитель заранее известно, так что SOAP от XML практически не отличается в этом случае.
[QUOTE]Sergey Cheban пишет:
Протокол SOAP - открытый. И вот с этой точки - пожалуйста, сами, если можете. А если не можете, то и говорить не о чем. А DLL - это очень, очень плохая идея:Непонятная DLL, работающая с криптографией и имеющая доступ к приватным ключам - это не безопасно.DLL привязывает нас к платформе Windows.Интерфейс, предоставляемый DLL - это чистый C. Даже не C++. Работать с ним из современных языков программирования неудобно.DLL выполняется в адресном пространстве чужого процесса. Если в результате процесс падает, не всегда понятно, по чьей вине это произошло. Нет внятного разграничения зон ответственности.В DLL наверняка были бы ошибки. Распространение DLL с исправлениями этих ошибок - задача нетривиальная.[/QUOTE]По пунктам:
1) Более половины реализации SOAP одинаково не только в рамках ГИС ЖКХ, но и вообще всех российских ФГИС (все что вне Body по большому счету описано SOAP, отличий не так уж много). То есть что разработчиков множество это плохо, а что государство не предложит единую реализацию SOAP, на которую могли бы ориентироваться те же разработчики будущих ФГИС, это нормально - как хотите так и плывите. Правильно Вас понимаю?
2) небезопасно, согласен. Но все криптопровайдеры тоже в своем составе имеют DLL, естественно подписанные и сертифицированные ФСБ. Им вы доверяете? И при этом лично звонили проверяли подлинность сертификата? Ну и прекрасно, используем их.
Собственно для данной DLL (обертки XML в SOAP, добавление подписи, отправки SOAP на сервер ГИС)  нет необходимости работать с приватными ключами напрямую (даже скорее посторонняя функция, зачем изобретать велосипед и реализовывать криптографические примитивы) - можно вычислить необходимые значения либо через сертифицированный криптопровайдер (который, "зараза", формирует cades-bes в отсоединенной ЭП файла, но тем не менее сам не умеет формировать xades-bes внутри XML) либо через сертифицированную версию OpenSSL (как рекомендуется в статьях на хабре). Плюс цифровая подпись DLL, что ее никто не изменял и она сама ключи не ворует. Понятно, если бы библиотека была подписана подписью ГИС ЖКХ или КриптоПро к ней было бы больше доверия, чем к "левому" разработчику, потому и просим.
Естественно, будет ли пользователь использовать сертифицированный криптопровайдер, сертифицированные бинарные файлы OpenSSL (и платить денежку) или общедоступные несертифицированные или соберет свою сборку - остается на совести администратора информационной безопасности организации пользователя. Нет смысла "не выпускать джинна из бутылки" - кто захочет несертифицированный, сделает и по тем статьям на хабре.
3) На Linux есть аналог DLL - SO библиотеки. Если компилятор кроссплатформенный, то сделать библиотеку для Linux примерно так сложно как передать параметр TargetOs и ссылки на библиотеки взять в управляющие комментарии (в кроссплатформенных компиляторах как правило уже есть билды стандартных Unit с использованием библиотек поддерживаемых операционных систем, нужно только Unit собственного сочинения перестроить под них). Тем не менее, у меня, например, нет планов поддерживать библиотеку на *nix системах, так как у меня нет возможности составить корректные представления о криптопровайдерах на *nix и написать соответствующие Unit.
4) Здравствуйте, при всем уважении, а кроме семейства Си языки какие-то знаете? У меня например мои все DLL на Паскале. Главное, что бы формат параметров можно было описать на любом языке - неважен язык программирования разработчика DLL. Это дает огромное преимущество по сравнению с проектами которые все делают именно на C# или Java. Не считая отсутствия громоздкого dotNet. Это компенсирует некоторые неудобства. Написать объект на вашем языке программирования когда уже есть реализация кода объекта в виде отдельных функций DLL  тоже простая задача - все основные функции операционной системы Windows как раз содержатся в DLL, тем не менее работаете с ними через объекты.
Если же Вы имеете ввиду ООП при работе самой библиотеки, то огромное количество COM объектов как раз используют фабрики экземпляров в виде DLL и OCX TLB (расширение не особо имеет значение - по сути это тоже внешний исполняемый код, подгружаемый программой). Но COM объекты как раз и привяжут нас к Windows. dotNet полагаю тоже?
5) Ошибки есть везде и зона ответственности не разграничена, согласен. Но посмотрим, в среднем процессе Windows 7 вовлечены более чем 100 библиотек - не потому что разработчик программы их все загрузил, а потому системные и околосистемные библиотеки тянут за собой огромное количество зависимостей. В этом смысле, если добавится еще одна библиотека, погоды это не сделает. Для этого есть современные средства отладки собирающие данные активности на момент сбоя во всех потоках процесса. Определить, что вылетело при выполнении такой-то функции - на раз.
Тут хочу высказаться о языке программирования, на котором сделана библиотека - компиляторы Паскаля как раз славятся тем, что при загрузке модуля (будь то программа или библиотека) сразу же запрашивается память у системы "про запас", не через getmem, а как еще один сегмент наряду с кодом и данными (в них сразу записаны значения) - сегмент "кучи" (значения не записаны, заполнен "мусором" из оперативной памяти). По умолчанию это 8 мегабайт, мало по нынешним меркам, но на хранение результатов криптооперации - с головой хватит. Заранее объявленные глобальные переменные сюда не входят - один раз была нужда и объявил глобальный многомерный массив, потянувший на гигабайт - и все это скомпилировалось в сегменте данных. Если памяти не хватит библиотека не загрузится вообще и будет ясно - вывалилось до загрузки библиотеки и обработать это корректно задача использующей программы. Если память есть, то все загрузится и пока запас не исчерпан, никакой дополнительной памяти у системы не запрашивается и всю обработку правильности использования памяти в сегментах ведет стандартный код, вставленный компилятором. То есть со внутренней "кучей" можно что угодно делать - это повлияет на корректность работы библиотеки, но на работоспособность программы, использующей библиотеку, и системы это не повлияет. Хотя конечно памяти потребляет больше, по сравнению с запросом и освобождением у системы памяти для каждого объекта, но так надежнее.
С использованием данных, переданных основной программой гораздо сложнее, но и тут можно подстелить соломку, проверяя все указатели системной функцией (IsBadReadPtr IsBadWritePtr кажется - для своих программ не делал, но если распространять библиотеку, то нужно делать), как это делает само ядро операционной системы, и возвращая код ошибки "неправильный указатель", если проверка не пройдена. Лезть в память программы, если библиотеку об этом не просили и не дали правильный указатель - заведомо ошибочное дело, нет разницы в одном мы адресном пространстве или в разных.
6) проблемы обновления DLL абсолютно такие же, как и у программы, а именно - что заменить файл модуля, который запущен в данный момент, мягко говоря, непросто. Плюс при этом нужно убедиться, что замена не испорчена, а то и подписана ЭП. Проще в том плане, что объем библиотеки мал. Апплеты панели управления с расширением CPL - все те же DLL, но написанные по определенным требованиям и выводящие пользователю диалоговые окна. В том числе среди них есть такие, что реализуют функцию обновления какой-либо программы. Есть и другие средства решения: например можно функцию обновления вызывать в самой DLL при инициализации. Либо экспортировать функцию обновления отдельно, а в комплекте распространять  bat файл, запускающий rundll32 для загрузки библиотеки и выполнения функции.
[QUOTE]Sergey Cheban пишет:
3. В каком виде должна быть ЭЦП? Как она должна отделяться от данных?[/QUOTE]Насчет этого - никаких проблем, просто ЭЦП должна быть отсоединенной, в виде отдельного файла с расширением sig. Заметьте, в ту же налоговую (и из нее тоже) передается отсоединенная ЭЦП. Еще краем уха слышал, сейчас можно подписать VBScript, тоже по сути текстовый файл, в подробности не вникал пока. С остальным соглашусь, формат должен быть описан точно.
[QUOTE]Sergey Cheban пишет:
Да и присутствие на рынке _множества_ разработчиков мне кажется вредным для дела.[/QUOTE]Это конечно так, однако вот так посмотришь что в одном регионе "горячее водоснабжение", в другом "подогрев воды" и так далее и тому подобное. Программа, учитывающая все нюансы будет огромной и соответственно пропорционально количеству кода возрастет количество ошибок. Собственно именно это и видим на примере ГИС. Хотя наверно тоже можно поделить на библиотеки :D
Средства работы с XLSX-файлами
 
Вообще молодцы, даже в выходные исправляете.
По кодировкам Юникода конечно много где можно прочитать - но если думаешь, что перекодировать 33 буквы русского алфавита достаточно (32 последовательно и Ё отдельно), то это не так. Некоторые умудряются Ё и Й кодировать соответственно как (Е и точечки отдельно) и (И и крышечка отдельно). В своей программе синхронизации файлов... (знаю, таких программ миллион, но наши пользователи их в ступор вгоняют - полный путь к файлу может превышать 260 символов, например, был 254 символа, в том числе 150 символов название самого файла, потом создали папку на верхнем уровне "архивы 2015" и перенесли папку с файлом туда - в итоге Word такой документ через раз открывает, а остальные программы не могут даже скопировать, у "любимого" Экселя наоборот - выяснилось ограничение в 212 символов в какой-то побочной технологии и файл замечательно копируется, но не открывается, Эксель говорит "не найден") Так вот в программе наткнулся на файл с таким Й, видимо сохранили из интернета страничку с таким И+крышечка символом - программа на этом месте крепко зависла. Так что с [B][U]чужим[/U][/B] Юникодом глаз да глаз.
[QUOTE]AlcorVol пишет:
Oh, yes! Правда, VFP к этому как-то не очень приспособлена. Проблем будет куча. И кстати, имена листов уже кто-то там в 1251 перекодирует. Я бы предпочёл в 1251 работать. Для ГИС ЖКХ - точно будет достаточно того, что есть. Особенно, если Рубль добавить.[/QUOTE]Если честно, то от однобайтных кодировок лучше отказываться где только можно. Главное себя заставить и планомерно переходить - это тоже своего рода подстилание соломки. Все (или почти все) странички я уже перевел на utf-8. Отправной точкой стал переезд сайта на _общеизвестный хостинг_ - там просто для всех страниц сервер выдает что они в utf-8, так как админка в utf-8. И это проблема сайта, если остальные страницы по факту в другой кодировке. Можно указать вторую в самой странице, но половина браузеров все равно покажет "крокозябры". Сначала тоже было больно - в текстовых файлах в начале строит символ кодировки utf-8, браузер корректно пропускает его первый раз. Но если включать несколько файлов в страничку, то символ встретится в середине и у браузера будет "разрыв шаблона", выдаст ошибку или сдвинет все оформление страницы на высоту 1 текстовой строчки. Ничего, написал программку, убирающую символ. Теперь все файлы что содержат кириллицу перекодирую. Для сохранения в БД местами осталось win-1251 (так вручную проще смотреть/исправить и слишком много места занимает utf-8).
С EXE-программами конечно сложнее - win-1251 как переходная к utf-8 сохраняется, но между win-1251 и utf-8 пока перекодирую только кириллицу и некоторые специальные символы. Если [U][B]моя[/B][/U] программа при этом работает с win-1251, то прочие символы просто не использую и игнорирую. Если же другие символы используются - то вся работа программы в utf-8.
[QUOTE]Basil пишет:
И если в исходном файле в строке есть символ #A4, при записи он преобразуется в символ рубля, хотя это не требовалось.[/QUOTE] Вопрос: #A4 на основании чего выбран? это официальный код для рубля? В смысле Майкрософт тоже его использует в win-1251? Смутно помню, когда только добавили символ рубля, его поместили на одно из "свободных мест" (ранее не занятых) в официальной win-1251. Меня тогда удивило, что свободные места есть. Поэтому смущает замена символа валюты на символ рубля. Либо символ валюты был ранее неофициальный, либо у символа рубля другой код в официальной версии.
[QUOTE]AlcorVol пишет:
Если бы дела обстояли именно таким образом, то на одном ПК (и тем более, в одном и том же документе) нельзя было бы указывать денежные поля с разными валютами. Странновато и примитивно как-то... Не верится просто.[/QUOTE]Мне тоже не верится, скорее всего где-то еще указывается "маскировочный" символ, но допускаю, что если он там явно не указан, то значение берется из локали системы.[quote:2xvhfzp3]WinMerge[/quote:2xvhfzp3]Спасибо, попробую. Обычно использовал консольный diff из FreePascal (но там есть некоторые неудобства, например, оператор конца предыдущей функции показывает в добавленном блоке, а оператор конца добавленной функции соответственно не показывает), и набросал необходимое для своего аналога, но не написал.
Средства работы с XLSX-файлами
 
Просмотрел PRG - много всего, есть именованные диапазоны и даже PageSetup. Из того, что бросилось в глаза - импортируется Sleep, этого всегда стараюсь избегать - в зависимости от реализации Sleep может вызывать 100% загрузку одного из ядер процессора. В WinXP+ более правильно - создать "пустое" событие (которое не может наступить) и "ждать" его указанное время функцией WaitForSingleObject.
Средства работы с XLSX-файлами
 
[QUOTE]Basil пишет:
нужно всё-таки поискать описание формата xlxs[/QUOTE] ;) Как в анекдоте прямо: если ничего не помогло - прочитай инструкцию.
[QUOTE]AlcorVol пишет:
Не такой уж мегапроект.[/QUOTE]Согласен, но когда-то все равно придется.
[QUOTE]Basil пишет:
Мне этот пакет не очень нравится, когда-то были проблемы с открытием xlsx. Думаю, проще использовать Libre.[/QUOTE]Я тоже мягко говоря "не в восторге", но скорее откажусь от xlsx в пользу xls, чем перееду с привычного офиса. Первая версия пакета совместимости вообще была ужасна, открывала файлы 2007 Экселя через раз, потом года через полтора стало получше, чего-то допиливают постоянно - теперь уже сохраненные в Экселе 2010 файлы открывает, но это к сожалению не решает основной проблемы конвертера - конвертированный файл в папке temp, имя из цифр и обычное "сохранить" не прокатит - файл просто сотрется при очистке временных файлов, надо каждый раз после конвертирования "сохранить как" и придавать осмысленное имя. Как будто было нельзя cконвертировать в ту же папку где исходный с исходным именем без X.
[quote:1co2mxw1]трёхзначный: E2 82 BD[/quote:1co2mxw1]Неудивительно. Если вкратце, 1 байт UTF-8 нужен на символы Юникода до 007F (они не кодируются, просто отбрасывается байт 00 в начале), 2 байта 0080 по 07FF (кодирует 11 бит), 3 байта до FFFF(16 бит). То есть 3 байта UTF-8 достаточно чтобы закодировать любой символ из UTF-16. Каждый дополнительный байт UTF-8 позволяет кодировать на 5 бит больше (еще 3 бита добавляются в служебные) - максимальное число байт разное в разных версиях стандарта, вплоть до 6 байт (кодирует 31 бит из UTF-32). Служебные формируются так: В первом байте UTF-8 количество бит "1" в начале равно количеству байт в коде символа, далее идет разделительный бит "0". Второй и следующие байты начинаются с "10".
На примере символа рубля в UTF-8, E2 82 BD = [1110] 0010, [10]00 0010, [10]11 1101 в квадратных скобках служебные биты, собираем неслужебные, получим 0010 0000, 1011 1101 = 20 BD (символ рубля в UTF-16).
Ошибки в ГИС (эмоции пост)
 
[quote:2bracnn0]Для обсуждения программных решений отдельный раздел есть. ;) [/quote:2bracnn0]Так это.. тогда еще отдельного раздела не было, после того сообщения все и пошло. ;)
[quote:2bracnn0]для оптимизации работы объекты и договоры попрятались,[/quote:2bracnn0]Эта пяяяяяяяяяяять!!!!! Надо на своих сайтах так же сделать, заходит пользователь, а на странице только кнопки Вход и Поиск. :D :D
Пресловутый подогрев воды
 
Хех, я говорю что РСО надо договорится между собой (раз все все понимают), а ты - что они сами по себе, и точка. Круг замкнулся.

У нас называется горячее водоснабжение и платится (оба компонента - вода в кубометрах и энергия в гигакалориях) Энергосбыту. То есть Энергосбыт покупает воду для горячего водоснабжения у Водоканала, потом продает оба компонента населению. Я не понимаю, почему у нас так можно, а в Вологде нет? Почему местные Теплосети не могут купить воду у Водоканала? Это такая специальная статья ЖК для конкретного предприятия или их убеждения не позволяют покупать?  :?
Закрадывается впечатление, что УК выгоднее непрямые платежи, поэтому любые варианты прямых (или непрямых не через УК) сразу отвергаешь без рассмотрения. (Шучу.) Тогда конечно, "Подогреву воды" - жить!  :D
Ну хорошо, а что мешает самой УК так сделать? Разве это будет незаконно купить воду у Водоканала, продать населению уже подогретую и запретить прямые платежи, так как вода [B][U]уже куплена[/U][/B] у Водоканала? То есть у УК долг перед Водоканалом, а у населения перед УК.
ГИС ЖКХ: квитирование
 
Я имею ввиду, что это работа программистов банка на перспективу. Добавление поля еще не значит, что оно реально работает. Пока что, например у меня, даже нет возможности как гражданину зайти в ЛК и увидеть какой же там ЕЛС и идентификатор ЖКУ присвоили квартире. Потому что, это увидит (может быть, и то есть сомнения) основной квартиросъемщик, а меня ЛК посылает на все 4 стороны - нет прав.
Средства работы с XLSX-файлами
 
[QUOTE]AlcorVol пишет:
Надо как-то сделать, чтобы расхождения не накапливались.[/QUOTE]Да, похоже для командной работы надо git осваивать и github.
Средства работы с XLSX-файлами
 
Да да побольше примеров) Дома у меня стоит Office XP с пакетом совместимости (добавлю, пакет почему то считает, что язык системы - японский) для открытия XLSX. Итак, пакет совместимости вообще отказался открывать пересохраненный файл, выкинул строчку иероглифов. Открыл в Winrar - бросилось в глаза, что многие файлы по объему стали меньше, не говоря про отсутствие нескольких папок (те папки как я понимаю связаны с настройкой печати на принтер). В workbook.xml порезаны объявления именованных диапазонов и еще какие-то отношения с ними связанные. С именованными диапазонами я не особо знаком, но именно в таком расположены данные для списка - то есть список так работать не будет. Их нужно как-то аккуратно обработать чтоб не исчезли. styles.xml тоже ощутимо похудел.
ГИС ЖКХ: квитирование
 
Просто замечательно. Хотя мне кажется, что появление таких новшеств никак не связано с ГИС. У нас например, уже года полтора в терминалах пункт оплата ЖКХ, но все знают что по факту пока не работает.
Пресловутый подогрев воды
 
[QUOTE]AlcorVol пишет:
[QUOTE]two_oceans пишет:
 Однако мне немного кажется странным, что предлагаешь узаконить именно этот "изворот".[/QUOTE]
Это не изворот.  :) Это - повседневная реальность жизни. У нас в каждый дом не три, а две трубы идут. (Обратки считать не будем.  :) ) Для меня изворот - это как раз "самостоятельное приготовление...".  :)[/QUOTE]Кажется, я пропустил отличия между "Подогревом воды" и "самостоятельным приготовлением". Если так, прошу извинить, на сторонний взгляд что так, что этак. В остальном же, как-то это неправильно, почему обычного ГВС не хватает. Неужели нельзя бойлеры оформить как котельные - вместо котла и топлива - теплообменник. Дескать, такие у нас котельные прогрессивные.
[QUOTE]AlcorVol пишет:
[QUOTE]two_oceans пишет:
Не в обиду будет сказано, но я сомневаюсь, что у Теплосети нет утечек теплоносителя.[/QUOTE]
Ну, при чём тут эти "утечки"? Они есть всегда и везде. Все эти утечки учитываются, когда РЭК утверждает тарифы на гигакалории. А так, схема подачи теплоносителя - закрытая. Он и батареи греет, и холодную воду до горячей подогревает. И уже остывший - обратно на ТЭЦ течёт. Ни в какие краны населения не поступает.[/QUOTE]Готов допустить, что система закрытая - вдруг действительно пар подают. У нас вот не пар, а вода и почти на каждой батарее есть если не кран, то шайба для спуска воздуха, то есть система не закрытая. Технически возможно (хотя и неудобно) набрать воду из батареи.
Я говорил не столько об утечках и замкнутости, сколько о том, что между Водоканалом и Теплосетью уже есть договор (восполнение теплоносителя). Это значит, что изменив пару пунктов в договорах можно всю плату перегонять в Теплосеть и не маяться с "приготовлением или подогревом", они там сами могут рассчитаться и не грузить УО  проблемами.
[QUOTE]AlcorVol пишет:
[QUOTE]two_oceans пишет:
Не обязательно на муниципальном уровне, региональный закон тоже подойдет [/QUOTE]
Как бы не так! Если ЖК РФ не знает коммунальной услуги "подогрев воды", то родить её на региональном уровне невозможно. Это только по Конституции Россия - федерация. А на самом деле - унитарное государство. Почти всё в федеральном центре регулируется и утверждается. Да и ГИС ЖКХ - не лучшее ли тому доказательство? Всё-превсё в одном центре соберём!  :D[/QUOTE]Верно, "подогрев" не родить, потому что нет в исчерпывающем перечне. Но назвать то, что уже есть в реальности "горячим водоснабжением" либо другим подходящим пунктом и подогнать под ЖК наверняка вполне возможно. Неужели в федеральном законе указано в подробностях какие должны быть котельные и прочие мелкие детали? Полагаю, что нет такой точности и изменив детали можно сдвинуть "правовое поле" на котором все рассматривается. Региональный закон как раз может сделать из светло-серого - белое, а темно-серого - черное. Останется поменять с темно-серого на светло-серое совместными действиями организаций.

[SIZE=85px][COLOR=greenpt]Отправлено спустя 18 минуты 43 секунды:[/COLOR][/SIZE]
Вот пример вспомнился немного из другой области - недавно ОМСУ запросили какие у нас тарифы на проезд в транспорте. Фокус в том, что если "регулируемые", то должны быть договора с перевозчиками и доплата из бюджета до экономически обоснованного, а если "нерегулируемые", то ничего не нужно. Доплата естественно не запланирована, так как тарифы равны обоснованным, договоров нет. Но! выяснилось что доплата может быть нулевой! То есть можно заключить договоры и провозгласить что доплата нулевая, а тарифы "регулируемые", а можно не заключать и тогда тарифы "нерегулируемые". Такие законы.
Средства работы с XLSX-файлами
 
Можно мне тоже пример - открытие, вывод слова кириллицей, сохранение? energy-sv <собака> yandex <точка> ru (Да, из своих адресов нашел вот в тему "энергичный", специально добавлю к рабочему почтовому клиенту)
Стили ячеек (цвета, форматы) тоже своего рода отношения: на самом деле Эксель не устанавливает свойства каждой ячейки, а создает стиль ячейки и цепляет к нему список ячеек (ну в смысле наоборот ячейка указывает на стиль, но удобнее понимать так). Возможно именно указание на стиль портится, надо попробовать расковырять до уровня XML. Видимость листов наверно ГИС не принципиальна, но тоже интересный эффект.
Пресловутый подогрев воды
 
[QUOTE]AlcorVol пишет:
Вот тут, уважаемый Константин, я с тобой не согласился бы. Жизнь - она хитрее нормативных документов. Никакой "дополнительной услуги" под названием "Горячее водоснабжение" в этой схеме (которая широко применяется не только в Вологде, но - вроде бы - и в Перми, и в Кирове), на самом деле, нет. <...> . Если делать всё по уму, то в ЖК РФ нужно внести изменения, которые допускали бы существование самостоятельной коммунальной услуги "Подогрев воды" в случае отсутствия централизованного горячего водоснабжения. И всё встало бы на свои места.[/QUOTE]То есть половинку услуги засчитать как отдельную. Правильно?
[QUOTE]AlcorVol пишет:
Вот, в том-то и дело, что РСО не хотят, чтобы платежи проходили транзитом через УО. [/QUOTE]
Ну, даже спорить не буду, я не юрист, и изменения законодательства явно нужны на федеральном уровне. Однако мне немного кажется странным, что предлагаешь узаконить именно этот "изворот". Если УО не может предоставлять горячее водоснабжение,   :idea: есть другой вариант решения - бойлеры отнести в ведение Теплосети, тогда схема будет как во всех остальных регионах и для одного из двух РСО будет как они хотели - прямые платежи. Итого - решение проблемы своими силами, не ожидая федерального законотворчества.
Например, мы платим Энергосбыту за ГВС (и за "нагрев" и за саму воду, в квитанции указаны оба компонента). (К слову там же и за отопление и за электричество - без бутылька не разобраться - уже привыкли, что за электричество переплата, а за отопление долг - и в кассе говорят,что нет долга "по сумме", но чем руководствуются при делении платежа  по услугам - непостижимо). Никто не пытается платить водоканалу за ГВС. Как ее нагревают и откуда они ее берут жителей не волнует, но, естественно, взять кроме как у водоканала неоткуда, то есть у нас договариваются с водоканалом, ещё как.
И как-то будут это вносить в ГИС ЖКХ. На текущий момент Энергосбыт крут - уже наверно пару лет как есть сайт, где можно посмотреть начисления и суммарные платежи за месяц, передать показания и авторизация гораздо проще - номер лицевого счета и пароль из смс. Не нужно подтверждать личность через Госуслуги. Правда это нисколько не помогает разобраться с цифрами.  :D

[QUOTE]AlcorVol пишет:
В нашем случае - никто ни с кем не договаривается.  :) Водоканал чисто за воду получает, а Теплосеть - за тепло. Каждая РСО - за свой ресурс. И знать они друг друга не хотят. Да и зачем?   :) [/QUOTE]Не в обиду будет сказано, но я сомневаюсь, что у Теплосети нет утечек теплоносителя. Если бы это был маленький зарубежный поселок с замкнутой системой отопления, построенный пару лет назад, я бы поверил. Но Вологда не маленький поселок и страна наша любимая, полагаю, система отопления хотя бы где-то да прохудилась. Откуда они возмещают утечки - ведь не из ближайшего водоема ведрами носят? Или незаметным образом вблизи города и перечисленных соседних городов открылся портал в рай и трубы теперь не изнашиваются? "Тогда мы идем к вам" :D
Если серьезно, то нежелание договариваться как раз и "лечится" нормативными актами. Скажут "сверху" договариваться иначе штраф - желание сразу найдется.
[QUOTE]AlcorVol пишет:
Муниципальным актом тут не обойтись. Сразу наткнётесь на проблемы при заполнении ГИС ЖКХ, которые только на федеральном уровне решаются. А внутри города - никаких особенных проблем нет. Даже ГЖИ всё понимает.  :)[/QUOTE]Не обязательно на муниципальном уровне, региональный закон тоже подойдет :) Это надо смотреть по разграничению полномочий между уровнями власти, главное чтобы региональный закон не противоречил федеральному законодательству и чего-то разъяснял. У нас порой по каждой мелочи издают региональные законы, которые на более чем на 3/4 слово в слово соответствуют федеральным, остальное - количественные уточнения. Тут-то бы и уточнить, что вот такой местный колорит - ГВС делаем так-то и все это относится к такому-то пункту исчерпывающего перечня. На основании регионального закона подправить лицензии.
ГИС ЖКХ: Предложения по информационному обмену
 
[QUOTE]AlcorVol пишет:
[QUOTE]two_oceans пишет:
Ещё подумал - а ведь если интерфейс похожий, то надо при изменении ЛК менять программу, это однако похуже шаблонов будет.[/QUOTE]
Не совсем понял. Я имел в виду самостоятельное интерактивное приложение, интерфейс которого (GUI) по стилю напоминает стиль работы юзера в ЛК. А если будут меняться сами форматы структуры данных (как сейчас шаблоны меняются), то это, конечно, в  программе клиента (УО), осуществляющей подготовку XML-файлов, учитывать придётся.[/QUOTE]
А я не про форматы, а про то, что они и сайт частенько меняют - перетаскивают форму с одного раздела на другой без всякого предупреждения. То есть периодически придется синхронизировать вид приложения с текущим видом сайта.
[quote:3nv6tnms]Успехов! А я пока продолжу с XLSX-шаблонами ковыряться. Пора бы отложить в сторону писанину на форуме, а заняться делом. :)[/quote:3nv6tnms]Как раз о том же подумал, да и другой работки подкинули. Поэтому сокращаю время на форуме и ищу наметки в Интернете. Вот что вчера нашел:
[url:3nv6tnms]http://www.clevercomponents.com/articles/article022/soapsecurity.asp[/url:3nv6tnms] Пример на Дельфи как подписывать XML, на ГОСТ нужно изменить пару деталей и так как функция подписания по ГОСТу уже найдена, я уже знаю каких деталей. С приведением к каноничному - мрак (самодельные примеры не учитывают всех вывертов стандарта, если будет XML без вывертов, то сработают, но есть предчувствие что это не сработает в самый неподходящий момент). С кодировкой base64 виду чуть лучше - она везде есть, но исходник пока не нашел. Ничего, найду, где-то он мне уже встречался.
[url:3nv6tnms]http://forum.foxclub.ru/read.php?29,562055[/url:3nv6tnms] "Возможна ли каноникализация XML средствами VFP". Специально для пилящих SOAP на VFP. Кроме каноникализации там еще и декларации функций майкрософтовского криптопровайдера - как получить хэш и подпись и чего с ними потом делать.
[quote:3nv6tnms]Коллеги, чем предложения разработчикам ГИС об изменениях будут дальше от существующих схем, тем меньше вероятность того, что их хотя бы прочитают.[/quote:3nv6tnms]Согласен, но с другой стороны сколько можно ждать "милости от природы", поэтому наиболее далекие от существующих схем предлагаю сделать совместными усилиями - я вот практически решился написать DLL для подписи XML. Тема достаточно интересная в плане множества других применений XML. Ранее думал, что моего кунг-фу не хватит, но оказалось программисты ФГИС это не придумали, есть международный стандарт - сразу стало легче. Остается вопрос реализовать подписание как в ГИС ЖКХ и остановиться или реализовать формат полностью. В частности, сертификат, можно указывать многими способами. О полном формате нашел вводную статью: [url:3nv6tnms]http://minichden.narod.ru/articles/xmldsig.htm[/url:3nv6tnms].
По этому вопросу - мне нужно будет как-то проверить результат. Пилить в C# только ради проверки нет никакого смысла. Может быть, если у кого есть рабочая схема подписи, я предоставлю "самодельные" тестовые сертификаты и вы ими подпишите несколько файлов?
[quote:3nv6tnms]Поскольку xlsx это «усложнённый» xml, то (навскидку) дополнительной работы для его обработки должно быть немного.[/quote:3nv6tnms]Обоснование понятно. Однако, как мне кажется это может иметь обратный эффект: SOAP, это то же XML, так что с ним программисты ГИС уже "наигрались" и реализовывать еще что-то промежуточное между SOAP и XLSX будет слишком похоже, при дополнительной необходимости отражать изменения на еще один формат, и потому не так уж привлекательно. Однако даже если сделают возможность грузить SOAP через ЛК без кучи регистраций в качестве ИС и тестирований, тоже будет достаточно забавно.
[quote:3nv6tnms]Да, практически все более менее умеют работать в Excel. Но Excel умеет открывать и сохранять xml, csv, ods и с натяжкой dbf. [/quote:3nv6tnms]Вот честно говоря, насчет xml не уверен, с таким же успехом html можно дополнить в список. Сам формат Эксель конечно умеет открывать и сохранять, но при этом при создании/сохранении файла в Экселе в тегах столько специфичного для Экселя "мусора" - всяческие стили офисного пакета, форматы, формулы и т.д. - что ни одна уважающая себя система не будет этот хлам обрабатывать без дополнительного "очищающего" конвертера. Из-за такого "мусора" в тегах я даже FrontPage давно перестал использовать для редактирования веб-страниц.
Средства работы с XLSX-файлами
 
Кажется, примерно представляю в чем может быть проблема. Если есть скрытые листы, то скорее всего они не просто так, и на видимые листы "тянутся" какие-то формулы или "отношения" между ячейками. При ручном заполнении Эксель их автоматом корректирует (либо не совсем автоматом, с помощью каких-то макросов от авторов шаблона). Когда пишете программно, нужно тоже эти "отношения" указывать.
#
[QUOTE]AlexRed пишет:
Может у кого было такое, что делать то?[/QUOTE]Написал простенький макрос сравнения - так он мне показывает, что значение на листе 10 (Жилые помещения) в ячейке A5 (строка загрузилась) отличается от значения в ячейке A6 (в строке ошибка). Чем именно отличается еще посмотрю, но скорее всего Вам всего лишь нужно скопировать значение в первом столбце из загрузившихся строк в ошибочные.

[SIZE=85px][COLOR=greenpt]Отправлено спустя 13 минуты 5 секунды:[/COLOR][/SIZE]
Хм, будете смеяться, но похоже, что обработанные строки неправильны. У них в конце после дом 15 идет пробел, как и в адресе на листе "Информация о МКД". У необработанных строк пробела в конце нет.
#
[QUOTE]AlcorVol пишет:
Ув. burmistr, Вы не могли бы объединить три последних темы товарища suineg в одну?[/QUOTE]Полагаю, этого не позволяет стандартный функционал движка форума. Можно исправить прямо в базе данных, но для этого нужно знать, что и где править. В общем случае, нужно "всего лишь" изменить привязку сообщений на одну тему, объединить начальные сообщения в одно, исправить счетчик сообщений автора, потом убрать лишние "опустевшие" темы. Плюс зайти в базу данных на сервере тоже задача нетривиальная - для безопасности внешний доступ обычно отключен или разрешен только с определенных адресов в панели администратора хостинга. Еще можно скопировать текст со всех тем и вставить в одно сообщение, потом удалить лишние темы. Еще вариант - добавить функцию объединения тем в движок. В любом случае, слишком много движений.
[QUOTE]AlcorVol пишет:
Номера ЕЛС присваивает ГИС ЖКХ. Ваша задача - их запомнить.[/QUOTE]Поддерживаю.[QUOTE]AlcorVol пишет:
Ваш вопрос по контрольным разрядам в составе ЕЛС (удалённый администратором) - тоже из той же серии. Не Вы должны их вычислять. Это дело ГИС ЖКХ.[/QUOTE]А вот это более интересно - лишний раз проверить отправляемые данные и "подстелить соломку" не помешает. Алгоритм проверки я не смотрел (скажу сразу), но (судя по вопросу) весьма удивляет, что снова кто-то "гениально" предложил использовать символы кириллицы, похожие по начертанию с латинскими. Это наводит мрачные подозрения, что кто-то будет вбивать латинские. Учитывая возможные проблемы с кодировками, я бы вообще кириллицу использовал как можно реже и тем более не в идентификаторах. Видимо, снова считают среднестатистического пользователя дураком, не способным элементарно переключить язык.
В случае аналогичной системы ГИС ГМП (штрафы ГИБДД, в частности) там можно использовать и латинские и кириллицу, да еще и алгоритм проверки (там определяется не системой, а тем, кто начисляет, то есть ГИБДД) их не отличает! Но, при этом, при написании латиницей и кириллицей считаются разными идентификаторами. Банки это решили запросом данных протокола, из которых формируется идентификатор и переформируют его заново. В некоторых случаях получается правильней чем в квитанции  :lol:Так что, возвращаясь к ГИС ЖКХ, лишний раз проверить, что, скажем, не вбили буквы другого алфавита не помешает.
#
[QUOTE]Sergey Cheban пишет:
Так что увы, строгий порядок нас ждёт только на кладбище (квартал такой-то, ряд такой-то, могила такая-то), а пока мы живём, нам придётся бороться с беспорядком. Так этот мир устроен.[/QUOTE]Увы, в реальности и кладбища далеко не везде упорядочены рядами и кварталами.
[QUOTE]Sergey Cheban пишет:
Если Вы считаете, что эта штука действительно нужная, то попробуйте сами её сделать, а потом продать. Ну или хотя бы прикиньте, сколько времени и людей потребуется на разработку, и сколько экземпляров по какой цене можно продать. Если получается не выгодно, то и государству не стоит этим заниматься.[/QUOTE]Да, считаю что нужна. Федеральных ГИС все больше. В принципе, меня одного хватит, только в одиночку это может затянуться надолго. А вот продавать - смысла не вижу, так как это потянет ответственность за дальнейшую поддержку. Максимум - добровольные пожертвования.[QUOTE]Sergey Cheban пишет:
А написание портабельного кода - дело хоть и не невозможное, но всё же не тривиальное, и граблей на этом пути разложено значительно больше, чем хотелось бы. Тот же __stdcall - не стандарт, а расширение языка, gcc его не поймёт.[/QUOTE]Согласен. Однако, наверняка можно использовать средства, которые понимают.
[QUOTE]Sergey Cheban пишет:
паскаля не миновал[/QUOTE]Прошу простить в таком случае.[QUOTE]Sergey Cheban пишет:
Проблемы с std::string и прочими не-сишными типами в том, что двоичная совместимость гарантируется только тогда, когда всё собрано одним и тем же компилятором с одними и теми же настройками. Обычно двоичную совместимость стараются сохранять в пределах мажорной версии компилятора, хотя даже из этого правила бывают исключения. И нет, конкретно в случае std::string у Вас не будет указателя на таблицу виртуальных методов, потому что эти методы не виртуальные.[/QUOTE]Какой ужас, тогда мне вообще не ясно почему Си++ и более поздние версии так популярны. В любом случае, передавать методы как бы не обязательно, важны данные, в том же дельфи есть тип, в котором в начале длина строки (вариации тоже разные, до 8 байт на длину), потом само значение, для гарантии еще #0 в конце. Все это (и функции работы с ним) можно описать в Unit на Паскале или соответственно в заголовочном файле Си.[QUOTE]Sergey Cheban пишет:
__stdcall как раз и оставит нам интерфейс на голом Си. С небезопасными строками, без поддержки исключений (exceptions), с проблемами освобождения переданной памяти, с проблемами использования из языков, отличных от си-подобных.[/QUOTE]Что ж поделать, если с безопасными такая неприятность из-за двоичной несовместимости.[QUOTE]Sergey Cheban пишет:
Паскаль, насколько я понимаю, застрял в девяностых, и поэтому у него с SOAP проблемы. Но в более современных языках всё уже есть. Либо в виде внешних библиотек, либо прямо в составе языка.[/QUOTE]Что застрял, не отрицаю. Однако с SOAP в целом никаких проблем нет, есть стандартные Unit ("диалекты" Паскаля можно адаптировать, так что насобирать их не проблема). Проблемы начинаются, когда SOAP нужно подписать ЭП вообще (из-за не очень верной каконикализации в стандартных Unit (и даже в старых системных com-объектах), не совпадающей с новейшими каноникализаторами С#, использованными в ГИС), и невнятно определенной стандартом ГОСТ ЭП в частности. С отправкой на веб-сервис тоже не все гладко - модули есть, но в них нужно добавить "вкус шифрования ГОСТ". Итого - Unit, добавляющий к SOAP "вкус ГОСТ", как раз бы пригодился. Реализации этого естественно уже есть на Паскале, но, к сожалению, готового решения не нашел, ни бесплатно ни за деньги. На форумах активно обсуждались проблемы написания, но потом авторы написали и замолчали, на попытки связаться не отвечают. Естественно, можно попробовать перенести с других языков - но для этого нужно знать язык источника и тогда собственно проще писать именно на нем. А библиотека - способ не переписывать весь код с другого языка, а только интерфейсы - это проще.
С другой стороны, смены версий форматов запросов SOAP тоже сильно действуют на нервы и вынести функционал SOAP вне "основного кода" своей ИС в "модуль генерации SOAP" было бы логично. Начать с присвоения хранимым в своей ИС данным неких однозначных имен. Дальнейшие шаги по сопоставлению этих имен с тегами в запросах SOAP не потребуют изменения ИС, а простой смены настроек "модуля генерации SOAP". А вот если понадобятся передавать данные, которых нет в ИС - собственную ИС все равно придется дорабатывать: добавлять таблицы/поля для хранения данных, формы ввода и определять новые имена, но это не так сложно, по сравнению с чтением огромной, меняющейся и частично неверной документации к запросам. И снова в этом случае код  "модуля генерации SOAP" менять не придется, а только его настройки. Если посмотреть шире, то "модуль генерации SOAP" будет в общих чертах одинаков практически у всех. Какой смысл тратить человеко-часы на написание его снова и снова разными разработчиками. С моей точки зрения, библиотека DLL как раз такой способ вынести общий, редко обновляемый функционал вне "основного кода" ИС.
Кроме того, если не ограничиваться ГИС ЖКХ, то, например, СМЭВ требует сохранять все запросы и ответы в базе данных (так порой сделаешь неправильный запрос, обнаружишь тестом, что в нем ошибка еще [U]до отправки[/U], а нет - удалять нельзя даже неотправленный запрос, так и висит как памятник глупости), а это в свою очередь пересекается с импортозамещением баз данных. То есть, по-хорошему, нужна вообще платформа включающая формирование SOAP из XML, подписание, отправку и отечественную базу данных (ясно что это уже не бесплатно, но хотелось бы за приемлемые деньги).

[SIZE=85px][COLOR=greenpt]Отправлено спустя 26 минуты 50 секунды:[/COLOR][/SIZE]
[QUOTE]Sergey Cheban пишет:
По-моему, эта функция находится в личном кабинете на самом видном месте и называется "подключить лицевой счёт". Можно указать номер лицевого счёта и адрес, и подключиться к _чужому_ лицевому счёту, если собственник не запретил подключение.[/QUOTE]Спасибо, попробую. Логично, я эту функцию и использовал, но после выбора адреса - выдало, что у меня нет прав. Правда, номер лицевого я не указывал (и мне интересно как я должен был об этом догадаться). С этим тоже проблема - например, у нас счета одной РСО выглядят вроде "01-1089" (особенность местного разработчика ПО, "01-" это номер УО/РСО), но в квитанции банк пишет просто 1089 и реквизиты компании. У другой РСО счет вида "ЧРТ010111111", в квитанции также, но на их сайте, например, нужно вводить без букв, только цифры. Поэтому я и не стал вводить лицевой счет без дополнительной "наводки" - нужно еще догадаться/подобрать, что РСО указало в этом поле.
#
[QUOTE]two_oceans пишет:
закрытый доступ для разработчиков серверов стоит довольно дорого[/QUOTE]Уточню, что если бы продавал услуги, то купил бы. А для "самообразования" и экспериментов 30-50 тысяч за 1 файл как-то многовато.
[QUOTE]AlcorVol пишет:
Умножает тут, кстати, не моя программа, а сама VFP[/QUOTE]Согласен, я имел ввиду, что сама VFP тоже либо по сути программа либо встраивает что-то в твою при компиляции (не работал, так что не знаю детали, но предполагаю так).
[QUOTE]AlcorVol пишет:
с гарантией - если Byte Order Mark в начале влепишь[/QUOTE][QUOTE]Basil пишет:
Far3 умеет работать с файлами в UTF-8.[/QUOTE]Полагаю, замечание о Byte Order Mark в силе и для UTF-8 в Far3? Если да, то это не очень хорошо - как я уже упоминал, составляю веб-странички из нескольких PHP файлов и, если метка есть и попадает в середину страницы, то браузер всякие фокусы выкидывает. В основном, помогает брать начало файла в теги комментарии, но иногда комментарий никак не влепить.
#
[QUOTE]AlcorVol пишет:
Константин, ты не совсем понял.  У меня ширина окна программы - 80 символов, как в ДОСе. (Хотя высота в строках может быть и переменной.) Если задать шрифт поменьше - то и окошко приложения станет поменьше. Я сам прошу тут VFP окошко перерисовать соответствующим шрифтом => соответствующего размера.[/QUOTE]Кхм, а мне кажется наоборот, ты не совсем понимаешь, что шрифт может занимать на мониторе не столько пикселей, сколько было тобой задумано при создании шрифта. Ну смотри. Твой шрифт скажем 10х8 (к примеру, я не смотрел какие там размеры), то есть 8 пикселей в ширину. Предположим что расстояние между символами 1 пиксель, тогда (8+1)*80=720 (для круглого счета опустим, что после последнего промежутка нет). Пусть программа просто умножила, игнорируя масштабирование, известный размер шрифта на 80 и окно занимает эти 720 пикселей в ширину. Но в Винде, допустим, включено масштабирование 150% и твой шрифт, выведенный Виндой, по факту занимает на мониторе 12 пикселей в ширину, а промежуток стал полтора пикселя (дробное значение сглаживается видеоадаптером, так что края могут ужасно выглядеть). То есть войдет в окно 720/(12+1,5)=53,(3) символа. А если запросить у Винды сколько займет в ширину текст длиной 80 символов с таким-то шрифтом (если не моноширинный, то еще и будет учтена ширина каждого символа в конкретном тексте), она вернет правильное значение (12+1,5)*80=1080 пикселей. От изменения базового размера шрифта не изменится соотношение между реальным размером и базовым размером и входить будут все те же 53 символа. Вот о чем я говорю, что надо проверить запрашивает VFP размер 80 символов у Винды или сам умножает. Конечно, есть еще вариант, что запрашивает размер одного символа шрифта, а потом умножает - в этом случае будет ошибка с промежутками на 80*0,5=40 пикселей и не войдет "всего" 2-3 символа.[QUOTE]AlcorVol пишет:
Клавиша Alt-F7[/QUOTE]Огромное спасибо. Хотя про кодировки остается небольшое сомнение (UTF-8, например, в которой веб-страницы или поиск в Word), но если я ищу в исходном тексте программ, то они почти полностью на английском и все отлично.[QUOTE]AlcorVol пишет:
[QUOTE]Дамир пишет:
дыкть, просто шаблоны распоковать и писать 'как там'... не?[/QUOTE]Дыкть, не так всё просто![/QUOTE]Точно! В частности, в этой реализации на PHP вообще пишется только содержимое ячеек, причем перезаписывается весь распакованный файл в котором значения, ничего из бывшего "до этого" не остается, то есть "как там" нужно будет как минимум либо добавить прямо в своем коде (а если шаблон изменится, то изменить, так что не пойдет!) либо считывать файлы в шаблон и совмещать с новыми значениями.
Кроме того, на самом деле, если мы уже имеем веб-интерфейс, получающий данные для размещения из базы данных УО, то нам и XLSX не очень нужен. Во-первых, (не предусмотрено, но реализуемо) можно хитрым скриптом авторизоваться в ЛК и напрямую заполнить значения форм ручного ввода, сохранить, повторить. Работать конечно будет не очень хорошо, но есть и плюсы - при обычном открытии отображается весь ЛК, но скрипт может вырезать из него только форму отправки и она будет работать намного быстрее. Конечно, все равно придется ставить задержку, чтобы было похоже на человека и не порезало защитой - например, отправка новой формы через 5 секунд. Плюс контроль не вышло ли сообщения что технические работы или страница не найдена. Плюс контроль чтобы не забить данные дважды, но и ничего не пропустить. Во-вторых, (предусмотрено разработчиками) до SOAP рукой подать. Правда, с ЭП там будет "вешалка".
С другой стороны, прелесть PHP в том, что веб-интерфейс на самом деле не нужен - можно запустить PHP файл в консоли, а "параметры запроса" страницы передать в командной строке. Вот тут запись в XLSX бы пригодилась. И раз уж возможны целых 3 подхода из PHP, задумался, не перейти ли на PHP для этого проекта. А для ЭП можно написать расширение PHP (на самом деле, оно уже есть от КриптоПро, но не в открытом доступе, а закрытый доступ для разработчиков серверов стоит довольно дорого).
#
[QUOTE]Programmer пишет:
shortstring[/QUOTE]Конечно они должны иметь одинаковый тип, точнее одинаково описанный. Хм, никогда не было проблем с этим. Ни со своими DLL, ни с системными. Сейчас перепроверю какой тип использовался, насколько помню pchar и все дела. Точнее, совместимый с ним собственный тип pathstr=array[1..260] of char и запись #0 в конце, от которого брался указатель. Что со мной не так? :D Замечу, что это не был объект и соответственно методы работы с ним реализовались независимо на каждой стороне, операторы не переопределялись. Конечно, так работать неудобно.
Другой вопрос, что типы-объекты нужно правильно (ре)конструировать и правильно передавать - просто положиться на среду программирования не всегда получится. Паскаль обычно использует как ссылку на себя внутри объекта (и она передается в метод в регистре процессора, а не через стек) ссылку на [B][U]данные[/U][/B] объекта (а не на начало памяти объекта ) - с одной стороны от нее (адрес в большую сторону, насколько помню) данные объекта, с другой стороны (в меньшую сторону соответственно) - адреса функций и процедур (методы) объекта. Если описание объекта не совпадает (методы и данные не совпадут после передачи) либо если передать ссылку на данные вместо объекта целиком и наоборот (так при передаче адресов методов может не оказаться в объекте на стороне-получателе), то ничего работать не будет.
Поэтому (если не заморачиваться) обычно и нужно избегать передавать объекты. Но, если я реконструирую объект после получения (исправлю адреса методов и поставлю указатель на нужное место), то проблем быть не должно. В этом смысле общее адресное пространство между программой и библиотекой скорее плюс, ссылки на методы должны быть все еще действительными после передачи. Однако, тут важно помнить, что адрес самой DLL может измениться при загрузке библиотеки, и если реализация объекта находится в DLL, то изменится и адрес реализации метода. Поэтому адрес метода нужно не прописывать конкретной цифрой, а импортировать либо находить системной функцией (GetProcAddress) после загрузки библиотеки.[QUOTE]Programmer пишет:
[QUOTE]two_oceans пишет:
[99427]непонятно, с чего начинать[/QUOTE]Из-за этого очень сильные тормоза![/QUOTE]Ну, в смысле, понятно, что можно получить описания схем и их проанализировать на предмет новых полей, изменений формата, удалений полей. Но далее нужно как-то связать с получаемыми из базы данных УО/ТСЖ данными. Пока придумался такой вариант - после обновления документация анализируется и структура тегов вроде [quote:2glc8wxb]... <soapenv:Body>
<pay:importNotificationsOfOrderExecutionRequest base:version="10.0.1.1">
<pay:NotificationOfOrderExecutionType>

<pay1:RecipientInfo>
<org:INN>3436018361</org:INN>...[/quote:2glc8wxb]преобразуется в имя переменной: в начале и конце строки ставится $, имена тегов (можно без пространств имен, но тогда еще отдельно нужно имена пространств передавать и сопоставлять плюс проверять ссылки на них) соединяются точками согласно иерархии, получится строка вроде$soapenv:Body.pay:importNotificationsOfOrderExecutionRequest.pay:NotificationOfOrderExecutionType.pay1:RecipientInfo.org:INN$ (с пространствами) либо $Body.importNotificationsOfOrderExecutionRequest.NotificationOfOrderExecutionType.RecipientInfo.INN$ (без пространств), формируется и где-то сохраняется шаблон в котором вместо значения подставлена такая строка (и так по всем значениям). Можно конечно как-то сокращать имена до $RecipientInfo.INN$ например, а то в shortstring не впишемся, но тогда нужно сопоставлять сокращенные и краткие имена. Зато попутно можно сопоставлять новое положение переменной в иерархии старому краткому имени и это может делать "опытный пользователь", не обязательно программист.
По запросу от библиотеки программа может получить список массив имен нужных переменных (без $), массив их обязательности и версию для конкретного шаблона SOAP запроса.
При формировании из программы передаются два массива строк для формирования отчета - один с именами переменных (без $), другой со соответствующими значениями переменных (значения уже заранее переведены в строку). Функция проверяет, что все переменные заполнены либо остались незаполнены необязательные (если не хватает выдает ошибку и, допустим, массив нехватающих переменных и их обязательность), убирает пустые необязательные и формирует готовый для отправки SOAP запрос, соответствующий новому шаблону.
Результат программа проверяет, что там нет "Продаю имущество имярек за 1 рубль". Можно, например, выводить пользователю для визуальной оценки (если XML плохо смотреть, то можно в библиотеку еще формирование версии для печати заложить на основе переданного XML и данных о стилях полученных из описания новой версии запроса. Чтобы не привязываться к платформе можно записывать html для печати во временную папку и открывать ассоциированным браузером. Либо выводить в самой программе псевдографикой моноширинным шрифтом как у AlcorVol) и ждать нажатия кнопки "Подписать и отправить".
После этого программа передает запрос в другую библиотеку для подписания/отправки вместе с адресом, портом, сертификатом. Как-то так, но это совсем "просто" получается.

[SIZE=85px][COLOR=greenpt]Отправлено спустя 49 минуты 52 секунды:[/COLOR][/SIZE]
Еще подумалось, что можно в библиотеке подписания просто запретить слова из юридических формул вроде "Продаю" "Дарю" "Завещаю" и возвращать ошибку, если текст их содержит.
#
[QUOTE]Sergey Cheban пишет:
Не вижу проблемы. Чтобы подключить лицевой счёт к личному кабинету, не обязательно быть собственником. Достаточно знать адрес и номер лицевого счёта (который, очевидно, должен фигурировать в бумажных квитанциях).[/QUOTE]Что-то я такой опции не увидел. И никаких "наводок" на это тоже. Поищу еще, если получится - премного благодарен.
[QUOTE]Sergey Cheban пишет:
Вообще-то если по уму, то следовало бы требовать подпись и от файлов, передаваемых через ЛК.[/QUOTE]Это да. но раз полагаются на ПЭП Госуслуг, нам проще.
[QUOTE]Sergey Cheban пишет:
Реализации SOAP предлагает не государство, а разработчики[/QUOTE]Согласен, но государство покупает реализации SOAP для центральных узлов СМЭВ - ничего не мешает включить в ТЗ пункт про библиотеку для свободного распространения. Бог с реализацией, но на данный момент каждая ГИС дополняет формат SOAP как в голову придет разработчикам ГИС. Минкомсвязь могло бы утвердить правила, уточняющие как именно дополнять стандарт - в какое место файла располагать ЭП, как стандартно указывать отправителя/получателя и тд. В конце концов, Little Endian или Big Endian использовать в кодировке ЭП. Это явно задача государства, а не разработчиков, которые реализуют только один вариант, но при этом никто не может внятно объяснить, почему нельзя по другому- в ГОСТ это не указано. Тем не менее, другой вариант возвращается с ошибкой - "Неверная ЭП".
[QUOTE]Sergey Cheban пишет:
С ними - ровно те же самые проблемы, что и с виндовыми dll. И по тем же техническим причинам.[/QUOTE]Конечно, но это другая платформа, то есть привязка к Windows - мнимая. Тот же код программы, который напишете на Си будет скомпилирован и упакован в разный формат исполняемых файлов для разных операционных систем.
[QUOTE]Sergey Cheban пишет:
Деньги давать не пробовали?[/QUOTE]Что это изменит? Качество вряд ли будет выше пропорционально сумме. Другой вопрос - кому? Реализация SOAP в ГИС довольно неполная и кривоватая, нет никакой гарантии, что другая неполная же реализация других разработчиков совпадет "по кривизне" и будет работать. В магазине Вам тоже могут предложить Столичный хлеб, когда вы пришли за Бородинским. Даже если с одной ГИС будет, хотелось бы универсальную библиотеку для всех федеральных ГИС. А если тем же, кто разрабатывал ГИС, то их компании и так уже заплатило государство (а государство это взяло из налогов и штрафов, то есть с нас с Вами в том числе) и совершенно немалые суммы. Честно, меня просто жаба задавит [B][U]добавлять[/U][/B] к тем суммам.[QUOTE]Sergey Cheban пишет:
Разные языки программирования - это причина существования в компиляторах от MS ключевых слов __stdcall и __cdecl.[/QUOTE]Знаю. Я в это когда-то вникал и смогу вызвать функцию, хотя возможно это займет время, чтобы разобрать код на Си и подобрать аналогичное описание объекта на Паскале. Либо подключить другую библиотеку того же языка, реализующую этот объект - если не вникать как объект устроен, а просто скормить, что передали и получить, что нужно либо наоборот. Как правило ключевые слова меняют порядок аргументов, так что для функции с одним аргументом мало что изменится, пример неудачен.
(я таки на Си не пишу, но немного разбираю, char * - указатель на буфер сразу, std::string &d вроде бы указатель на объект из которого еще надо получить указатель на буфер через c_str и длину через length/size, в этом смысле достаточно каким-то образом реализовать или подключить c_str и size. Скорее даже не так - объекты обычно хранят указатели на реализованные методы объекта, то есть достаточно найти в объекте нужный указатель на уже реализованную функцию c_str и узнать как ей передать объект). В общем, я не так хорошо знаю Си, а Вы похоже вообще не знаете Паскаль, примеры тут бессмысленно обсуждать.
Для информации - в Паскале таких ключевых слов тоже с десяток, включая вышеназванные - это раз. Если ни одно не подойдет, то никто не отменял возможность сделать "оберточную функцию" и вставить в код на Паскале операторную скобку asm .. end  и написать внутри код ассемблера для передачи параметров и вызова импортируемой функции - это два. Конечно, при этом вся типизация коту под хвост и возможны ошибки. Но, надеюсь Вы не считаете, что разные языки для передачи параметров компилируют какой-то иной машинный код, несовместимый с ассемблером под ту же архитектуру процессора? Можно еще проще, просто используем stdcall - большинство языков умеет работать с системными библиотеками. Итого: остается просто описать заголовки (ну или оберточные функции) на нужном языке, а проблема не стоит выеденного яйца - решаем один раз, потом миллионы раз вызываем функцию.
[QUOTE]Sergey Cheban пишет:
Да и у MS регулярно находят проблемы.[/QUOTE]Да и большая часть из них именно переполнение буфера, то есть по сути именно memory corruption. Это именно болезнь языка Си и прямого использования char * - даже хотя есть вариант функций с указанием размера, многие даже в Майкрософт на это плюют и используют функции без ограничения размера либо неправильно вычисляют ограничение. В Паскале все жестче - например, обычный string (shortstring в моей IDE) ограничен 255 байтами и (используя стандартные функции, без обращения к символам по номеру и махинаций с указателями) 256-ой записать невозможно в принципе - при любой записи берется минимум из ограничения и ожидаемого размера данных. Конечно, 255 байт откровенно сказать мало, но тут ничего не мешает найти исходник встроенного типа по образцу сделать собственный тип скажем на 10 мегабайт и тоже жестко вшить в него ограничение.[QUOTE]Sergey Cheban пишет:
Пока не решены проблемы с интерфейсами, не вижу смысла это обсуждать.[/QUOTE]Учитывая, выше про stdcall, не вижу проблем. Интерфейс всегда можно доработать, если Вам удобнее получать строчку в std::string чем в голом char * то это предмет переговоров о включении дополнительной "оберточной" функции. Либо мне тоже std::string понравится и я портирую объект на Паскаль. Но тут как раз может вылезти что объект не такой уж и std (стандартный), а отличается в разных Си.[QUOTE]Sergey Cheban пишет:
Технически - такие же. Юридически - нет: если нет DLL, то техподдержка ГИС ЖКХ избавляется от разговоров про эту DLL.[/QUOTE]я и не говорил, что это именно техподдержка ГИС ЖКХ будет по DLL по SOAP работу вести, так как федеральных ГИС много, и желательно общую библиотеку. Есть ситуационный центр электронного правительства. Как вариант, сама компания-разработчик библиотеки. А вот конкретно по библиотеке отчетов для ГИС ЖКХ, там конечно техподдержка этой ГИС и тут все понятно (в смысле наоборот непонятно, с чего начинать).
#
[QUOTE]Александр7272 пишет:
[QUOTE]alik пишет:
компания потеряла все данные за 5 лет и лишилась 30000 руб.[/QUOTE]
Решением для данного вопроса является - регулярное копирование базы, с переносом копии на внешний носитель, можно в тоже облако. В итоге потеря будет не за ... лет, а за период до последнего копирования.[/QUOTE]Все правильно, однако, например у нас где-то 16 баз 1с (4 организации, бухгалтерия и зарплата на каждую плюс еще предыдущие варианты редакций платформы 1с), архивация 15 раз в неделю и объем получается весьма приличный - никаких внешних носителей не напасешься каждую копию сохранять. Частично сохраняем конечно, но большинство копий удаляется через месяц либо при смене версии платформы. С другой стороны, это и плюс - можно восстановлением данных откопать удаленную копию, которую вирус просто не увидит. Ну и можно начать с того, чтобы почта приходила (и вложения открывались там, печатались оттуда) на виртуальный компьютер (xp mode например), с которого нет доступа к базе 1с и файлам физического компьютера, зато есть нормальный антивирус. Еще есть вариант с AppLocker/политиками - запретить выполнять скрипты вообще или разрешить только из определенной папки, в которую доступ "только чтение". Про очевидные меры вроде убедиться что база данных и удаленный рабочий стол и веб-интерфейс 1с не слушает на внешнем айпи и пароли поставить сложнее чем "123456" не стану расписывать.
#
[QUOTE]AlcorVol пишет:
шрифт поменьше станет. А вместе с ним - и окошко.[/QUOTE]Ага, но снова не факт что все войдет, так как размер окна тоже пересчитается. Впрочем, я полагаю, что VFP все же достаточно умен, чтобы спросить ширину текста с учетом всех масштабирований у системы и тогда никаких проблем. Однако протестировать лишний раз не помешает.
[QUOTE]AlcorVol пишет:
Если просто файлы/папки/текст - то лучше в FAR'е искать.[/QUOTE]Да, походу Far это наше всё. Обычно я там только шестнадцатеричные коды смотрю, когда форматы файлов подбираю, но видимо надо снова вспоминать и использовать по полной. Тогда, 1) какой смысл тратить процент системных ресурсов на службу индексирования и службу отслеживания файлов; 2) как искать в Far и в частности по тексту файлов я пока не разбирался. В одном файле знаю, а допустим по тексту файлов с определенным расширением на всем диске, включая поддиректории - нет.
[QUOTE]AlcorVol пишет:
C него же на Hyper-V загружаться?[/QUOTE]Если нужда припадет, то можно и с другого гипервизора виртуальных машин. Родные - VirtualBox и Hyper-V. Там я перечислял функции семерки Про, но практически уверен, они есть и в десятке. Вот, нашел - Hyper-V в 8 и 10 по умолчанию выключен, его нужно включить в списке компонентов ОС, убедится что он не затенен серым и перезагрузить компьютер. Нашел [URL=http://www.download3k.com/articles/How-to-add-an-XP-Mode-Virtual-Machine-to-Windows-10-or-8-using-Hyper-V-00770]вот здесь[/URL], там еще есть всякие тонкости (статья на английском). Так как VHD уже есть, то можно начать с пункта "4. Activate Hyper-V on your Windows 10".[QUOTE]serg_p пишет:
вот нашёл на просторах[/QUOTE]Спасибо, глянул беглым взглядом, это реализация записи на PHP, без чтения, сильно упрощенная и не соответствует шаблонам. В остальном, прекрасное решение на случай, когда нужно записать в XLSX огромные объемы данных, выбранных из базы данных по запросу из веб-формы и не нужно беспокоиться о форматах ячеек. В конце концов, можно еще чем-то обработать результат, чтобы соответствовал шаблону. :D
#
[QUOTE]AlcorVol пишет:
VFP использует этот шрифт, отрисовывая окна[/QUOTE]Ага, то есть к WinApi обращается сам VFP. Удобно.
[QUOTE]AlcorVol пишет:
Этот размер вычисляет VFP[/QUOTE]А вот тут могут быть сюрпризы, если и правда вычисляет сам умножением, а не спрашивает у системы. Например, может оказаться, что на мониторе 1600x900 со включенным масштабированием на 150% входит скажем символов 60 вместо 80. С программами "больших корпораций" такого не встречал, а вот "независимые" разработчики вроде меня и тебя вполне могут попасть под такой глюк - в качестве примера программка, которой бухгалтерия набирает данные по зарплате для сбербанка. Внезапно на одном из компьютеров после обновления Windows XP на Windows 7, программка оказалась с исковерканным интерфейсом, при этом на соседнем компьютере с Windows 7 нормально отображается. Для меня такое актуально, потому что начальники отделов и их заместители почти хит-парад устраивают у кого монитор побольше, а потом начинают ныть когда он показывает или слишком мелко или размазано или мерцает на "родном" разрешении (вот это меня "восхитило" - один из мониторов на "родном" поддерживает только 60Гц и видимо мерцает, на разрешениях поменьше 90 Гц и мерцания практически не видно.
[QUOTE]AlcorVol пишет:
 Не очень-то эти стрелки и нужны.[/QUOTE]Конечно, да и сама подсказка тоже скорее дань "ретро", сейчас подсказки в строке состояния и прямо под указателем мыши всплывают. Кстати, а мышь поддерживается?
[QUOTE]AlcorVol пишет:
Обновился до 10-ки в последний день бесплатного обновления, как это и принято на Руси.[/QUOTE]Молодец, успел. В последний день там наверно сервера работали на износ.[QUOTE]AlcorVol пишет:
Но рабочий стол вернули ещё в 8-ке.[/QUOTE]Ага, но главное меню вернули не на все версии и вызвать поиск у меня получается через раз - приходится долго крутиться у правого края экрана.[QUOTE]AlcorVol пишет:
Больших неприятностей при переходе c 7-ки Pro на 10-ку Pro пока не заметил.[/QUOTE]Как по мне там одна большая неприятность :) Если по деталям, я конечно себе не ставил, а на чужих компах глубоко в настройки не лазил, но мне совершенно не нравится как выглядит список программ в главном меню (при этом само меню смотрится замечательно) - ну зачем, вместо удобных подменю все вывалили в алфавитном порядке в меню, да еще и вставили разделители по буквам. В подменю можно было все компактно сгруппировать и прокручивать не приходилось, теперь очень напряжно листать меню с тачпадов, да и с мышью ненамного лучше. На прошлых версиях русские названия менялись с завидным постоянством (не знаю, может на английском названия одни и те же, а чудили переводчики), поэтому я никогда не учил наизусть названия программ, ориентировался на название подменю и смысл ярлыка. Теперь же приходится мучительно вспоминать как же эти (редиски) обозвали ту или иную программу, поиск конечно помогает, но не всегда, потому что ищет тоже по названию. В итоге времени на диагностику/настройку уходит больше, потому что черт его знает куда засунули и как переназвали.[QUOTE]AlcorVol пишет:
 Юзера всё больше за дебила считают.[/QUOTE]Ох, про это я могу говорить очень долго. Вообще лично мне самым комфортным был интерфейс Windows 2000 - стабильно, без "украшательств" и даже [B][U]возможности[/U][/B] их сделать. Теперь вот и к семерке на работе притерпелся, а дома все еще икспи и виртуальная машина с сервером 2000 (держу на случай совместной работы над каким-то проектом - хоть и серверная ос, но оперативки требует меньше чем икспи). На Windows Xp добавили возможность и сразу в это окунулись - понятно надо было ребятам показать что не зря зарплату получали - иначе на XP бы никто не пошел. Одновременно программы поставили перед выбором - поддерживать 2000 без украшательств или XP с украшательствами. Если бы возможность украшать добавили на 2000 и выпускали обновления безопасности - программы бы до сих пор его поддерживали и на следующие версии никто не пошел. Я не отрицаю внутренних преимуществ архитектуры Windows 7 (более стабильный загрузчик, но он и XP/2000 прекрасно загружает; NTFS эффективнее работает с большими дисками - это улучшение[B][U] драйвера[/U][/B] NTFS - при желании могли включить в XP или 2000; поддержка образов - тоже можно, приложив руки, запихать в образ икспи, наверное и 2000 тоже; зато практически убили интерфейс поиска - теперь ищется всякий хлам из папки Windows, не ищется по содержимому например исходников программ или документов Word, если задать ".ini", то точку проигнорирует и найдет кучу файлов с ini в середине; если перейти из найденного в папку, содержащую объект, а потом перейти на уровень выше - вернется к списку найденного, а не к родительской папке; в профиле пользователя понаставили хардссылок - задумка хорошая, но сам проводник по ним, ****, не переходит! они там с ума посходили?), 8 (поиск вроде подправили - но запихнули изощренно; сделали расположение файлов для быстрой загрузки, отображение часов на экране блокировки - непонятно, что мешало это сделать раньше; поддержка на уровне BIOS - на самом деле семерка тоже прекрасно грузится если поставить вместо восьмерки потом вернуть SecureBoot, но зависит от прошивки BIOS и потому работает не везде) или 10 (обязательная подпись драйверов и неотключаемые обновления - задумано вроде неплохо, но по факту больше проблем), но если посмотреть на список возможностей максимальной редакции (да хотя бы и профессиональной), то сомневаюсь что 90% пользователей вообще знают, что эти названия означают, а из тех кто знает половине они вообще не нужны - единственные полезные функции - поддержка домена и редактор политик, эмулятор икспи, сервер RDP, в максимальной еще AppLocker (правда я его все никак не настрою). Остальное: BranchCache, BitLocker, многоязычный пользовательский интерфейс, поддержка нескольких физических процессоров, подсистема запуска Unix приложений и так далее не используются, зато за них берут деньги. А значит и от того, что их обновляют и улучшают простому пользователю ни тепло ни холодно. Все что нужно, можно было включить еще в windows 2000. Сервера правда все равно пришлось бы обновлять, там действительно есть кардинальные улучшения. Но корпоративный сегмент и сервера от обычного пользователя очень далеки.[QUOTE]two_oceans пишет:
то плитками замостят[/QUOTE]Не то чтобы мне не нравились плитки сами по себе, но это мне сильно напоминает как раньше продвигали Active Desktop во времена windows 98 и Windows 2000 - типа можно скрыть ярлыки, зайти прямо рабочим столом на страничку сайта (то есть смотреть курсы валют, погоду и тп прямо на рабочем столе), а еще только на нем можно было поставить картинки в JPG. Но что-то не припомню случаев, когда кто-то действительно скрывал значки ради просмотра погоды. Даже JPG простые пользователи сохраняли в BMP и прекрасно ставили картинку, игнорируя "замечательный" Active Desktop. На XP стали поддерживаться JPG в обычном режиме и про него перестали вспоминать вообще. На 7 ввели поддержку виджетов и на них откликнулось гораздо больше пользователей - по сути почти у всех одно и тоже, что предлагали на Active Desktop: часы, погода, валюты, но без скрытия значков. Минус - виджеты потребляют много ресурсов и частенько слетают. В 8-10 все это переехало на плитки и наверняка потребляет немало ресурсов. И не отключишь насовсем, так как это теперь основной интерфейс. Прям передергивает когда вижу на плитках содержимое каких-нибудь новостных сайтов, Office 365, магазин Майкрософт или вход через единую учетную запись Майкрософт. И все разного размера плюс перемещивается при удалении плиток.[QUOTE]AlcorVol пишет:
Но, действительно, слегка бесит, что по ночам комп может проснуться без спросу для обновления.[/QUOTE]На сколько я знаком с 10, должно быть минимум два способа с эти бороться - 1) отложить обновления (при этом там настораживающая приписка, что отложить можно максимум на год - потом видимо каааак постааавит) и запускать обновление вручную (варианта совсем отключить в 10 не показывается, может быть сработает, если в реестре поковырять способом для предыдущих ос); 2) настроить другое время для автообновления - но это тоже мало приятного, включаешь например утром, с настроем поработать, а комп пишет - подождите, ставятся обновления. Сразу первая мысль - отключить обновления вообще. И хорошо, если они нормально установятся, а ведь много случаев когда на семерке вылетал синий экран или отказывала подсистема Wow64. В общем, тема не о том, надо завязывывать с оффтопиком.
#
[QUOTE]AlcorVol пишет:
ДОС-овское приложение - это не обязательно чёрно-белый экран консольного вида.[/QUOTE]Это я понимаю, IDE Free Pascal практически так же выглядит, но там консольное приложение. И еще двойная рамка псевдографикой по краю окна. Просто не ожидал, что в Windows цвета тоже перенесешь. Как-то я никогда не задавался вопросом, но без обращения к WinApi (создание кисти определенного цвета либо кисти из системной цветовой схемы, применение ее к фону/шрифту и тп) не представляю как задать цвета. [QUOTE]AlcorVol пишет:
 Какие проблемы - с растровыми-то шрифтами?[/QUOTE]Значит, не тот случай. Тут Windows шрифт использует и рисует? Мои сомнения больше относятся к случаю, когда программа сама шрифт по пикселям рисует. В одном из старых журналов видел программу как это сделать - и в Досе все отлично, так как можно напрямую обращаться к видеопамяти и "зажигать" нужные пикселы. А в Win подозреваю будут жуткие тормоза либо придется с DirectX возиться.[QUOTE]AlcorVol пишет:
1280х1024  в Win 10[/QUOTE]Замечательно, полагаю проблем нет, если шрифт рисует Windows и ширина(высота) окна тоже определяется системной функцией (в смысле, сколько данные 80 символов займут пикселей на экране).[QUOTE]AlcorVol пишет:
Ну, и вот - картинки.[/QUOTE]"Выберите действие клавишами" - кажется, клавиши в шрифте не прорисовалось.[QUOTE]AlcorVol пишет:
Думаю, что такое ретро скоро снова на пике моды будет.[/QUOTE]Хорошо бы, но пока все какие-то "инновации" и "украшательства"- то плитками замостят, рабочий стол уберут, то автообновят на следующую версию ночью. Интерфейс все больше ориентирован на детей - крупные и яркие значки, автонастройка практически всего. Автонастройка это конечно хорошо, но кое-что я бы даже и не стал настраивать потому как функции вообще мне не нужны и, отключив,сэкономил бы немного ресурсов. Про графику игр вообще диву даюсь - системные требования растут катастрофически. Теперь уже каждая игра считает должным тащить минимум 5-10 Гб текстур. Раньше драйвер весил 200 Кб, теперь чтобы поставить некоторые драйвера нужно скачать еще 300 Мб - всяческие фреймворки и тому подобное. Фреймворки задумывались как средство уменьшения размера программы, но сейчас это перевернулось с ног на голову. Так что не знаю, не знаю, доживем ли. Может это ретро будет в моде при наших внуках, когда грянет какой-нибудь апокалипсис и всем временно станет не до "украшательств".
#
[QUOTE]AlcorVol пишет:
Win-1251 - не русская, а кириллическая кодировка. Учитывает одновременно русский, украинский, белорусский, болгарский, сербский и македонский алфавиты.[/QUOTE]Примерно так и предполагал: для расширенной латиницы наверно 5 разных кодовых страниц сделали, а для кириллицы зажались и сделали одну. Больше всего свободных мест в греческой, хотя казалось бы символы с древних времен и похожа на все понемногу.[QUOTE]AlcorVol пишет:
И решение такое я нашёл.[/QUOTE]Спасибо, порадовал! Изящное решение, но с трудом представляю внешний вид. То есть в программе виндовское окно с серым(белым) фоном, а в нем еще текстом нарисована рамка и прочие элементы управления - поля ввода, списки, а сам текст моноширинным шрифтом? Это конечно вариант, но как-то странно должно смотреться среди оформления Windows :) В первую очередь вопрос по быстродействию отрисовки. Во вторую, как оно выглядит на Win 7 с новейшими мониторами и включенным масштабированием. Не так давно видел программу, которая не масштабируется, но говорит Windows 8 что все ОК, перемасштабировать не надо. В итоге размер окна на родном разрешении монитора примерно с пластиковую карту и приходится ставить 1024x768, чтобы разглядеть что-то кроме меню и заголовка (их Windows увеличивает).
У меня такой задачи не стояло - рисование псевдографическими символами прошло стороной. Я бы наверно сделал по-другому, так как у меня другой язык и другая IDE - унифицировал параметры функции, выводящей элемент управления (скажем, поле ввода) шрифтом для DOS (на Паскале есть стандартный Unit) и стандартным элементом управления в Windows (по образцу досовского Unit). Далее подставил разные циферки при формировании окон (на Паскале есть управляющие комментарии для компилятора - то есть сама программа вообще может не проверять в какой среде работает, можно из одного текста сделать несколько версий в зависимости, какие условия передать при сборке, и распространять разные версии для разных сред). Конечно "малой кровью" не назовешь (кроме внешнего вида, стандартные элементы Windows по другой логике работают), но и выглядеть будет по-разному из одного исходника.
[QUOTE]AlcorVol пишет:
Во-вторых, собственноручно разработал семейство растровых шрифтов разных размеров для правильного отображения символов этой кодировки на экране.[/QUOTE]Вот это мне очень интересно. Очень давно есть проблема с отображением кириллицы на синем экране смерти Windows XP. Конечно обычно там стандартный текст и я его уже практически выучил и ориентируюсь на код ошибки, но у некоторых ошибок есть отличия в тексте. Как я понимаю это как раз должно решаться заменой файла шрифтов bootfont.bin Однако нормальной версии вроде бы не нашел и с чего начать ковырять формат тоже непонятно. С Win 7 проблема решается по-другому - в загрузчике указать RU-ru.
#
[QUOTE]AlcorVol пишет:
Хотя и Википедия тут подошла бы. Достаточно часто обновляется.[/QUOTE]Ну нет, Википедия незаменима как источник когда вообще ничего о каком-то явлении/понятии не знаешь, но когда надо какую-то мелочь [B][U]абсолютно точно[/U][/B] узнать, она не авторитет. Спасибо, хотя юникод орг тоже как-то с натяжкой - "Date: 04/15/98", мягко говоря устарело. И это стандарт для преобразования из 1251 в Юникод, а не сама 1251. Норматив от Майкрософт (2014 года или новее, после включения символа рубля в Юникод) был бы убедительней. Я бы вообще выкинул из 1251 символы вроде #CYRILLIC SMALL LETTER LJE, которые в русском не встречаются.
#
[QUOTE]МихаилИгоревич пишет:
Готов частично профинансировать разработку веб сервиса для 1с, а также выступить разработчиком ТЗ.[/QUOTE]1c это немного другое, там специфический Visual Basic с русским акцентом. Конечно это достойно отдельного обсуждения, работающих в 1с немало и есть платный модуль для гисгмп, так что есть с чего начать. Кстати, модуль для ГИС жкх вроде бы тоже есть, в соседнем разделе обсуждали как замечательно все синхронизируется с 1с, но кажется выгрузка-загрузка вручную. Вот [URL=http://www.forum.mista.ru/topic.php?id=780234]тут[/URL] начали что-то делать по автоматизации, но похоже пока не очень-то ладится и им посоветовали тоже сделать сервис на C#. Я за 1с не возьмусь - так как там специфическое обновление форм и как представлю что это все править после каждой смены версии форматов гис жкх, становится дурно.
Теоретически,если все же сделать DLL автоматической смены  отчетов, можно подумать как прикрутить к 1с. Пока что проектирую DLL для обертки и отправки уже готовых данных, до подготовки самих отчетов еще не скоро дело дойдет.
#
[QUOTE]AlcorVol пишет:
Ну, если не нравится ¤, [/QUOTE]Дело-то не в том, что нравится или не нравится, а чтобы совпадало с официальным от Майкрософт, а то получится не очень хорошо. Вот где смотришь официальную страницу?
[QUOTE]AlcorVol пишет:
Насколько мне известно, в 1251 только одна пустая позиция - #98. И она ничем не занята до сих пор.[/QUOTE]я смотрю через вот такой файлик, в который выведены последовательно все коды символов с #20 по #FF просто в Блокнотe, шрифт Lucida Console и вижу следущее: На всякий случай проверил основные шрифты использующиеся в Office: Arial, Times New Roman, Tahoma, Calibri, Courier - везде одно и тоже. Странно, похоже #98 вообще пропускает и показывает символ торговой марки со следующей позиции. Правда последнее обновление шрифтов, вышедшее в этом году не установлено - там тоже добавили символ какой-то валюты. Поэтому меня тоже удивило заявление, что в официальной есть свободные места, на рисунке их реально было с десяток. Сейчас искал, пока нашел только такую же как у меня в Блокнтое, но с подписями кодов Юникода:

[SIZE=85px][COLOR=greenpt]Отправлено спустя 14 минуты 37 секунды:[/COLOR][/SIZE]
[QUOTE]AlcorVol пишет:
И как раз такие-то последовательности неплохо было бы "нормализовать" - особенно, при работе со всякими Гос.ИС.[/QUOTE]Согласен.
[QUOTE]Basil пишет:
XML, состоящие из одной длинной строки, приходится предварительно расставлять CRLF [/QUOTE]Собственно, в других программах сравнения не лучше. В ряде случаев расстановки CRLF нужно избегать, например к "нашим баранам" SOAP, это сломает каноникализацию (****, еле выговоришь) и проверку ЭП, там допустимы только LF и в файл на отправку нужно писать именно полученный при каноникализации текст. Но это наверно напишу подробно в другой теме, не будем тут обсуждать.
#
[quote:2ry8c0t6]это нужно для жителей[/quote:2ry8c0t6]Я уже тут писал, что на данный момент система авторизации на ГИС ЖКХ заслуживает самое мягкое определения "крайне непродуманная". В стране все еще много тех, кто не зарегистрирован на Госуслугах - в основном это пенсионеры. А пенсионеров - треть населения страны. И они очень часто являются формальными владельцами. Итого, минимум треть квартир даже в принципе (не обращая внимание на то, что Росреестр привязывается как попало) не могут зайти и посмотреть, что же там УО внесли.
[quote:2ry8c0t6]SOAP в ЛК[/quote:2ry8c0t6]Это конечно была шутка, забавное преувеличение. но! в каждой шутке как известно только доля шутки. ЭП на файлы передаваемые в ЛК не ставится, кто отправитель заранее известно, так что SOAP от XML практически не отличается в этом случае.
[QUOTE]Sergey Cheban пишет:
Протокол SOAP - открытый. И вот с этой точки - пожалуйста, сами, если можете. А если не можете, то и говорить не о чем. А DLL - это очень, очень плохая идея:Непонятная DLL, работающая с криптографией и имеющая доступ к приватным ключам - это не безопасно.DLL привязывает нас к платформе Windows.Интерфейс, предоставляемый DLL - это чистый C. Даже не C++. Работать с ним из современных языков программирования неудобно.DLL выполняется в адресном пространстве чужого процесса. Если в результате процесс падает, не всегда понятно, по чьей вине это произошло. Нет внятного разграничения зон ответственности.В DLL наверняка были бы ошибки. Распространение DLL с исправлениями этих ошибок - задача нетривиальная.[/QUOTE]По пунктам:
1) Более половины реализации SOAP одинаково не только в рамках ГИС ЖКХ, но и вообще всех российских ФГИС (все что вне Body по большому счету описано SOAP, отличий не так уж много). То есть что разработчиков множество это плохо, а что государство не предложит единую реализацию SOAP, на которую могли бы ориентироваться те же разработчики будущих ФГИС, это нормально - как хотите так и плывите. Правильно Вас понимаю?
2) небезопасно, согласен. Но все криптопровайдеры тоже в своем составе имеют DLL, естественно подписанные и сертифицированные ФСБ. Им вы доверяете? И при этом лично звонили проверяли подлинность сертификата? Ну и прекрасно, используем их.
Собственно для данной DLL (обертки XML в SOAP, добавление подписи, отправки SOAP на сервер ГИС)  нет необходимости работать с приватными ключами напрямую (даже скорее посторонняя функция, зачем изобретать велосипед и реализовывать криптографические примитивы) - можно вычислить необходимые значения либо через сертифицированный криптопровайдер (который, "зараза", формирует cades-bes в отсоединенной ЭП файла, но тем не менее сам не умеет формировать xades-bes внутри XML) либо через сертифицированную версию OpenSSL (как рекомендуется в статьях на хабре). Плюс цифровая подпись DLL, что ее никто не изменял и она сама ключи не ворует. Понятно, если бы библиотека была подписана подписью ГИС ЖКХ или КриптоПро к ней было бы больше доверия, чем к "левому" разработчику, потому и просим.
Естественно, будет ли пользователь использовать сертифицированный криптопровайдер, сертифицированные бинарные файлы OpenSSL (и платить денежку) или общедоступные несертифицированные или соберет свою сборку - остается на совести администратора информационной безопасности организации пользователя. Нет смысла "не выпускать джинна из бутылки" - кто захочет несертифицированный, сделает и по тем статьям на хабре.
3) На Linux есть аналог DLL - SO библиотеки. Если компилятор кроссплатформенный, то сделать библиотеку для Linux примерно так сложно как передать параметр TargetOs и ссылки на библиотеки взять в управляющие комментарии (в кроссплатформенных компиляторах как правило уже есть билды стандартных Unit с использованием библиотек поддерживаемых операционных систем, нужно только Unit собственного сочинения перестроить под них). Тем не менее, у меня, например, нет планов поддерживать библиотеку на *nix системах, так как у меня нет возможности составить корректные представления о криптопровайдерах на *nix и написать соответствующие Unit.
4) Здравствуйте, при всем уважении, а кроме семейства Си языки какие-то знаете? У меня например мои все DLL на Паскале. Главное, что бы формат параметров можно было описать на любом языке - неважен язык программирования разработчика DLL. Это дает огромное преимущество по сравнению с проектами которые все делают именно на C# или Java. Не считая отсутствия громоздкого dotNet. Это компенсирует некоторые неудобства. Написать объект на вашем языке программирования когда уже есть реализация кода объекта в виде отдельных функций DLL  тоже простая задача - все основные функции операционной системы Windows как раз содержатся в DLL, тем не менее работаете с ними через объекты.
Если же Вы имеете ввиду ООП при работе самой библиотеки, то огромное количество COM объектов как раз используют фабрики экземпляров в виде DLL и OCX TLB (расширение не особо имеет значение - по сути это тоже внешний исполняемый код, подгружаемый программой). Но COM объекты как раз и привяжут нас к Windows. dotNet полагаю тоже?
5) Ошибки есть везде и зона ответственности не разграничена, согласен. Но посмотрим, в среднем процессе Windows 7 вовлечены более чем 100 библиотек - не потому что разработчик программы их все загрузил, а потому системные и околосистемные библиотеки тянут за собой огромное количество зависимостей. В этом смысле, если добавится еще одна библиотека, погоды это не сделает. Для этого есть современные средства отладки собирающие данные активности на момент сбоя во всех потоках процесса. Определить, что вылетело при выполнении такой-то функции - на раз.
Тут хочу высказаться о языке программирования, на котором сделана библиотека - компиляторы Паскаля как раз славятся тем, что при загрузке модуля (будь то программа или библиотека) сразу же запрашивается память у системы "про запас", не через getmem, а как еще один сегмент наряду с кодом и данными (в них сразу записаны значения) - сегмент "кучи" (значения не записаны, заполнен "мусором" из оперативной памяти). По умолчанию это 8 мегабайт, мало по нынешним меркам, но на хранение результатов криптооперации - с головой хватит. Заранее объявленные глобальные переменные сюда не входят - один раз была нужда и объявил глобальный многомерный массив, потянувший на гигабайт - и все это скомпилировалось в сегменте данных. Если памяти не хватит библиотека не загрузится вообще и будет ясно - вывалилось до загрузки библиотеки и обработать это корректно задача использующей программы. Если память есть, то все загрузится и пока запас не исчерпан, никакой дополнительной памяти у системы не запрашивается и всю обработку правильности использования памяти в сегментах ведет стандартный код, вставленный компилятором. То есть со внутренней "кучей" можно что угодно делать - это повлияет на корректность работы библиотеки, но на работоспособность программы, использующей библиотеку, и системы это не повлияет. Хотя конечно памяти потребляет больше, по сравнению с запросом и освобождением у системы памяти для каждого объекта, но так надежнее.
С использованием данных, переданных основной программой гораздо сложнее, но и тут можно подстелить соломку, проверяя все указатели системной функцией (IsBadReadPtr IsBadWritePtr кажется - для своих программ не делал, но если распространять библиотеку, то нужно делать), как это делает само ядро операционной системы, и возвращая код ошибки "неправильный указатель", если проверка не пройдена. Лезть в память программы, если библиотеку об этом не просили и не дали правильный указатель - заведомо ошибочное дело, нет разницы в одном мы адресном пространстве или в разных.
6) проблемы обновления DLL абсолютно такие же, как и у программы, а именно - что заменить файл модуля, который запущен в данный момент, мягко говоря, непросто. Плюс при этом нужно убедиться, что замена не испорчена, а то и подписана ЭП. Проще в том плане, что объем библиотеки мал. Апплеты панели управления с расширением CPL - все те же DLL, но написанные по определенным требованиям и выводящие пользователю диалоговые окна. В том числе среди них есть такие, что реализуют функцию обновления какой-либо программы. Есть и другие средства решения: например можно функцию обновления вызывать в самой DLL при инициализации. Либо экспортировать функцию обновления отдельно, а в комплекте распространять  bat файл, запускающий rundll32 для загрузки библиотеки и выполнения функции.
[QUOTE]Sergey Cheban пишет:
3. В каком виде должна быть ЭЦП? Как она должна отделяться от данных?[/QUOTE]Насчет этого - никаких проблем, просто ЭЦП должна быть отсоединенной, в виде отдельного файла с расширением sig. Заметьте, в ту же налоговую (и из нее тоже) передается отсоединенная ЭЦП. Еще краем уха слышал, сейчас можно подписать VBScript, тоже по сути текстовый файл, в подробности не вникал пока. С остальным соглашусь, формат должен быть описан точно.
[QUOTE]Sergey Cheban пишет:
Да и присутствие на рынке _множества_ разработчиков мне кажется вредным для дела.[/QUOTE]Это конечно так, однако вот так посмотришь что в одном регионе "горячее водоснабжение", в другом "подогрев воды" и так далее и тому подобное. Программа, учитывающая все нюансы будет огромной и соответственно пропорционально количеству кода возрастет количество ошибок. Собственно именно это и видим на примере ГИС. Хотя наверно тоже можно поделить на библиотеки :D
#
Вообще молодцы, даже в выходные исправляете.
По кодировкам Юникода конечно много где можно прочитать - но если думаешь, что перекодировать 33 буквы русского алфавита достаточно (32 последовательно и Ё отдельно), то это не так. Некоторые умудряются Ё и Й кодировать соответственно как (Е и точечки отдельно) и (И и крышечка отдельно). В своей программе синхронизации файлов... (знаю, таких программ миллион, но наши пользователи их в ступор вгоняют - полный путь к файлу может превышать 260 символов, например, был 254 символа, в том числе 150 символов название самого файла, потом создали папку на верхнем уровне "архивы 2015" и перенесли папку с файлом туда - в итоге Word такой документ через раз открывает, а остальные программы не могут даже скопировать, у "любимого" Экселя наоборот - выяснилось ограничение в 212 символов в какой-то побочной технологии и файл замечательно копируется, но не открывается, Эксель говорит "не найден") Так вот в программе наткнулся на файл с таким Й, видимо сохранили из интернета страничку с таким И+крышечка символом - программа на этом месте крепко зависла. Так что с [B][U]чужим[/U][/B] Юникодом глаз да глаз.
[QUOTE]AlcorVol пишет:
Oh, yes! Правда, VFP к этому как-то не очень приспособлена. Проблем будет куча. И кстати, имена листов уже кто-то там в 1251 перекодирует. Я бы предпочёл в 1251 работать. Для ГИС ЖКХ - точно будет достаточно того, что есть. Особенно, если Рубль добавить.[/QUOTE]Если честно, то от однобайтных кодировок лучше отказываться где только можно. Главное себя заставить и планомерно переходить - это тоже своего рода подстилание соломки. Все (или почти все) странички я уже перевел на utf-8. Отправной точкой стал переезд сайта на _общеизвестный хостинг_ - там просто для всех страниц сервер выдает что они в utf-8, так как админка в utf-8. И это проблема сайта, если остальные страницы по факту в другой кодировке. Можно указать вторую в самой странице, но половина браузеров все равно покажет "крокозябры". Сначала тоже было больно - в текстовых файлах в начале строит символ кодировки utf-8, браузер корректно пропускает его первый раз. Но если включать несколько файлов в страничку, то символ встретится в середине и у браузера будет "разрыв шаблона", выдаст ошибку или сдвинет все оформление страницы на высоту 1 текстовой строчки. Ничего, написал программку, убирающую символ. Теперь все файлы что содержат кириллицу перекодирую. Для сохранения в БД местами осталось win-1251 (так вручную проще смотреть/исправить и слишком много места занимает utf-8).
С EXE-программами конечно сложнее - win-1251 как переходная к utf-8 сохраняется, но между win-1251 и utf-8 пока перекодирую только кириллицу и некоторые специальные символы. Если [U][B]моя[/B][/U] программа при этом работает с win-1251, то прочие символы просто не использую и игнорирую. Если же другие символы используются - то вся работа программы в utf-8.
[QUOTE]Basil пишет:
И если в исходном файле в строке есть символ #A4, при записи он преобразуется в символ рубля, хотя это не требовалось.[/QUOTE] Вопрос: #A4 на основании чего выбран? это официальный код для рубля? В смысле Майкрософт тоже его использует в win-1251? Смутно помню, когда только добавили символ рубля, его поместили на одно из "свободных мест" (ранее не занятых) в официальной win-1251. Меня тогда удивило, что свободные места есть. Поэтому смущает замена символа валюты на символ рубля. Либо символ валюты был ранее неофициальный, либо у символа рубля другой код в официальной версии.
[QUOTE]AlcorVol пишет:
Если бы дела обстояли именно таким образом, то на одном ПК (и тем более, в одном и том же документе) нельзя было бы указывать денежные поля с разными валютами. Странновато и примитивно как-то... Не верится просто.[/QUOTE]Мне тоже не верится, скорее всего где-то еще указывается "маскировочный" символ, но допускаю, что если он там явно не указан, то значение берется из локали системы.[quote:2xvhfzp3]WinMerge[/quote:2xvhfzp3]Спасибо, попробую. Обычно использовал консольный diff из FreePascal (но там есть некоторые неудобства, например, оператор конца предыдущей функции показывает в добавленном блоке, а оператор конца добавленной функции соответственно не показывает), и набросал необходимое для своего аналога, но не написал.
#
Просмотрел PRG - много всего, есть именованные диапазоны и даже PageSetup. Из того, что бросилось в глаза - импортируется Sleep, этого всегда стараюсь избегать - в зависимости от реализации Sleep может вызывать 100% загрузку одного из ядер процессора. В WinXP+ более правильно - создать "пустое" событие (которое не может наступить) и "ждать" его указанное время функцией WaitForSingleObject.
#
[QUOTE]Basil пишет:
нужно всё-таки поискать описание формата xlxs[/QUOTE] ;) Как в анекдоте прямо: если ничего не помогло - прочитай инструкцию.
[QUOTE]AlcorVol пишет:
Не такой уж мегапроект.[/QUOTE]Согласен, но когда-то все равно придется.
[QUOTE]Basil пишет:
Мне этот пакет не очень нравится, когда-то были проблемы с открытием xlsx. Думаю, проще использовать Libre.[/QUOTE]Я тоже мягко говоря "не в восторге", но скорее откажусь от xlsx в пользу xls, чем перееду с привычного офиса. Первая версия пакета совместимости вообще была ужасна, открывала файлы 2007 Экселя через раз, потом года через полтора стало получше, чего-то допиливают постоянно - теперь уже сохраненные в Экселе 2010 файлы открывает, но это к сожалению не решает основной проблемы конвертера - конвертированный файл в папке temp, имя из цифр и обычное "сохранить" не прокатит - файл просто сотрется при очистке временных файлов, надо каждый раз после конвертирования "сохранить как" и придавать осмысленное имя. Как будто было нельзя cконвертировать в ту же папку где исходный с исходным именем без X.
[quote:1co2mxw1]трёхзначный: E2 82 BD[/quote:1co2mxw1]Неудивительно. Если вкратце, 1 байт UTF-8 нужен на символы Юникода до 007F (они не кодируются, просто отбрасывается байт 00 в начале), 2 байта 0080 по 07FF (кодирует 11 бит), 3 байта до FFFF(16 бит). То есть 3 байта UTF-8 достаточно чтобы закодировать любой символ из UTF-16. Каждый дополнительный байт UTF-8 позволяет кодировать на 5 бит больше (еще 3 бита добавляются в служебные) - максимальное число байт разное в разных версиях стандарта, вплоть до 6 байт (кодирует 31 бит из UTF-32). Служебные формируются так: В первом байте UTF-8 количество бит "1" в начале равно количеству байт в коде символа, далее идет разделительный бит "0". Второй и следующие байты начинаются с "10".
На примере символа рубля в UTF-8, E2 82 BD = [1110] 0010, [10]00 0010, [10]11 1101 в квадратных скобках служебные биты, собираем неслужебные, получим 0010 0000, 1011 1101 = 20 BD (символ рубля в UTF-16).
#
[quote:2bracnn0]Для обсуждения программных решений отдельный раздел есть. ;) [/quote:2bracnn0]Так это.. тогда еще отдельного раздела не было, после того сообщения все и пошло. ;)
[quote:2bracnn0]для оптимизации работы объекты и договоры попрятались,[/quote:2bracnn0]Эта пяяяяяяяяяяять!!!!! Надо на своих сайтах так же сделать, заходит пользователь, а на странице только кнопки Вход и Поиск. :D :D
#
Хех, я говорю что РСО надо договорится между собой (раз все все понимают), а ты - что они сами по себе, и точка. Круг замкнулся.

У нас называется горячее водоснабжение и платится (оба компонента - вода в кубометрах и энергия в гигакалориях) Энергосбыту. То есть Энергосбыт покупает воду для горячего водоснабжения у Водоканала, потом продает оба компонента населению. Я не понимаю, почему у нас так можно, а в Вологде нет? Почему местные Теплосети не могут купить воду у Водоканала? Это такая специальная статья ЖК для конкретного предприятия или их убеждения не позволяют покупать?  :?
Закрадывается впечатление, что УК выгоднее непрямые платежи, поэтому любые варианты прямых (или непрямых не через УК) сразу отвергаешь без рассмотрения. (Шучу.) Тогда конечно, "Подогреву воды" - жить!  :D
Ну хорошо, а что мешает самой УК так сделать? Разве это будет незаконно купить воду у Водоканала, продать населению уже подогретую и запретить прямые платежи, так как вода [B][U]уже куплена[/U][/B] у Водоканала? То есть у УК долг перед Водоканалом, а у населения перед УК.
#
Я имею ввиду, что это работа программистов банка на перспективу. Добавление поля еще не значит, что оно реально работает. Пока что, например у меня, даже нет возможности как гражданину зайти в ЛК и увидеть какой же там ЕЛС и идентификатор ЖКУ присвоили квартире. Потому что, это увидит (может быть, и то есть сомнения) основной квартиросъемщик, а меня ЛК посылает на все 4 стороны - нет прав.
#
[QUOTE]AlcorVol пишет:
Надо как-то сделать, чтобы расхождения не накапливались.[/QUOTE]Да, похоже для командной работы надо git осваивать и github.
#
Да да побольше примеров) Дома у меня стоит Office XP с пакетом совместимости (добавлю, пакет почему то считает, что язык системы - японский) для открытия XLSX. Итак, пакет совместимости вообще отказался открывать пересохраненный файл, выкинул строчку иероглифов. Открыл в Winrar - бросилось в глаза, что многие файлы по объему стали меньше, не говоря про отсутствие нескольких папок (те папки как я понимаю связаны с настройкой печати на принтер). В workbook.xml порезаны объявления именованных диапазонов и еще какие-то отношения с ними связанные. С именованными диапазонами я не особо знаком, но именно в таком расположены данные для списка - то есть список так работать не будет. Их нужно как-то аккуратно обработать чтоб не исчезли. styles.xml тоже ощутимо похудел.
#
Просто замечательно. Хотя мне кажется, что появление таких новшеств никак не связано с ГИС. У нас например, уже года полтора в терминалах пункт оплата ЖКХ, но все знают что по факту пока не работает.
#
[QUOTE]AlcorVol пишет:
[QUOTE]two_oceans пишет:
 Однако мне немного кажется странным, что предлагаешь узаконить именно этот "изворот".[/QUOTE]
Это не изворот.  :) Это - повседневная реальность жизни. У нас в каждый дом не три, а две трубы идут. (Обратки считать не будем.  :) ) Для меня изворот - это как раз "самостоятельное приготовление...".  :)[/QUOTE]Кажется, я пропустил отличия между "Подогревом воды" и "самостоятельным приготовлением". Если так, прошу извинить, на сторонний взгляд что так, что этак. В остальном же, как-то это неправильно, почему обычного ГВС не хватает. Неужели нельзя бойлеры оформить как котельные - вместо котла и топлива - теплообменник. Дескать, такие у нас котельные прогрессивные.
[QUOTE]AlcorVol пишет:
[QUOTE]two_oceans пишет:
Не в обиду будет сказано, но я сомневаюсь, что у Теплосети нет утечек теплоносителя.[/QUOTE]
Ну, при чём тут эти "утечки"? Они есть всегда и везде. Все эти утечки учитываются, когда РЭК утверждает тарифы на гигакалории. А так, схема подачи теплоносителя - закрытая. Он и батареи греет, и холодную воду до горячей подогревает. И уже остывший - обратно на ТЭЦ течёт. Ни в какие краны населения не поступает.[/QUOTE]Готов допустить, что система закрытая - вдруг действительно пар подают. У нас вот не пар, а вода и почти на каждой батарее есть если не кран, то шайба для спуска воздуха, то есть система не закрытая. Технически возможно (хотя и неудобно) набрать воду из батареи.
Я говорил не столько об утечках и замкнутости, сколько о том, что между Водоканалом и Теплосетью уже есть договор (восполнение теплоносителя). Это значит, что изменив пару пунктов в договорах можно всю плату перегонять в Теплосеть и не маяться с "приготовлением или подогревом", они там сами могут рассчитаться и не грузить УО  проблемами.
[QUOTE]AlcorVol пишет:
[QUOTE]two_oceans пишет:
Не обязательно на муниципальном уровне, региональный закон тоже подойдет [/QUOTE]
Как бы не так! Если ЖК РФ не знает коммунальной услуги "подогрев воды", то родить её на региональном уровне невозможно. Это только по Конституции Россия - федерация. А на самом деле - унитарное государство. Почти всё в федеральном центре регулируется и утверждается. Да и ГИС ЖКХ - не лучшее ли тому доказательство? Всё-превсё в одном центре соберём!  :D[/QUOTE]Верно, "подогрев" не родить, потому что нет в исчерпывающем перечне. Но назвать то, что уже есть в реальности "горячим водоснабжением" либо другим подходящим пунктом и подогнать под ЖК наверняка вполне возможно. Неужели в федеральном законе указано в подробностях какие должны быть котельные и прочие мелкие детали? Полагаю, что нет такой точности и изменив детали можно сдвинуть "правовое поле" на котором все рассматривается. Региональный закон как раз может сделать из светло-серого - белое, а темно-серого - черное. Останется поменять с темно-серого на светло-серое совместными действиями организаций.

[SIZE=85px][COLOR=greenpt]Отправлено спустя 18 минуты 43 секунды:[/COLOR][/SIZE]
Вот пример вспомнился немного из другой области - недавно ОМСУ запросили какие у нас тарифы на проезд в транспорте. Фокус в том, что если "регулируемые", то должны быть договора с перевозчиками и доплата из бюджета до экономически обоснованного, а если "нерегулируемые", то ничего не нужно. Доплата естественно не запланирована, так как тарифы равны обоснованным, договоров нет. Но! выяснилось что доплата может быть нулевой! То есть можно заключить договоры и провозгласить что доплата нулевая, а тарифы "регулируемые", а можно не заключать и тогда тарифы "нерегулируемые". Такие законы.
#
Можно мне тоже пример - открытие, вывод слова кириллицей, сохранение? energy-sv <собака> yandex <точка> ru (Да, из своих адресов нашел вот в тему "энергичный", специально добавлю к рабочему почтовому клиенту)
Стили ячеек (цвета, форматы) тоже своего рода отношения: на самом деле Эксель не устанавливает свойства каждой ячейки, а создает стиль ячейки и цепляет к нему список ячеек (ну в смысле наоборот ячейка указывает на стиль, но удобнее понимать так). Возможно именно указание на стиль портится, надо попробовать расковырять до уровня XML. Видимость листов наверно ГИС не принципиальна, но тоже интересный эффект.
#
[QUOTE]AlcorVol пишет:
Вот тут, уважаемый Константин, я с тобой не согласился бы. Жизнь - она хитрее нормативных документов. Никакой "дополнительной услуги" под названием "Горячее водоснабжение" в этой схеме (которая широко применяется не только в Вологде, но - вроде бы - и в Перми, и в Кирове), на самом деле, нет. <...> . Если делать всё по уму, то в ЖК РФ нужно внести изменения, которые допускали бы существование самостоятельной коммунальной услуги "Подогрев воды" в случае отсутствия централизованного горячего водоснабжения. И всё встало бы на свои места.[/QUOTE]То есть половинку услуги засчитать как отдельную. Правильно?
[QUOTE]AlcorVol пишет:
Вот, в том-то и дело, что РСО не хотят, чтобы платежи проходили транзитом через УО. [/QUOTE]
Ну, даже спорить не буду, я не юрист, и изменения законодательства явно нужны на федеральном уровне. Однако мне немного кажется странным, что предлагаешь узаконить именно этот "изворот". Если УО не может предоставлять горячее водоснабжение,   :idea: есть другой вариант решения - бойлеры отнести в ведение Теплосети, тогда схема будет как во всех остальных регионах и для одного из двух РСО будет как они хотели - прямые платежи. Итого - решение проблемы своими силами, не ожидая федерального законотворчества.
Например, мы платим Энергосбыту за ГВС (и за "нагрев" и за саму воду, в квитанции указаны оба компонента). (К слову там же и за отопление и за электричество - без бутылька не разобраться - уже привыкли, что за электричество переплата, а за отопление долг - и в кассе говорят,что нет долга "по сумме", но чем руководствуются при делении платежа  по услугам - непостижимо). Никто не пытается платить водоканалу за ГВС. Как ее нагревают и откуда они ее берут жителей не волнует, но, естественно, взять кроме как у водоканала неоткуда, то есть у нас договариваются с водоканалом, ещё как.
И как-то будут это вносить в ГИС ЖКХ. На текущий момент Энергосбыт крут - уже наверно пару лет как есть сайт, где можно посмотреть начисления и суммарные платежи за месяц, передать показания и авторизация гораздо проще - номер лицевого счета и пароль из смс. Не нужно подтверждать личность через Госуслуги. Правда это нисколько не помогает разобраться с цифрами.  :D

[QUOTE]AlcorVol пишет:
В нашем случае - никто ни с кем не договаривается.  :) Водоканал чисто за воду получает, а Теплосеть - за тепло. Каждая РСО - за свой ресурс. И знать они друг друга не хотят. Да и зачем?   :) [/QUOTE]Не в обиду будет сказано, но я сомневаюсь, что у Теплосети нет утечек теплоносителя. Если бы это был маленький зарубежный поселок с замкнутой системой отопления, построенный пару лет назад, я бы поверил. Но Вологда не маленький поселок и страна наша любимая, полагаю, система отопления хотя бы где-то да прохудилась. Откуда они возмещают утечки - ведь не из ближайшего водоема ведрами носят? Или незаметным образом вблизи города и перечисленных соседних городов открылся портал в рай и трубы теперь не изнашиваются? "Тогда мы идем к вам" :D
Если серьезно, то нежелание договариваться как раз и "лечится" нормативными актами. Скажут "сверху" договариваться иначе штраф - желание сразу найдется.
[QUOTE]AlcorVol пишет:
Муниципальным актом тут не обойтись. Сразу наткнётесь на проблемы при заполнении ГИС ЖКХ, которые только на федеральном уровне решаются. А внутри города - никаких особенных проблем нет. Даже ГЖИ всё понимает.  :)[/QUOTE]Не обязательно на муниципальном уровне, региональный закон тоже подойдет :) Это надо смотреть по разграничению полномочий между уровнями власти, главное чтобы региональный закон не противоречил федеральному законодательству и чего-то разъяснял. У нас порой по каждой мелочи издают региональные законы, которые на более чем на 3/4 слово в слово соответствуют федеральным, остальное - количественные уточнения. Тут-то бы и уточнить, что вот такой местный колорит - ГВС делаем так-то и все это относится к такому-то пункту исчерпывающего перечня. На основании регионального закона подправить лицензии.
#
[QUOTE]AlcorVol пишет:
[QUOTE]two_oceans пишет:
Ещё подумал - а ведь если интерфейс похожий, то надо при изменении ЛК менять программу, это однако похуже шаблонов будет.[/QUOTE]
Не совсем понял. Я имел в виду самостоятельное интерактивное приложение, интерфейс которого (GUI) по стилю напоминает стиль работы юзера в ЛК. А если будут меняться сами форматы структуры данных (как сейчас шаблоны меняются), то это, конечно, в  программе клиента (УО), осуществляющей подготовку XML-файлов, учитывать придётся.[/QUOTE]
А я не про форматы, а про то, что они и сайт частенько меняют - перетаскивают форму с одного раздела на другой без всякого предупреждения. То есть периодически придется синхронизировать вид приложения с текущим видом сайта.
[quote:3nv6tnms]Успехов! А я пока продолжу с XLSX-шаблонами ковыряться. Пора бы отложить в сторону писанину на форуме, а заняться делом. :)[/quote:3nv6tnms]Как раз о том же подумал, да и другой работки подкинули. Поэтому сокращаю время на форуме и ищу наметки в Интернете. Вот что вчера нашел:
[url:3nv6tnms]http://www.clevercomponents.com/articles/article022/soapsecurity.asp[/url:3nv6tnms] Пример на Дельфи как подписывать XML, на ГОСТ нужно изменить пару деталей и так как функция подписания по ГОСТу уже найдена, я уже знаю каких деталей. С приведением к каноничному - мрак (самодельные примеры не учитывают всех вывертов стандарта, если будет XML без вывертов, то сработают, но есть предчувствие что это не сработает в самый неподходящий момент). С кодировкой base64 виду чуть лучше - она везде есть, но исходник пока не нашел. Ничего, найду, где-то он мне уже встречался.
[url:3nv6tnms]http://forum.foxclub.ru/read.php?29,562055[/url:3nv6tnms] "Возможна ли каноникализация XML средствами VFP". Специально для пилящих SOAP на VFP. Кроме каноникализации там еще и декларации функций майкрософтовского криптопровайдера - как получить хэш и подпись и чего с ними потом делать.
[quote:3nv6tnms]Коллеги, чем предложения разработчикам ГИС об изменениях будут дальше от существующих схем, тем меньше вероятность того, что их хотя бы прочитают.[/quote:3nv6tnms]Согласен, но с другой стороны сколько можно ждать "милости от природы", поэтому наиболее далекие от существующих схем предлагаю сделать совместными усилиями - я вот практически решился написать DLL для подписи XML. Тема достаточно интересная в плане множества других применений XML. Ранее думал, что моего кунг-фу не хватит, но оказалось программисты ФГИС это не придумали, есть международный стандарт - сразу стало легче. Остается вопрос реализовать подписание как в ГИС ЖКХ и остановиться или реализовать формат полностью. В частности, сертификат, можно указывать многими способами. О полном формате нашел вводную статью: [url:3nv6tnms]http://minichden.narod.ru/articles/xmldsig.htm[/url:3nv6tnms].
По этому вопросу - мне нужно будет как-то проверить результат. Пилить в C# только ради проверки нет никакого смысла. Может быть, если у кого есть рабочая схема подписи, я предоставлю "самодельные" тестовые сертификаты и вы ими подпишите несколько файлов?
[quote:3nv6tnms]Поскольку xlsx это «усложнённый» xml, то (навскидку) дополнительной работы для его обработки должно быть немного.[/quote:3nv6tnms]Обоснование понятно. Однако, как мне кажется это может иметь обратный эффект: SOAP, это то же XML, так что с ним программисты ГИС уже "наигрались" и реализовывать еще что-то промежуточное между SOAP и XLSX будет слишком похоже, при дополнительной необходимости отражать изменения на еще один формат, и потому не так уж привлекательно. Однако даже если сделают возможность грузить SOAP через ЛК без кучи регистраций в качестве ИС и тестирований, тоже будет достаточно забавно.
[quote:3nv6tnms]Да, практически все более менее умеют работать в Excel. Но Excel умеет открывать и сохранять xml, csv, ods и с натяжкой dbf. [/quote:3nv6tnms]Вот честно говоря, насчет xml не уверен, с таким же успехом html можно дополнить в список. Сам формат Эксель конечно умеет открывать и сохранять, но при этом при создании/сохранении файла в Экселе в тегах столько специфичного для Экселя "мусора" - всяческие стили офисного пакета, форматы, формулы и т.д. - что ни одна уважающая себя система не будет этот хлам обрабатывать без дополнительного "очищающего" конвертера. Из-за такого "мусора" в тегах я даже FrontPage давно перестал использовать для редактирования веб-страниц.
#
Кажется, примерно представляю в чем может быть проблема. Если есть скрытые листы, то скорее всего они не просто так, и на видимые листы "тянутся" какие-то формулы или "отношения" между ячейками. При ручном заполнении Эксель их автоматом корректирует (либо не совсем автоматом, с помощью каких-то макросов от авторов шаблона). Когда пишете программно, нужно тоже эти "отношения" указывать.

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

Подпишись на рассылку новостей ЖКХ, а также наших статей!

Спасибо, вы успешно подписались на рассылку!