06.03.2019, 21:13 | #1 |
Участник
|
Denis Trunin's Blogs: Tool to filter in a query as a developer
Источник: https://denistrunin.com//xpptools-queryfieldsaotname/
============== X++ tool that adds a system field name in a standard query filter field lookup Источник: https://denistrunin.com//xpptools-queryfieldsaotname/
__________________
Расскажите о новых и интересных блогах по Microsoft Dynamics, напишите личное сообщение администратору. |
|
06.03.2019, 23:05 | #2 |
Участник
|
такую штуку бы ещё в Personalization-Add field добавить, а то никак не догадаешься, какое из 4 одинаковых полей твоё
__________________
Felix nihil admirari |
|
07.03.2019, 03:35 | #3 |
Участник
|
Ага, хорошая идея, добавил
https://github.com/TrudAX/XppTools#-...e-query-filter |
|
|
За это сообщение автора поблагодарили: sukhanchik (15). |
07.03.2019, 10:34 | #4 |
Участник
|
Цитата:
А я еще делал такую настройку: 1. Выбор формата как показывать Xppname/Label или Label/Xppname. Как показывает практика, аналитикам удобнее смотреть когда первым значением идет метка. А программистам удобнее когда в начале идет X++ наименование. По ним же и сортировка идет. 2. Возможность игнорировать опцию AllowAdd для поля. Ее значение по дефолту - Restricted, что приводит к тому что если поле не выведено на форму то штатным средством его уже не выведешь. Так вот, иногда бывает полезно игнорировать значение Restricted и считать что можно добавить. Это делается одной строкой кода. |
|
|
За это сообщение автора поблагодарили: trud (2). |
07.03.2019, 12:09 | #5 |
Administrator
|
Это в 2012. В D365 так может и не получиться. Проект-то по D365.
Впрочем надо исследовать
__________________
Возможно сделать все. Вопрос времени |
|
|
За это сообщение автора поблагодарили: Logger (3). |
07.03.2019, 13:44 | #6 |
Участник
|
Цитата:
Цитата:
Сообщение от Logger
2. Возможность игнорировать опцию AllowAdd для поля. Ее значение по дефолту - Restricted, что приводит к тому что если поле не выведено на форму то штатным средством его уже не выведешь. Так вот, иногда бывает полезно игнорировать значение Restricted и считать что можно добавить. Это делается одной строкой кода.
|
|
07.03.2019, 14:15 | #7 |
Участник
|
Про синхронизацию не совсем понял.
Если вы про хранение опций в настроечной табличке, которую надо создавать при установке, то можно этого избежать. Чем-нить типа SysLastValue / pack / unpack. |
|
07.03.2019, 15:13 | #8 |
Участник
|
В 2012-й для добавления полей это
\Classes\SysSetupForm\fieldTreeAddFields в нем X++: ... switch (formDataObject.allowAdd()) { case FormAllowAdd::Restricted: ... Возможно в 365-й это не сработает. Надо смотреть. |
|
11.03.2019, 07:23 | #9 |
Участник
|
|
|
11.03.2019, 08:38 | #10 |
Administrator
|
Пока на примере формы групп клиентов я вижу, что можно добавить все поля, кроме системных и ссылочных (в частности, DefaultDimension)
Интересный момент, связанный с формой InventOnhandItem. В InventSum добавили поле InventIsExcludedFromInventoryValue, но форму после этого не восстановили. В результате в форму это поле добавить нельзя, но его и нет в списке полей датасорса. Восстановление же формы - добавляет поле в список полей датасорса, но тогда считается, что форма изменена, а изменение стандартного кода запрещено . В результате - все остается как и было. Но все эти примеры неполноценные - на формы выведены по сути все поля таблицы.
__________________
Возможно сделать все. Вопрос времени |
|
|
|