SysLookupMultiselectCtrl отметить значения

[Lankey]

Хорошая идея, спасибо
Я попробовала, но, когда указываю Max (RecId) в запросе, что использую потом во view, то view создается с константным значением(1010 в моем случае) в колонке RecId, а не результатом агрегатной функции
(я посмотрела сформированный запрос на стороне sql server select....Myfield as Myfield, 1010 as RecId from MyTable group by Myfield)
Пробовала поменять на Min - то же самое происходит.

Попробовала без запроса, т.е напрямую во view выбрать max(RecId), но он тогда колонку переименовывает в RecId1 (и выдает ошибку "Cannot rename RecId1 to RecId . Table field name cannot be the same as system defined name")

[Lankey]

Попробовала с временной таблицей, но не понимаю, каким образом ее буфер передать в SysLookupMultiselectGrid? (Тут нет parmTmpBuffer() как на SysTableLookup )
Есть какая-то возможность это обойти?

[SRF]

Если говорить про техническую реализацию, то примеры есть в стандарте - класс EREnumLookupMultiSelectGrid, метод new, передача через QueryRun.

        container selectedFields = [tableNum(SysOperationMultiSelectTmp), fieldName2id(tableNum(SysOperationMultiSelectTmp), fieldStr(SysOperationMultiSelectTmp, Values))];

        selectTableTmp = this.getMultiSelectTableForEnum(_enumId, _valuesToSkip);

        QueryRun localQueryRun = SysOperationHelper::getMultiSelectQueryRun(selectTableTmp);
        
        this.parmCallingControl(_targetStringControl);
        this.parmQuery(localQueryRun.query());
        this.parmQueryRun(localQueryRun);

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

Также можно в качестве времянки использовать TempDB, заполнять ее прямым запросом через Query::insert_recordset, будет работать быстро, но выглядит это все как какой то Overengineering, ради лукапа.

Я бегло посмотрел по перекрестным ссылкам в стандарте, есть пример (да там нет группировки, может быть можно сделать примерно так же - скрытый контрол с recId - StatisticsOnInvoiceUIBuilder?).

    private void initPostingProfilesDialogField()
    {
        DialogField postingProfilesField = this.bindInfo().getDialogField(this.dataContractObject(), methodStr(StatisticsOnInvoiceDataContract, parmPostingProfiles));
        postingProfilesField.registerOverrideMethod(
            methodStr(FormDateControl, lookup),
            methodStr(StatisticsOnInvoiceUIBuilder, postingProfilesLookup),
            this);
        postingProfilesField.lookupButton(FormLookupButton::Always);

        SysOperationDialog reportDialogBox = this.dialog();
        postingProfilesRecIdsControl = reportDialogBox.formRun().design().addControl(FormControlType::String, PostingProfilesRecIdsControlName);
        postingProfilesRecIdsControl.visible(false);
    }

    private void postingProfilesLookup(FormStringControl _postingProfilesControl)
    {
        Query query = new Query();
        QueryBuildDataSource qbds = query.addDataSource(tableNum(VendLedger));
        QueryBuildFieldList qbfl = qbds.fields();
        qbfl.dynamic(false);
        qbfl.clearFieldList();
        qbfl.addField(fieldNum(VendLedger, PostingProfile));
        qbfl.addField(fieldNum(VendLedger, Name));

        container selectFields = [ tableNum(VendLedger), fieldNum(VendLedger, PostingProfile) ];

        SysLookupMultiSelectGrid::lookup(
            query,
            _postingProfilesControl,
            postingProfilesRecIdsControl,
            _postingProfilesControl,
            selectFields);
    }

Если все же нельзя, то может сделать свою лукап-форму ? расширить функционал базового класса, чтобы можно было скрыть контрол с recId ?

[Lankey]

Цитата:

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

Если говорить про техническую реализацию, то примеры есть в стандарте - класс EREnumLookupMultiSelectGrid, метод new, передача через QueryRun.

Гениально. Спасибо большое! Сделала, опираясь на этот пример. Все работает!

А какая раница между Lookup vs OnLookup в 365?

На контроле формы (форма тут моя, в моей модели, т.е кастомная) доступен метод Lookup() и его можно переопределить в коде формы. В вышеуказанных примерах стандарта именно он используется.

Я делала изначально через класс event handler и там описала OnLookup контрола. Вроде, оба, и Lookup и OnLookup, отрабатывают. То есть, нет разницы. Только писать лишний класс ради одного метода-обработника события как-то слишком. Думаю оставить подход через lookup

[sukhanchik]

Цитата:

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

А какая раница между Lookup vs OnLookup в 365?

Для своей формы технически разницы нет. Однако с т.з. дальнейших раскопок кода всё-таки лучше как-то договориться внутри команды разработки об использовании единого подхода (мне, лично нравится Lookup)

Разница появляется тогда, когда надо сделать расширение и нет возможности сделать / использовать Lookup. Тогда использование event handler-а очень помогает. Правда тут опять-таки подводный камень в том, чтобы договориться внутри команды разработки об использовании единого подхода. Иначе можно написать много разных Event Handler-ов в разных классах, после чего они все дружно вызовутся, пользователь удивится, а разработчик, который будет искать эту ошибку - долго будет искать причину проблемы.