Гм... Ну ты даешь.
А я только спать собрался

Зачетно! Радости у народа должно быть полные штаны...
Блин, как надоела 1С, кто бы знал... Только подобные чудеса еще как-то поддерживают интерес к ней.

(0)
не видел, но одобряю 

Круто! Спасибо, Миша!
П.С. после редактирования значения куда-то пропадает один "esc", т.е. отредактировал, бегаяю по ячейкам, хочу закрыть форму обработки по ESC, но первое нажатие уходит вникуда, второе - отрабатывает нормально.

vip писал(а) 11. Февраля 2008 :: 21:58:

Да можно не сдерживать, дети уже спят

maljaev писал(а) 11. Февраля 2008 :: 23:14:

Очень хорошо знаю. Кстати, твои чудеса мы тоже видели.

vandalsvq писал(а) 12. Февраля 2008 :: 04:08:

Принято.
Выбор подчиненных и групп в эту серию не прошел из-за ограничений по бюджету

JohnyDeath писал(а) 12. Февраля 2008 :: 07:31:

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

JohnyDeath писал(а) 12. Февраля 2008 :: 09:35:


Пока все же задача стоит в отладке базовой логики, там видно будет.
Но здесь проще все же в коде реализовать, типа:

Процедура ТаблПолеПриРедактированииЗначения(__тп, __стр, __кол, __рег, __знач)
     Если __рег =3 Тогда
           _всего =__тп.Колонки.Количество();
           _поз =__тп.Колонки.Индекс(__кол) +1;
           _поз =?(_поз =_всего, 0, _поз);
           __тп.ТекущаяКолонка = __тп.Колонки.Получить(_поз);
     КонецЕсли;
КонецПроцедуры

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

trad писал(а) 12. Февраля 2008 :: 06:12:



Uzhast писал(а) 12. Февраля 2008 :: 06:47:

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

Цитата:

Э, ну во-первых это же не ты думал.
И потом я не понял, ты тоже за это время дедушкой стал что ли?

... вечно молодым, вечно пьяным...

Цитата:

Непременно. Сейчас вот пиво мы допьем...

Цитата:

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

Arta писал(а) 12. Февраля 2008 :: 22:39:

Хорошо сказал.
С тебя тоже тогда отзывы и предложения по теме

Arta писал(а) 12. Февраля 2008 :: 22:56:


А все-таки хотелось бы что-то вроде отдельной ветки сборки TF с этим функционалом. Если не очень напряжно. Или сразу внести в ветку TF. Если я правильно понимаю, в ветке TF есть все изменения основной ночной сборки.
Все равно эту ветку на свой страх юзают отдельные энтузиасты (я ). А лучшего тестирования, чем боевое применение, не придумаешь.

vip писал(а) 13. Февраля 2008 :: 05:50:

А здесь в заглавном сообщении и будет сборка этой ветки, условно TF3_EV.
Т.е. простой nightbuild и TF3 собираются как обычно, TF3_EV собирается здесь.
К сожалению, пока добавить в CVS не получится, ибо изменения касаются не только ТП.
Ну, мы решим эту проблему чуть позже.

kms писал(а) 13. Февраля 2008 :: 08:01:

А чего откладывать?
Чего еще касаются изменения?

JohnyDeath писал(а) 13. Февраля 2008 :: 09:10:

в свойствах файла уж больно старенькая прописана -
Nightly build 2007-11-12

А почему проц так грузит? Почти на все 100%, когда мышкой возишь над ТП.

1. Процессор Celeron 2100 - уже слабый?
2. Загрузка процессора в примере, данном в начале этой темы.

alyuev писал(а) 13. Февраля 2008 :: 14:14:

Проверил - в пустой конфе не удалось загрузить камень больше, чем на 30-35%. У меня простой П4 2.4ГГ. Скорее всего, у тебя в конфе фигня какая-то

Глобальник совершенно пустой, никаких классов. Только в ПриНачалеРаботыСистемы() ЗагрузитьВнешнююКомпоненту("1CPP.dll"). 1CPP 2.5.0.6 от 12.11.2007.

Но похоже действительно что-то с системой. На терминале работает нормально.

PS/ Проц нагружается даже в конфигураторе без открытой конфигурации. А там и OpenConf и Colorer.

alyuev писал(а) 13. Февраля 2008 :: 15:11:

Кстати, заметил одну нехорошую ботву. Иногда, когда параллельно открыты 1С и Конфигуратор, могут возникать повышенные тормоза при работе 1С. При этом таскменеджер показывает, что процессор грузит и 1С, и Конфигуратор. Если запустить голый 1С, то тормоза пропадают. Может, у тебя что-то из этой оперы всплыло?

При отключенных всех программах проц нагружается до 30%. В девственной конфигурации. Система XP SP2, 1C v27. Так что прямое редактирование думаю здесь ни при чем. Это отдельная тема для размышлений - нагрузка на проц. Всё - пошел думать дома.... А то голова тоже загрузилась. 

kms писал(а) 15. Февраля 2008 :: 09:30:

Да вроде подробней уже некуда, чувак

Миш, может все-таки закоммитишь в cvs? А то приходится разрываться

kms писал(а) 15. Февраля 2008 :: 23:02:

Ты не про это случайно? http://www.1cpp.ru/forum/YaBB.pl?num=1199369336/9#9

Uzhast
О, спасибо.

vip
Я думаю, до рабочего варианта недолго осталось.
Меня больше беспокоит соседняя ветка, когда удастся разобраться, я куплю себе ящик хорошего темного пива.

all

Обновлена сборка TF+EV от 2008-02-16

(!) исправлены проблемы совместимости
(-) исправлена потеря ESC при первом нажатии

kms писал(а) 15. Февраля 2008 :: 23:02:

Дык все как у правдашных, занесено в багзиллу, ждет своего часа

Начал было радоваться такой замечательной возможности. Кинулся интегрировать в новую разрабатываемую конфигурацию взамен класса "Редактирование таблицы значений".... и тут на тебе. Наткнулся на глюк.
При использовании в модальном режиме попытка вызывать редактирование сносит 1С начисто Пишет "Память не может быть Read" и все ...
Меняю в коде только одну строчку "ОткрытьФормуМодально" на "ОткрытьФорму" и все работает замечательно.
Можно ли это как-то решить?

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

Ну хоть какую-то надежду оставить можно а?

mvgfirst писал(а) 17. Февраля 2008 :: 21:35:


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

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

НО! В любом случае огромное спасибо за столь быструю реакцию... Сегодня вечером потестирую. Разработка дома лежит.

kiruha писал(а) 18. Февраля 2008 :: 09:11:

А ведь встречалось и такое

Цитата:

Все ок, нормальные мысли нигде не мешают.

Очень озадачен ошибкой которую умудрился словить:
Создаю документ, в документе многострочная часть, в многострочной части реквизит связанный с реквизитом в шапке документа.
Так же в документе есть текстовое поле с формулой глЗаголовок(Контекст) соответственно возвращающий заголовок формы. Там есть такие строки
ОбъектФорма = Конт.Форма;
Попытка редактирования значения в версии без доступа к реквизиту проходит на ура, т.е. нет проблем.
Попытка редактирования на последней версии (с поддержкой модальных окон) приводит к тому что передаваемый контекст становится чей угодно но только не той формы в которой расположено ТП. Как объяснить подробнее не знаю. 
Однако факт. при редактировании в старой версии все путем, а в новой сбивается контекст. Ни одно обращение к переменным или атрибутам через контекст уже не проходит ругаясь Поле агрегатного объекта не обнаружено (КакойТоТамРеквизит) 

2008-02-19
[+] исправлено обновление групповых контекстов


P.S.
2 formex developers
CGroupContext::Accept() при любом чихе в FormEx - это есть зло.

2 1cpp developer
Автору, написавшему в CGCBoost::RefreshGroupContextData

delete [] m_pMyVTable;

поем мы песню.

kms писал(а) 18. Февраля 2008 :: 21:46:


Вот уж не думал что в такое позднее время кто-то кроме меня не спит...
Огромное спасибо... огромнейшее...
Все теперь ОК, работает без проблем и сбоев... 

Жил бы не в Уфе мартини-водка-лед уже бы приготовил 

По идее должно "ВыборГруппы(<Режим>)" помочь. Попробуй.

kriblya писал(а) 19. Февраля 2008 :: 12:57:

К временному реквизиту, идентификатор которого передан в метод РедактироватьЗначение().
Посмотри, как сделан выбор подчиненных справочников (через ИспользоватьВладельца()) в примере.

спасибо. заработало.
иногда слетает 1С при открытом ТП, изза чего, не понял.

Цитата:

Дык в процедуре Выбор() у тебя и так более чем достаточно данных для определения обрабатываемой ячейки. там и решай, нужно ли вызывать РедактироватьЗначение.

И вторая хотелка из той же оперы.

Не будем

Кстати, ПриНачалеВыбораЗначения стандартно работает уже сейчас.

РазрешитьРедактирование - это, думаю, перебор.
А вот недоступные колонки / строки / ячейки можно ожидать в недалеком будущем (ну, это тема соседней ветки).

Наткнулся еще на один глюк. Если зайти в режим редактирования и закрыть форму. Например по кнопке в которой Форма.Закрыть(0) - выскакивает АксессВиолейшин и 1С-ка падает. Срабатывает когда форма в модальном режиме. В немодальном все ОК.
Обнаружил на своей форме. На тестовой, которая в примере -  повторил.

Если вдруг в процессе устранения глюка появится какие-то методы позволяющие определить что ТП находится в процессе редактирования ячейки и метод позволяющий этот процесс завершить... Будет просто супер.

А то я честно говоря даже и не знаю .... возможно это как-то можо стандартными методами узнать... но пока не вижу как... видимо к ночи мозки уже вообще не варят.

Еще один мини-глюк: есть фома на форме сабжовое ТП и кнопка. На кнопке признак "Кнопка по умолчанию". Если фокус находится на ТП... комбинация Ctrl+Enter несрабатывает. В место нее ТП входит в режим редактирования.
P.S. Никаких обработчкиов "НажатияКнопкиКлавиатуры" в обработке нет.

Я думаю если подходить к этому вопросу с философской точки зрения то по первому событию: или я умру или исчезнет потребность в этом чудесном творении... ибо как гласит великая мудрость индийских программистов "Глюков нет только в ненужных программах"

Не подтверждается.
Если будет повторяемый тест - могу посмотреть.

ОК. По этой проблеме - не нужны там ни Активизировать, ни SendKeys.

А нюансов здесь много.
Вкратце:
1. К примеру - вход в редактирование (каким-либо способом) в процедуре ПослеОткрытия() либо ФормаПриСоздании() и т.п.
- совместимость не гарантируется

2. Использование "Активизировать" или SendKeys
- совместимость не гарантируется

На самом деле, проблема обеспечения 100% совместимости в данном контексте очень серьезная.
Я бы сказал, нерешаемая.

К счастью, такой цели у меня нет  

P.S.
С++ совместим с С настолько, насколько это возможно, но не больше (Stroustrup, D&E)

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

Если в процедуре ПриРедактированииЗначения я вызываю указанную тобой процедуру - ругается следующим образом:

Цитата:

В общем поймал тут на досуге:
В процедуре выбор создаем объект таблица и начинается:
1. Если пытаемся в ИсходнаяТаблица() установить что нить кроме пустого (по умолчанию) значения говорит что таблица не найдена
2. Если (установили по умолчанию - ИсходнаяТаблица("")) пытаемся вывести секцию (любую) говорит что секция не найдена.

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

Пример
Процедура ТП_ОтправленныеПисьмаВыбор()
     ТекСтрока = ТаблПоле.ТекущаяСтрока;
     ТЗПисьма.ПолучитьСтрокуПоНомеру(ТекСтрока);
     Таб = СоздатьОбъект("Таблица");
     Таб.ИсходнаяТаблица("");
     Таб.ВывестиСекцию("КрутаяСекция");
     Таб.Показать("");
КонецПроцедуры      // ТП_ОтправленныеПисьмаВыбор

В самой секции пять строк которые имею выражения = ТЗПисьма.(??????) - любой идентификатор колонки... это не суть. А суть что вылазиет ошибка что секция не найдена, а я точно знаю что она есть. Ведь в отдельной процедуре все прекрасно отрабатывается.

Версия 1С++ 2.5.0.6, TF3_EV 2008-02-19.... аналогичная проблема была и на 1С++ от 18.12.07... в общем давняя проблема видимо  

Arta писал(а) 28. Февраля 2008 :: 12:33:

Не, нормально все.


[-] Исправлена привязка шаблонов таблиц в событии Выбор()

Миша, слушай у меня тут какая то проблема... описать ее слишком сложно... а вот кинуть тебе на мыло МД я могу... и сказать где и что происходит... может это я туплю. Но уже полдня бьюсь и не могу понять почему так происходит...
если ты скажешь мне куда кидать я заброшу (там всего 3,5 метра)...
У меня получается в одном и том же месте если в ячеейке есть данные тогда ИспользоватьВладельца работает как надо, а если данных нет то не работает 
Может я туплю?
Скажи адрес... 

А когда этот функционал появится в NightBuilde?

+ вдогонку

Я подозреваю, что примененный метод определения владельца в принципе нерабочий.
Причем, по моему мнению, это еще один баг v7/R27, без надежды на исправление.

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

Удачи!

kms писал(а) 02. Марта 2008 :: 12:46:


ОК счас попробую... большое спасибо... переделать форму выбора на форму списка почему то не решился...
Очень рад что это не проблема ТП (в принципе я так и думал что это проблема v7 а не 1С++)... большое спасибо на потраченное на меня время... надеюсь оно для тебя тоже чем то интересно оказалось