код в Queryclose

  • Автор темы oxystile
  • Дата начала
O

oxystile

Доброго!

такая вот непонятка
в QueryClose код:

[codebox]t1=doc.ish_count(0) 'чисто для дебаггера
t2=dc.count 'для дебаггера

If doc.ish_count(0)<>dc.count Then
doc.ish_count=dc.count
Call ws.ViewRefresh
Call doc.Save(False,False)
end if[/codebox]

пусть, например t1<>t2 , при закрытии код выполнился (что видно в дебагере)
открываю док, значание переменной не изменилось, а при закрытии снова выполняется этот код
снова открываю док. и наконенц-то вижу, что значение изменено.

поле было и компутед и эдит, ни к чему оно не привязано, собственными глазами вижу, как оно получило новое значение (в дебагере) открываю, и вот нет его, этого значения... ;)
 
O

Omh

Что в QC делает Call doc.Save(False,False)?

Код:
If doc.ish_count(0)<>dc.count Then Call doc.replaceItemValue("ish_count", dc.count)
Всё, не надо лишнего городить...
 

Medevic

Что это ? :)
Green Team
10.12.2004
3 334
1
BIT
6
А что за doc? Случаем не профильный документ? ;)

Также, ты используешь False в параметрах: doc.Save(False,False). Неплохо бы посмотреть, что возвращает этот метод.
If Not doc.Save(False, False) Then MsgBox "Сохранение не удалось".
 
O

Omh

Хм, у меня даже не родилось мысли, что doc - это не текущий док, у которого QC и отрабатывает. ;)
Заштампованость мышления ;)
 
O

oxystile

Omh
doc это Source.Document
If doc.ish_count(0)<>dc.count Then Call doc.replaceItemValue("ish_count", dc.count) не работает, если save не выполнить, сколько не переоткрывай...
да и почему должен работать???

Medevic
может, я ошибаюсь в правильности наличия doc.Save(False, False) но
как раз в тех случаях, когда значение переменной и не обновлялось вставка этой проверки
If Not doc.Save(False, False) Then MsgBox "Сохранение не удалось".
и помогло определить что беда с сохранением
а почему, это уже надо искать
 
O

Omh

Medevic
Смотрю в книгу, вижу фигу.
Вообще голова уехала.
Прошу прощения.

Сохрание документа на QueryClose зачастую свидетельствует о неправильной реализации.
Лучше избегать этого.

oxystile
Почему не перенести все проверки на QuerySave таки?
 
O

oxystile

вот то-то и я смотрю, что сперва QuerySave а потом QueryClose

но в QuerySave код не стоит запихивать, потому что не всегда этот метод будет вызван(если конечно не заставить)
это мне все-таки надо что-нибудь придумать на тему https://codeby.net/threads/22589.html

т.к. мне надо поставить признак наличия во входящем исходящих(которые оформлены в виде embedded view)
и учитывая то, что исходящие создаются только из входящего и т.о. QuerySave не учавствует во входящем, а QueryClose задействован по-любому, вот и добавила на форму поле ish_count, которое вычисляется при закрытии входящего и равно количеству исходящих (хотя можно установить его признаком, либо исх. есть либо нет)
я не претендую, что это идеальное решение, но как-то вот родилось...
так что если есть другие решения, приму с удовольствием :)
 
S

Sandr

Используйте метод сохранения уидокумента... Тогда проблем не будет..
 
O

Omh

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

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

Я бы кампутед поле сунул бы в печЪ.
 

Medevic

Что это ? :)
Green Team
10.12.2004
3 334
1
BIT
6
так что если есть другие решения, приму с удовольствием smile.gif
Как вариант используем дополнительный документ. Назовем его счетчик.
1) Счетчик создается (как дочерний документ) при создании входящего документа.
2) В счетчик копируется необходимая часть данных из входящего документа, которая обновляется при сохранении входящего документа.
3) В представлении вместо входящего документа показываем счетчик с необходимыми данными из входящего документа. Соответственно, переопределяется событие Queryopendocument в представлении, чтобы открывался не счетчик, а входящий документ.

Да, и самое главное. :)
4) Все изменения исходящих документов пишем в счетчик агентом.
 
O

oxystile

Medevic
счетчик-документ, можно, но структура БД уже есть и на ней работают
и придется реализовывать п.1 на уже существующих документах...
+ такова уж практика, что все примочки кот. я добавляю в БД должны быть и легко "сносимы" (из-за 7 пятниц)
ну и прикручивать их надо ооочень аккуратненько, как бы так сказать сбоку :)

Sandr
почему именно метод сохранения уидокумента, а не doc.Save
doc.Save быстрее, а в querySave у меня набор всевозможных проверок, который необходим, если чел. действительно редактировал документ т.е. было и EditMode и он нажал сохранить
а такое действие как создание исходящего не нуждается потом в querySave входящего, т.к. все проверки неактуальны
да и к тому же этот уидок.save некуда и вставить (док открывается в реж. просмотра, из него добавляем исх., реж. просмотра при этом остается)


Omh
а почему поле компутед в печь? пусть будет edit
при входе зачитывать будет не совсем рационально
1. если документ свежак, то там будет 0 исходящих
2. чел открыл вход. и добавил исходящий, потом закрыл (и как рез-т надо чтобы соответсвующий icon появился в общем представлении напротив этого входящего)
а о том, нужен этот icon или нет, документ входящий узнает только при своем закрытии

на QueryClose у меня теперь код
t1=dc.count
If t1>0 And Cstr(doc.ish_flag(0))<>"1" Then
Call doc.replaceItemValue("ish_flag", 1)
End If
If t1=0 And Cstr(doc.ish_flag(0))="1" Then
Call doc.replaceItemValue("ish_flag", 0)
End If
If Not doc.Save(False,False) Then
Msgbox "Сохранение не удалось"
End If
Call ws.ViewRefresh

т.о. изменение флага на 1 будет только при добавлении первого исходящего, а дальнейшее их добавление не интересует.
ну и есть 1% случаев, когда исходящий (исходящие) будут удалены напрочь, и этот случай тоже отработает
 
S

Sandr

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

oxystile

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

Omh

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

oxystile

Omh
ладно, вообщем, я поробую внедрить, если что и грохнется, то исправить легко можно :)

спасибо всем!:)
 
30.05.2006
1 345
12
BIT
0
Сохрание документа на QueryClose зачастую сведетельствует о неправильной реализации.
ВСЕГДА.. не зачастую
Почему не перенести все проверки на QuerySave таки?
Ага. А если требуется лишнее сохранение, совместите его с основным - в PostSave (если только у вас не 4.х.х :ph34r: )
 
K

K-Fire

ВСЕГДА.. не зачастую

Допустим есть такая задача:

Главный документ "Счет". Подчиненные доки: "строка счета". Отображаются в ембеддед вью в Счете. Больше нигде не видны и из других месте не редактируются.
Вы добавляете еще одну "строку", вбиваете сумму внутри него. Закрываете документ строки.
Хочется чтобы сумма всех строк обновилась в "Счете" как можно быстрее, желательно сразу. Счет может находиться в режиме чтения или редактирования.

Какие ваши действия? :angry:
 
Мы в соцсетях:

Обучение наступательной кибербезопасности в игровой форме. Начать игру!