Переход на правильную запись при Переходе к основной таблице.

[Anais]

Как заставить форму подматывать данные к нужной записи при осуществлении действия "Переходе к основной таблице"?

Создала EDT, Таблицу и Форму. В EDT создала Relation на поле в Таблице, в Таблице - кластерный, Primary Индекс на это поле. Указала Форму в свойстве FormRef Таблицы. Индекс на DS формы НЕ указан. executeQuery (или любой другой метод DS) не перекрыт.
"Слизывала" с Таблицы/Формы LedgerTable. Слизала, кажется, уже ВСЕ.
Но при осуществлении Перехода к основной таблице упорно открывает форму на первой строке.

Чего еще нужно сделать, чтобы осуществлялась подкрутка к нужной записи?

[mazzy]

выложите проект, который можно вставить в стандартную конфигурацию

обратите внимание, что у вас может быть похожая на это ситуация
http://forum.mazzy.ru/index.php?showtopic=807

[Anais]

У меня новый EDT. Я не меняла на нем выравнивание, так что оно "влево" (если я правильно поняла, о чем речь). Проект выкладываю. Постаралась отрезать от него все "безболезненно лишнее".

Axapta 3.0, sp1

[mazzy]

хм...
у вас не переходит из таблицы tor_TMLifeHist из поля TMCode?

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

Совет:
Выкиньте из головы иерархию, пока не разберетесь с Аксаптой.
Научитесь работать с РЕЛЯЦИОННОЙ базой данных.

Дерево - очень медленный объект (или очень тяжелый для использования)
Дерево либо подчитывается целиком и хранится на клиенте, либо требует безумных трудозатрат от программиста.
Например, обратите внимание как заполняется дерево когда начинаешь настраивать контрль доступа. Это отвратительно!
Почитайте на течнете документ про правильное программирование дерева.

А еще лучше. Пока не разеретесь с аксаптой - не мучайте деревья и старайтесь не программировать

[Vadik]

Цитата:

Изначально опубликовано Anais
executeQuery (или любой другой метод DS) не перекрыт.

однако он вызывается из класса tor_TMTree (методы hideShowTree, selectionChanged)

[Anais]

Во-первых, ОГРОМНОЕ человеческое спасибо. Действительно, иерархия всю воду мутила... И вообще, на будущее, я поняла, где ловить подобного рода ошибки.

Что касается, советов - то тоже спасибо. Но
(1) Я - программист и совет "старайтесь не программировать" - ну никак не ко мне
(2) Я (лично Я) хорошо разбираюсь и в иерархии, и в реляционных СУБД. И даже объектно-ориентированную в качестве диплома писала Я понимаю, что дерево (здесь) - это "тяжелый" объект. Но вы объясните это консультантам, у которых уже (а) ТП подписан и (б) "список Тех.Мест - очень большой, но зато - четырехуровневый. Обязательно нужно иерархию, чтобы было удобно" (цитирую по тексту). Кстати, она у нас еще на форме-лукапе к этой таблице реализована....... А контроль доступа они еще не настраивали. Гы. А Вы говорите, не программировать.
(3) Модуль ТОРО в Axapta и без программирования? Очень, очень интересно. Честно. А на каком стандартном функционале его тогда реализовать?
(4) Документ обязательно почитаю.

Еще раз большое спасибо.

[rinugun]

Тоже был случай с громоздкой формой EmplTable(содержащей дерево), на которую не работал "переход к основной таблице".
Стал работать вот такой код в run (в этом коде узнаётся emplId, дальше идёт по нему позиционирование дерева):

PHP код:

    try
    {
        fr=element.args().caller();
        if(fr)
        {
            for(i=1;i<=fr.dataSourceCount();i++)
            {
                common=fr.dataSource(i).cursor();
                dictTable = new DictTable(common.TableId);
                if(dictTable.fieldName2Id("EmplId"))
                {
                    emplId = common.(dictTable.fieldName2Id("EmplId"));
                    break;
                }
            }
        }
    }
    catch
    {
        emplId="";
    } 


[mazzy]

Цитата:

Изначально опубликовано Anais
(1) Я - программист и совет "старайтесь не программировать" - ну никак не ко мне

Не готов согласится.
Этот совет - именно программистам, именно вам.
В Аксапте решайте задачи пользователей, а не свои.

Так например, "список Тех.Мест - очень большой, но зато - четырехуровневый. Обязательно нужно иерархию, чтобы было удобно"
Четырехуровневая иерархия может быть сделана в одной таблице "универсальной" иерархией, а может быть сделана в одноуровневые четыре таблицы.

Теперь смотрите, пользователям как правило будет абсолютно все равно как вы это реализовали.
НО
Если вы реализуете это как "универсальную" иерархию, то вам придется программировать ВЕЗДЕ, где вы будете сталкиваться с этим своим чудесным объектов. Обратите внимание на слово ВЕЗДЕ. Это не только ввод и лукап. Это и фильтры, это и ОТЧЕТЫ.

Теперь посмотрите, что произойдет, если вы выберете четыре одноуровневые таблицы. Ввод, фильтры, лукапы работают как обычно. формы и отчеты накидываются простым drag'n'drop'ом. Массово программировать не придется.

Именно это я и имею в виду в призыве "не программируйте".



Теперь самый главный вопрос - можно ли в вашем случае использовать четыре одноуровневые таблицы вместо универсальных?

Вот это и есть ключевой момент. Если вы будете решать проблемы ваших ПОЛЬЗОВАТЕЛЕЙ, то вы обязательно должны разобраться в задаче, понять какие случаи являются ключевыми и существенными, а какие нет. Вы обязательно должны понять где будет бесконечное число вариантов, а где число вариантов строго ограничено. (Пример неправильного подхода в некоторых системах: ставки НДС сделаны жестким перечислением (enum), а признак пола м\ж сделан таблицей).

Если же вы решаете свои ПРОГРАММИСТСКИЕ задачи, то конечно же надо делать самый универсальный способ. Это же так интересно! Заставить работать иерархию в реляционной базе данных! Это же какая победа программиста! Любой программист это оценит, ей богу. Так и рождаются универсальные построители sql запросов, когда есть query, так рождаются динамические формы с произвольным числом реквизитов произвольного типа и т.п. Беда только в том, что ПОЛЬЗОВАТЕЛЮ это нафиг не нужно. Пользователю нужно решение ЕГО проблем. Желательно понятными для него способами.

Ваш пример также является типичным: Где в вашем задании было сказано, что вам нужно построить иерархию с бесконечным числом уровней? Мало того, я сильно подозреваю, что у вас в техзадании прописано назначение каждого уровня. Почему же вы начали делать именно "универсальную" иерархию, заранее зная, что это будет тяжелый" объект и заранее зная, что будут проблемы с правами доступа? Вы уверены, что решаете задачу пользователей, а не свою?

Вы считаете, что иерархия может поменяться в любой момент? Может, это всего лишь значит, что вы (или ваши постановщики) не до конца разобрались в задаче?

Anais, я конечно же могу ошибаться. Заранее приношу свои извинения.
Надеюсь, что у вас происходит правильное программирование.

В частности у вас очень хороший третий вопрос: "Модуль ТОРО в Axapta и без программирования? Очень, очень интересно. Честно. А на каком стандартном функционале его тогда реализовать?"

Да, действительно очень интересно.
Для начала давайте определимся с терминологией.
Итак что вы подразумеваете под термином TOPO? Что вы хотите от него получить?

[YVAS]

Цитата:

Изначально опубликовано mazzy

Итак что вы подразумеваете под термином TOPO? Что вы хотите от него получить?

ТОРО - техническое обслуживание и ремонт оборудования. Подразумевается учет технического оборудования, времени наработки, планирование ремонтов, смет затарт на них. Больше ничего не могу сказать.

[mazzy]

Чем ВАМ не нравится модуль проекты?

Обратите внимание, я знаю ответ на этот вопрос. Вопрос почему ВЫ не стали его использовать, а начали программировать. Кстати, в проектах уже есть иерархия...

и... черт этот вопрос мне самому не нравится, так как сильно смахивает на рекламу...
вы смотрели другие ГОТОВЫЕ решения от партнеров MSBS?
например, сервисные предприятия от Колумбуса?
Извините, я не помню других решений в этой области.

К чему это я... Я к тому, что программировать - это далеко не единственный способ получить результат. Мало того, до сих пор убеждежден что программирование стоит применять только тогда, когда не осталось других способов решить задачу. Так как программирование чертовски ЗАТРАТНОЕ дело.

[Anais]

Цитата:

Изначально опубликовано mazzy

Не готов согласится.
Этот совет - именно программистам, именно вам.
В Аксапте решайте задачи пользователей, а не свои.
...
Теперь самый главный вопрос - можно ли в вашем случае использовать четыре одноуровневые таблицы вместо универсальных?
...
Ваш пример также является типичным: Где в вашем задании было сказано, что вам нужно построить иерархию с бесконечным числом уровней? Мало того, я сильно подозреваю, что у вас в техзадании прописано назначение каждого уровня. Почему же вы начали делать именно "универсальную" иерархию, заранее зная, что это будет тяжелый" объект и заранее зная, что будут проблемы с правами доступа? Вы уверены, что решаете задачу пользователей, а не свою?
...

Всегда стараюсь решать задачи пользователей, а не делать программистские навороты, хотя бы потому что:
а. максимум результата при минимуме средств это, ИМХО, хорошо
б. сроки, обычно, поджимают
в. из программистских наворотов глюки еще потом по полгода вылавливаются

Действительно, список ТМ - четырехуровневый с жестко заданной структурой номера (я отрезала проверку номера от таблицы, когда проект выкладывала - чтобы она там жить не мешала).
Но, читаем по ТП:
Структура технических мест выстраивается в виде иерархического дерева.
... ... ...
Представление справочника ТМ возможно в виде:
Табличной структуры
Графической структуры.

И вот, на основании вот этой бумажки, ловят меня за жабры и говорят: ОБЯЗАТЕЛЬНО нужно графическое дерево. Без этого не прокатит!
И как мне в решении этой задачи поможет разбиение справочника на четыре таблицы по подуровням?

[mazzy]

Цитата:

Изначально опубликовано Anais
Структура технических мест выстраивается в виде иерархического дерева.
... ... ...
Представление справочника ТМ возможно в виде:
Табличной структуры
Графической структуры.

И вот, на основании вот этой бумажки, ловят меня за жабры и говорят: ОБЯЗАТЕЛЬНО нужно графическое дерево.

Anais, обратите внимание на слово ПРЕДСТАВЛЕНИЕ.
"нужно графическое дерево" это тоже ПРЕДСТВАЛЕНИЕ.
Я ж не против контрола с названием tree

Мы говорили о структуре ХРАНЕНИЯ.
Хранить можно каждый уровень в отдельной таблице, а затем Представлять это дело пользователю в виде treeView (если нужно).

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

Дело в том, что если бы вы выбрали другую структуру хранения, то, на мой взгляд, у вас не было бы таких жестких требований к программированию представления. Так 4 таблицы можно было бы представить 4 связанными гридами. Опять же - я отлично понимаю, что это не совсем то, что обычно имеется в виду под словом "иерархический". Но вы могли бы мышкой накидать 4 связанных грида и перейти к разработке вашего функционала. ПРЕДСТАВЛЕНИЕ в виде дерева можно было бы оставить на потом, если у вас останутся время, деньги и желание пользователей что-то менять.

Опять же, посмотрите как иерархия сделана в проектах. Как там открываются подпроекты.