всем добрый день

большие респекты и спасибо разработчикам 1с++ , спасибо что проект живет и развивается.  

решил перейти на 1с++ 3.х с версии 2.0.3.3  и столкнулся с такой проблемой.  

перестали привычно работать методы _onReadProperty/_onWriteProperty .

т.е. раньше была возможность "перехватить" в классе чтение/запись несуществующего свойства класса, и динамически управлять процессом.
в частности, мой класс "Структура" позволял "вольности" типа такого :


 p = СоздатьОбъект("СStruc") ;
 p.property_1 = 1 ;
 n = p.property_2 ;


при этом, чтение/запись свойcтв как раз определяется в документированных методах _onReadProperty/_onWriteProperty ...

как и что исправить - и возможно ли в новой версии - не нашел.
перерыл всю документацию и форум  .

или ткните носом где читать или подскажите как быть ?

заранее - big thanx  

shmalevoz писал(а) 03. Декабря 2009 :: 08:38:


я читал этот топик.
насколько я понял, то убрали саму возможность присваивать напрямую (через точку) динамическим свойствам класса значения ?

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

думаю, что аналогичная проблема возникла у многих разработчиков. получается, что вариантов "безболезненного" перехода не существует ?  

shmalevoz писал(а) 03. Декабря 2009 :: 14:27:


ндя.... это не совсем удобно .
кроме того - загромождает код.

это видно даже на простом фрагменте :

запись вида
p.property_1 = 1 ;

гораздо компактнее, чем

p.ДобавитьДинамическоеСвойство("property_1") ;
p.property_1 = 1 ;
тогда смысл замены предыдущей логики становится совсем непонятным : метод можно было добавить и так , зато в итоге потеряли очень полезную фичу.

у меня вопрос к разработчикам :

а есть ли возможность как-то вернуть/добавить прежний функционал , хотя бы на уровне динамических свойств класса. ?

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

к примеру : в новом варианте , при записи в свойство [property_1 ] сейчас получим исключение и останов.
а если бы была возможность  отловить и обработать в классе этот момент каким нибудь предопределенным методом , как-то можно было бы выкрутиться.

или - попробовать через Перехватчик как-то решить проблему ?
хотелось бы хотя бы как то получить переменную и значение в случае исключения.

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

shmalevoz писал(а) 03. Декабря 2009 :: 20:47:


не всегда возможен такой подход.
имхо.

вот , порыл по сусекам - нашел старую ссылку, когда-то юзал вместо структуры.  

[ http://www.erp-volga.com/hare/add-in/addin.eproc.html ]

там есть объект [ AddIn.List ]
простой как грабли.
но весьма эффективный.
вот именно что-то такое нам всем нужно.   // судя по аналогичным постам на форуме

либо - добавить в [Структуру] эту полезность  

цитата :
Синтаксис:
<Переменная>
Назначение:
Значение элемента списка.
Замечание:
Позволяет устанавливать (Лист.Переменная = 10) и получать (ЗначПер = Лист.Переменная) значения через точку. При первом обращении к переменной (либо установка, либо получение) запоминается ее наименование, резервируется место и заносится значение.

попробую вывернуться через нее.
// кажется DynaWrapper (?   )
// позволяет создавать алиасы объектов,
// а базовые методы, вроде совпадают... -
// не придется лопатить весь код в классах....

кстати.
а можно ли как-то наследовать классы от объектов компонент ?

Напиши, плиз, простой тест.
в нем должен быть
1. 1 класс для работы с динамическими свойствами - т.е. упрости свой CSruct, убрав лишние детали
2. обработка с кодом, который должен сработать.
Объект = СоздатьОбъект("нужныйКласс");
Объект.НовоеСвойство = 1;

После получения теста смогу посмотреть более детально и подсказать решение.

artbear писал(а) 04. Декабря 2009 :: 07:17:



отлично !  

очередные ВАМ всем grand-респекты ! 

Ты правда думаешь, что если я по запарке напишу

а= объект.Сувойство1 

вместо

а= объект.Свойство1 

, а код будет выполнятся вместо вылета по ошибке "Свойство не найдено" - это будет круто?

orefkov писал(а) 05. Декабря 2009 :: 09:58:


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

* в частном случае со Структурой - в большинстве случаев - (имхо) да.  
такое поведение логично, если вернется EmptyValue

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

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

ps: кстати,  в тестовой прикрутил Addon.List  .
погонял.
вроде - все нормуль.
но весь феншуй ломается в одной точке - регистрозависимость....  
списался с автором - пока нет ответа (работа 2002 года)..
// подожду еще пару-тройку дней. не ответит - в свою компоненту воткну тогда фунцкионал. но это уже нефеншуйно будет....  

в итоге, остается открытым вопрос :

возможно ли добавить в класс Структура  следующий функционал :

при первой записи в свойство :
* проверяем есть ли свойство, если есть - перезаписываем его // сейчас так и есть
* если нет, создаем и записываем // ++

при чтении ствойства :
* если есть свойство - вернем его значение // сейчас так и есть
* если нет такого свойства - вернем GetEmptyValue() // в терминах 1с // ++

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

?

artbear писал(а) 06. Декабря 2009 :: 06:48:


ок. тогда сейчас перекомпоную немного тестовую.

fez писал(а) 07. Декабря 2009 :: 11:50:


Да оно то можно, но IMHO это можно сделать только в месте вызова а не в самом классе.... а в таком случае легче уж все места вызова поправить на использование функции/метода а не реквизита/свойства чем городить попытку

Хотя нет! В данном случае таки можно - через наследование класса, но когда это твой собственный класс, городить "наследника" только ради Попытки/Исключения - это уже лишнее

fez писал(а) 16. Декабря 2009 :: 16:01:

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