[ANN] Tabax 0.1 -- панель задач для Axapta

[kashperuk]

Цитата:

Сообщение от DocSerzh

С радостью приму критику, отмету заблуждения.

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

Теперь по делу:
А почему во втором способе восстанавливается только lookupField, а lookupValue остается с RecId?

Думаю, на данном этапе первый вариант в самый раз.
Но, как шаг для дальнейшего улучшения, второй вариант очень даже ничего.
Почему бы Вам не поэкспериментировать какое-то время с первым вариантом, добавив вывод какого-то сообщения в случае, если наткнулись на форму, на которой указан lookupField?
Мне кажется, особенно учитывая, что форма вызывается новая, и args формируется здесь же, что по ветке с findRecord идти никогда не будет
Возможно и не прав, не проверял.
Насколько я понял, Максим говорит о другом опасении. О том, что существуют формы, у которых логика завязана на использование значений lookupValue. Но, ИМХО, это в основном лукап-формы. В остальных (переход к основной таблице, к примеру) формах врядли значение этого поля анализируется. Завтра поищу по АОТ, чтобы утверждать наверняка.

[DocSerzh]

Цитата:

Сообщение от kashperuk

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

Как то неудачно засветился с комментариями...хм

Цитата:

Сообщение от kashperuk

Теперь по делу:
А почему во втором способе восстанавливается только lookupField, а lookupValue остается с RecId?
.

После executeQuery lookupValue сбрасывается (или после super() в нем, перекрытом).

Цитата:

Сообщение от kashperuk

Мне кажется, особенно учитывая, что форма вызывается новая, и args формируется здесь же, что по ветке с findRecord идти никогда не будет
.

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

Цитата:

Сообщение от kashperuk

Завтра поищу по АОТ, чтобы утверждать наверняка.
.

Проверил у себя [ сильно перелопаченный retail от коруса] :
В основном Lookup используются в init'e для анализа включать фильтры , накладываемые на форме, или нет...
Единственна критическая форма - Addresses , с ипользованием linkActivate в случае открытия из vendTable...
К сожалению, нет сейчас appl под рукой - по памяти....

Цитата:

Сообщение от AndyD

А почему вы считаете, что по lookupField( ) по RecId будет искать правильно?
В случае с SalesTable будет работать корректно, потому что большему salesId будет соответствовать больший recId (пока не перевалили на отрицательные recId!).
А, к примеру, InventTable. Там сортировка идет по itemId, и далеко не всегда большему itemId соответствует больший recId. И таких примеров по AOT можно привести массу
.

Насколько я понимаю, позиционирование идет самим движком, уже в выбранном и отсортированном ds [?]..Не вижу причин [но проверю обязательно - есть такая большая DB с отрицательными recId] почему бы ему (движку) искать не корректно... или имелось ввиду время позиционирования?

Цитата:

Сообщение от kashperuk

Можно усложнить - найти индекс по которому отсортирован дс, проверить уникальный ли он, проверить состоит ли он из 1 поля и только в ежэтом случае лукапить. Иначе скатываться к тормозному варианту
.

Эксперементировал на эту тему до знакомства с tabax...Положительных результатов не получил - как то странно работают объекты AOT, отвечающие за анализ PrimaryKey и уникальность индекса.. ( нет appl под рукой - иначе бы запостил результаты и код job'a, который меня смутил)... Поэтому и остановился на варианте ,используемом в tabax.

Цитата:

Сообщение от AndyD

Тогда надо формировать строку axpath опираясь не на recId, а на поля уникального индекса (если он есть, опять же).
А в случае recId корректнее все-таки поиск перебором.
.

В случае НЕуникальности RecId?

[AndyD]

Цитата:

Сообщение от DocSerzh

Насколько я понимаю, позиционирование идет самим движком, уже в выбранном и отсортированном ds [?]..Не вижу причин [но проверю обязательно - есть такая большая DB с отрицательными recId] почему бы ему (движку) искать не корректно... или имелось ввиду время позиционирования?

Нет. Не верно.
При лукапе на сервер отправляется запрос вида

select *
from TableName
where recid >= recIdValue
order by [- ,     ]

После этого курсор на форме позиционируется на первую полученную запись.
Если порядок сортировки по полям не будет совпадать с порядком сортировки по recId, то запись отпозиционируется неверно

[DocSerzh]

Цитата:

Сообщение от AndyD

Нет. Не верно.
При лукапе на сервер отправляется запрос вида

select *
from TableName
where recid >= recIdValue
order by [- ,     ]

После этого курсор на форме позиционируется на первую полученную запись.
Если порядок сортировки по полям не будет совпадать с порядком сортировки по recId, то запись отпозиционируется неверно

Спасибо за проверку, нет возможности сечас проверить самому...

[gl00mie]

Цитата:

Сообщение от AndyD

При лукапе на сервер отправляется запрос вида

select * from TableName where recid >= recIdValue
order by [- ,     ]

После этого курсор на форме позиционируется на первую полученную запись.Если порядок сортировки по полям не будет совпадать с порядком сортировки по recId, то запись отпозиционируется неверно

Кстати, да. Я «по просьбам трудящихся» переделал сортировку в формах закупок и заказов - сделал сортировку по ожидаемой дате поставки, в результате jumpRef из журнала накладных стал попадать не туда