Проблема с controlMethodOverload при выполнении на Сервере.

[oip]

Здравствуйте. В этой теме есть пример использования метода formRun().controlMethodOverload(). Однако, если сделать в том проекте небольшое изменение, а именно место выполнения класса заменить с "Called from" на "Server" и запустить его в трехуровневой конфигурации, то все сразу валится. Объясните пожалуйста, в чем дело и можно ли этого избежать?

[Delfins]

imho, forma eto klientskaja chast'...

[oip]

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

[sukhanchik]

Класс может исполняться где угодно. Форма может быть только на клиенте. Наследник RunBase - может исполняться на сервере - но форма, которая рисуется этим классом - создается на клиенте. FormRun должен быть проинициализирован на КЛИЕНТЕ. В частности - RunBase - несмотря на то, что создается на сервере - он сам делает клиентскую копию себя, откуда и работает с формой. А данные просто передает через контейнер между экземплярами классов.

[vallys]

Quote:

Originally Posted by sukhanchik

... RunBase - несмотря на то, что создается на сервере - он сам делает клиентскую копию себя, откуда и работает с формой. А данные просто передает через контейнер между экземплярами классов.

Хм... Думаю, что RunBase (вернее его наследник) делает клиентскую копию себя только если "Run on" равно "Called from" и экземпляр RunBase создан на сервере. Это можно увидеть в RunBase.PrompPrim():

...
// Move prompt to client when running on server and the class is swappable
if (isRunningOnServer() && this.canSwapBetweenCS() && this.canSwapBetweenCSPrim())
{
    [clientPrompt,clientPacked] = runbase::promptOnClient(classidget(this),this.promptPack());
    this.promptUnpack(clientPacked,clientPrompt);
    return clientPrompt;
}
...

Если "Run on" равно "Server", то создается клиентская копия Dialog - см. Dialog.doRun() и Dialog::runOnClient(). Соответственно в метод RunBase.dialogPostRun() передается серверный Dialog у которого формы нет, а клиентский (c формой) остается 'в тени'.

Quote:

Originally Posted by oip

Т.е. если класс выполняется на сервере, то ничего не поделаешь?

IMHO лучше "Run on" выставлять в "Called from" и создавать экземпляр RunBase на сервере принудительно. Получим и Dialog на клиенте (со всеми DialogField и формой) и выполнение RunBase.run() на сервере.

[oip]

vallys, у того класса, с которым я имею дело (LedgerJournalCopyPeriodic) и где я хотел применить controlMethodOverload стоит "Server".

[sukhanchik]

Quote:

Originally Posted by vallys

Хм... Думаю, что RunBase (вернее его наследник) делает клиентскую копию себя только если "Run on" равно "Called from" и экземпляр RunBase создан на сервере. Это можно увидеть в RunBase.PrompPrim():

...
// Move prompt to client when running on server and the class is swappable
if (isRunningOnServer() && this.canSwapBetweenCS() && this.canSwapBetweenCSPrim())
{
    [clientPrompt,clientPacked] = runbase::promptOnClient(classidget(this),this.promptPack());
    this.promptUnpack(clientPacked,clientPrompt);
    return clientPrompt;
}
...

ага ... согласен... только тут нигде нет упоминание свойства RunOn. Только проверка - создан ли экземпляр класса на сервере или нет. А значит без разницы - какое значение принимает свойство RunOn - лишь бы оно позволло создать класс на сервере

[vallys]

Quote:

Originally Posted by sukhanchik

ага ... согласен... только тут нигде нет упоминание свойства RunOn. Только проверка - создан ли экземпляр класса на сервере или нет. А значит без разницы - какое значение принимает свойство RunOn - лишь бы оно позволло создать класс на сервере

Есть проверка - в RunBase.canSwapBetweenCSPrim

/*
Returns whether it is possible to pack the class, reinstantiate a new class, and unpack it on the "other" side.
*/
private boolean canSwapBetweenCSPrim()
{
    return new dictClass(classIdget(this)).runMode() == ClassRunMode::Called;
}

[vallys]

Quote:

Originally Posted by oip

vallys, у того класса, с которым я имею дело (LedgerJournalCopyPeriodic) и где я хотел применить controlMethodOverload стоит "Server".

Тогда придется иметь дело с Dialog на клиенте ... Думаю без модификации Dialog или RunBase не обойтись...
Например, можно у Dialog создать методы Dialog.dialogOnClient() и Dialog.setDialogOnClient():

Dialog dialogOnClient()
{
    return dialogOnClient;
}

void setDialogOnClient(Dialog dialog)
{
    dialogOnClient = dialog;
}

переменную dialogOnClient, естественно, добавить в ClassDeclaration, добавить вызов Dialog.setDialogOnClient() в Dialog::runOnClient():

...
dialogClient.unpack(dialogCon);
dialogClient.setDialogOnServer(dialogServer);
// тут -->
dialogServer.setDialogOnClient(dialogClient);
// <--
Dialog::addControls(
...

Тогда в RunBase.dialogPostRun(_dialog) имеем доступ к клиентскому Dialog

public void dialogPostRun(DialogRunbase _dialog)
{
    ;
    super(_dialog);
    _dialog.dialogOnClient().dialogForm().formRun().controlMethodOverload(true);
    _dialog.dialogOnClient().dialogForm().formRun().controlMethodOverloadObject(this);
}

В медодах fld1_1_modified() и fld2_1_lookup() тоже использовать клиентский Dialog, не забывая что все экземпляры DialogField, созданные в RunBase.dialog() принадлежат серверному Dialog

public boolean fld1_1_modified()  // fieldUpdateMethod
{
    Boolean ret;
    Object  control = dialog.dialogOnClient().formRun().controlCallingMethod();
    ;
    ret = control.modified();
    if (ret)
    {
        dialog.dialogOnClient().name2dialogClass().lookup(DialogRContractAccount.name()).value('');
    }
    return ret;
}

public boolean fld2_1_lookup()  // fieldUpdateMethod
{
    Boolean ret;
    Object  control = dialog.dialogOnClient().formRun().controlCallingMethod();
    ;
    RContractTable::lookupByCust(control, dialog.dialogOnClient().name2dialogClass().lookup(DialogRContractAccount.name()).value());
    return true;
}

Написал из головы - на практике не проверял

[oip]

Понятно. Если все так сложно, то проще нарисовать собственную лукап форму и не мучиться. Спасибо! Обязательно попробую на своем локальном приложении то, что Вы написали, но для рабочего приложения это точно не приемлимо, думаю.

[sukhanchik]

Quote:

Originally Posted by vallys

Есть проверка - в RunBase.canSwapBetweenCSPrim

/*
Returns whether it is possible to pack the class, reinstantiate a new class, and unpack it on the "other" side.
*/
private boolean canSwapBetweenCSPrim()
{
    return new dictClass(classIdget(this)).runMode() == ClassRunMode::Called;
}

Эх... придется посыпать голову пеплом.... по крайней мере сейчас - и повнимательнее посмотреть RunBase....
В общем - был неправ.

[vallys]

Quote:

Originally Posted by oip

Понятно. Если все так сложно, то проще нарисовать собственную лукап форму и не мучиться. Спасибо! Обязательно попробую на своем локальном приложении то, что Вы написали, но для рабочего приложения это точно не приемлимо, думаю.

Блин, ёмаё! Забыл совсем Для того, чтобы Dialog создавался на клиенте достаточно в методе Runbase.dialog() в super() вторым параметром (forceOnClient) подставлять true. И все!

[oip]

Оп-па... На проекте msk_TutorialRunBase все отлично работает! Спасибо! Неужели все так просто было? Во вторник проверю на рабочем приложении на нужном мне классе.

ЗЫ Жаль не могу репутацию поднять, т.к. уже поднимал.