Последние сообщения

#1

Размышлизмы / Re: Про 1С++ООП, на ночь глядя...

Последний ответ от Злоп - Сегодня в 17:35

И почему это остаточный регистр бяка, а оборотный небяка?
.
Кстати, так до сих пор толком и не знаю что сидит в таблице итогов оборотного регистра (например, с периодичностью = месяц)...?

#2

Размышлизмы / Re: Про 1С++ООП, на ночь глядя...

Последний ответ от Пиит - Сегодня в 02:02

... появился Регистр собственный, как таблица Многомерного массива, произвольный OLAP-куб...

Всякий Регистр есть Пространство, но не всякое Пространство можно или нужно отнести к Регистрам.
Так, НепериодическийРегистрСведенийV8 являтся несостоятельным Регистром от слова совсем, но зато эту конструкцию можно использовать в качестве дискретной N-мерной Функции, с помощью которой можно задать множество полезной информации, такой как СодержаниеДрагметалловВТМЦ, НормыРасходаТопливаНаТягачИВидПолуприцепа, РасценкиКатегорийВодителейНаРаботыПоВидамТранспорта, СодержаниеВкусняшекВПродуктахПитания и т.д. и т.п. Когда речь идёт о действительно условно-постоянной информации, подобные КнигиОВкуснойИЗдоровойПище должны быть всегда под рукой. В типовых конфигурациях V7 такую информацию обычно раскладывали в ПодчинённыеСправочники, что не является правильным решением из-за асимметрии последних. И ТМЦ, и Драгметалл есть равнозначные Измерения, и пользователь, помимо информации о содержании всех драгметаллов в конкретном ТМЦ имеет полное право видеть и содержание конкретного драгметалла во всех ТМЦ.

ПериодическийРегистрСведенийV8 уже может быть Регистром, и подчиняться воле ХозяйственнойОперации, но это вовсе не обязательно. Так, например, НормыРаходаТоплива могут меняться со временем в связи с пробегом или другими обстоятельсвами, но из этого не следует, что нужно кровь из носу создавать для Регистрации этого события специальный ВидОперации, достаточно внести изменения в эти таблицы вручную. Наверное от слова "вручную" у некоторых товарисчей наверху прыщи на теле высыпают, иначе зачем они закрыли возможность править таким способом Регистры и даже Проводки? Понять эту логику без дедушки Фрейда крайне затруднительно.

Ближе к делу. Любое Пространство может стать Регистром при условии, что оно будет наделено ещё одним измерением, не совсем обычным, и называется оно - Время. Только Время даёт возможность положить в Регистр Событие, ту самый Точку Пространственно-ВременногоКонтинуума, ХозяйственнуюОперацию со своим собственным для этого случая Реквизитом ДатаОперации.
Это достаточное условие, но оно не является необходимым. Если нет Регистратора, то нет и Регистра, поэтому ПространствоВремя может существовать и само по себе, хотя в общем, я и не знаю, где будет востребована такая конструкция, ведь даже Флинн Таггарт не будет рад стоять на месте. Движение - это Жизнь.

Здесь я считаю небходимым пояснить разницу между Регистром и OLAP-кубом. Регистр - это таблица, пусть и "вторичных" Движений, но таки исходных данных для OLAP-куба. OLAP в общем случае не содержит Время в своих Измерениях, но в обязательном порядке содержит ПромежуточныеИтоги в разрезе ВременныхОтрезков. И здесь я считаю ОстаточныйРегистрV7 также несостоятельным решением, в отличие от ОборотногоРегистраV7 и БухгалтерскихИтогов. Специалисты знают недостатки ТочкиАктуальности при перепроведении отдалённым задним числом. Похоже, ДядяФёдор как раз на этом Объекте сдал свои дела, и РегистрV7 стал очередным не_до_разумением.

Важно, что Регистром не обязательно может быть только сложносочинённое Пространство. Любой ТипДанных, наделённый свойством Периодический, может стать Регистром. Я очень буду скучать по Объекту "Периодический", даже если меня тошнит от этого названия. Ведь это придумал ДядяФёдор - определить Время как Свойство, и это очень Логично. Время есть необычное Измерение, у него есть свои уникальные особенности, и добавить просто так Время в Пространство в Качестве рядового Измерения не позволит использовать его без надлежащего Интерфейса. Поэтому я, в честь ДядиФёдора, предлагаю восстановить Время в своих правах, и определить как фундаментальное Свойство любого ТипаДанных. Не вижу для этого никаких препятствий.
В системе, где каждый ТипДанных уложен в свою ТаблицуБД, и даже для Числа и Строки есть свои отдельные хранилища, добавить ещё одну колонку Время и ещё один индекс Owner+DateTime не составит никакого труда. Таблицу КонстантV7 видели? Вот, примерно так, каждый ТипДанных ака Класс, трах-тибидох, может одним щелчком превратиться в настоящий Регистр. И Зигмунд упаси запретить изменение его "вручную"...

#3

FormEx / Re: ПанельСтрокиСостояния - Чт...

Последний ответ от Злоп - Вчера в 19:23

Имеет смысл перенести по существу описание проблемы и её решение в ветку "дележка опытом" https://forum.dorex.pro/index.php?topic=94.15

#4

FormEx / Re: ПанельСтрокиСостояния - Чт...

Последний ответ от mEnter - Вчера в 17:11

Точно. Спасибо. Надо это где то записать, чтобы не потерялось.

#5

FormEx / Re: ПанельСтрокиСостояния - Чт...

Последний ответ от Djelf - Вчера в 11:32

Нашел, https://www.1cpp.ru/forum/YaBB.pl?num=1210673051

Код Выделить Развернуть

Трясение строки зависит от вот этого:
Цитата:
Меню - Сервис - ПанелиИнструментов - Дополнительные - Единая настройка для всех режимов работы

Единая настройка = 1  -- строку состояния трясет
Елиная настройка = 0  -- не трясет.
Переключение этого флажка влияет на эффект сразу при закрытии окна опций.

В реестре это
Цитата:
[HKEY_CURRENT_USER\Software\1C\1Cv7\7.7\Options\TOOLBARS]
"IgnoreLayouts"="1"

#6

FormEx / Re: ПанельСтрокиСостояния - Чт...

Последний ответ от mEnter - 07 мая 2024, 22:53

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

#7

Размышлизмы / Re: Про 1С++ООП, на ночь глядя...

Последний ответ от Пиит - 07 мая 2024, 12:39

... Есть в семёрке такой замечательный Объект, Регистр назывется...

Дядя Фёдор знал не только ООП и SQL3, но кое что ещё.
Откуда в Платформе взялось слово "Регистр"? Открываем толмуд по бух.учету и читаем: "Счёт - это учётный регистр, предназначенный для тэго вэго". Вот и весь секрет. Когда ДядяФёдор приступил к моделированию компоненты БухУчёт, он не поленился полистать специализированную литературу. Как известно, Счета бывают синтетические, т.е. группы, и аналитические, так называемые СубСчета. Но есть ещё и другие Регистры - аналитические СубСчета СубСчетов, которые в теории бух.учёта Кодируются специальным образом, но собственного названия почему-то не имеют. СубСчет же по латыни звучит как СубКонто, и в результате такой игры слов Компания являет Миру новый термин для обозначения этих Измерений. Красиво? Мне нравится.

В то время основная проблема учётных систем заключалась в замедлении расчета конечных итогов в процессе накопления информации. В контексте и бух. и опер. учета программы того времени рассчитывали конечные сальды начиная с первой проводки в системе, таким образом, чем больше движений, тем больше требуется времени для расчёта итогов. Многие специалисты находили выход в постоянном архивировании предыдущих периодов с перерасчетом входящих остатков в новый период. В V6 также была реализована подобная схема, но чуть хитрее. Была внедрена специальная Таблица, Бухгалтерские Итоги, а для смены ПериодаБИ требовалась соответсвующая процедура перерасчета Бухгалтерских Итогов. Шарик был доволен, его ноу-хау было немножко интереснее, чем у конкурентов.

ДядяФёдор так не считал. Принимая Счет и ВидыСубконто как измерения в многомерном массиве бухлалтерских данных, он задумал и реализовал в V7 самый что ни на есть настоящий OLAP-куб. Это и есть те самые Таблицы БухгалтерскихИтогов, которые содержат промежуточные данные бухгалтерских функций, ещё и в помесячном разрезе.
Знал ли ДядяФёдор в то время, что такое OLAP? Термин этот ввёл в обиход Эдгар Кодд в 93 году в известной статье  «12 правил аналитической обработки в реальном времени». Такие массивы использовались и раньше, с 70-х годов, а великодушный Эдгар в вышеуказанной заметке только дал добро на их применение в свой модели РБД.
ДядяФёдор мог и самостоятельно додуматься до подобной конструкции, а затем уже "включить диалап", чтобы удостовериться, что он не псих. Как бы то ни было, компонента получилась удачной. Положив структуру Таблицы Проводок в соответсвии с Таблицами БухгалтерскихИтогов, ДядяФёдор не только реализовал христоматийный ROLAP-куб, но и виртуальный одноимённый ПрикладнойОбъект, как технологию, объединяющую данные вторичных таблиц с исходными данными. И о приемственности Творец не забыл, и назвал такой механизм БухгалтерскимиИтогами.

В технологии OLAP, Таблицы, вмещающие в себе множества значений измерений общего массива данных, называют агРегированными, а уникальный набор значений, Кортеж данных в в этом многомерном Пространстве, в нашем случае это есть структура [Счет, Субконто1,.., СубконтоN], называют агРегатом, что вполне созвучно слову Регистр. Таким образом, ДядяФёдор и остановился на этом названии своей конструкции, с одной стороны, имеющем бухгалтерские корни, а с другой, вполне вписывающийся в актуальные по тем временам технологии.

Так в компоненте ОперативныйУчёт появился Регистр собственный, как таблица Многомерного массива, произвольный OLAP-куб, с неограниченным количеством как Измерений, так и Ресурсов. Причём Куб здесь немного урезанный, в отличие от БухгалтерскихИтогов. Почему-то один и тот же Регистр не может быть одновременно Оборотным и Остаточным. Но, несмотря на это, ПрикладнойОбъект Регистр, как и БухгалтерскиеИтоги, представляет собой Класс, объединяющий ТаблицыДвижений и ТаблицыАктуальности в одно целое.

Что любопытно, каждый новый Счёт в ПланеСчетов автоматически порождает новый бухгалтерский Регистр, и Одинэсники с удовольствием используют таким образом забалансовые счета в своих корыстных целях. И только Пираты Карибского моря могут  в таких случаях обвинять Сапожников в извращениях, дескать, не проще ли использовать для этих целей сам Регистр. Нет, проще таки за балансом, а Регистр только в случаях, когда количество измерений выходит за рамки ПланаСчетов. Но всегда нужно помнить, что количество агРегатов в OLAP-кубе растёт в экспонециальной прогрессии при каждом новом измерении.
ПланСчетов же по сути есть множество Регистров, и заметьте, даже бухгалтер имеет полное право на порождения нового МногомерногоПространства для своих целей, а вот кладовщик таким правом не наделён.

А что же такое "агрегатные" типы данных в нашей Платформе? Согласно Описанию встроенного языка, в этом чудном списке присутствует не только агРегированные Таблицы типа Справочник и Документ, но такие Классы, как СписокЗначений, ФайловаяСистема и даже XBase, в общем всё то, что порождается с помощью СоздатьОбъект.
Но об этом таки нужно спросить у Шарика, который одним лохматым ухом слышал слово "агрегат" от ДядиФёдора, но понять замысел Творца как известно был не в состоянии...

• [1810]

#8

Размышлизмы / Re: Про 1С++ООП, на ночь глядя...

Последний ответ от Пиит - 07 мая 2024, 08:32

-  так это же про 7.7.

И да, и нет.
Все мы Родом из 7.7, но в контексте нынешнего безобразия под номером 8.3 многие специалисты пожимают плечами, глядя куда катится Компания.
Не нашлось таки у них нового ДядиФёдора...

#9

Размышлизмы / Re: Про 1С++ООП, на ночь глядя...

Последний ответ от Злоп - 07 мая 2024, 02:19

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

- так это же про 7.7.

• [1804]

#10

Размышлизмы / Re: Про 1С++ООП, на ночь глядя...

Последний ответ от Пиит - 07 мая 2024, 00:52

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

Надо уже закрыть этот вопрос, и больше к нему не возвращаться.
Окна задумывались как псевдомногозадачная ОС, и до сих пор она по сути таковой и является, с добровольно-принудительным последовательно-параллельным распределением между приложениями процессорного времени и ОЗУ. По мере роста количества процессорных ядер и соответсвенно возможностей физического распараллеливания приложений, Окна трансформируются в настоящую многозадачную ОС. Ну и флаг им в руки, развитие этой концепции мне не представляется интересным.
В контексте объединения ОЗУ и ПЗУ имхо более интересным мне видится ОС с общим ЗУ для всех исполняемых приложений. Таким образом, в одной такой ЗУ-ООБД смогут одновременно сосуществовать и 1Сv25, и Компас-33D, и даже Флинн Таггарт в таком Мире будет иметь право на дополнительную Жизнь. И в такой Операционной Системе в добровольно-принудительном порядке, может быть осуществлён универсальный доступ приложений к данным друг друга, на основе общих Классов как универсальных СтруктурДанных в общей для всех среде исполнения.
Но это, "по расчисленью ФилософическихТаблиц, лет чрез пятьсот"...