[zipo]

Кто столкнется с такой же проблемой, то сделал такой солюшен:

В класс RunBaseReportStd добавляем такой метод

public void dialogPostRun(DialogRunbase dialog)
{
    ;
    super(dialog);
    reportRun._dialogPostRun(dialog);
}

В класс SysReportRun добавляем такой метод

public void _dialogPostRun(DialogRunbase dialog)
{
    ;
    if (this.reportHasMethod(methodstr(RunbaseReportStd, dialogPostRun)))
    {
        this.thisObject().dialogPostRun(dialog);
    }
}

Хоть это и изменение стандартных классов, ни к чему страшному это не приведет. Это просто добавление того функицонала который почему-то забыли сделать в стандартном RunBaseReportStd фрейм ворке, что бы включить функцию оверлоадинга

Дальше идет по обычной схеме, хотя она немного изменена:
Добавляем следующий метод в наш репорт:

public Object dialogPostRun(DialogRunbase _dialog)
{
    ;
    _dialog.formRun().controlMethodOverload(true);
    _dialog.formRun().controlMethodOverloadObject(dialogEvents);

    return _dialog;
}

dialogEvents - это экземпляр класса, который я инициализирую в репорте на init методе. Почему так каряво? Потому как обычный this или element не работает, скорее всего на оверлоадинг умеет проверять наличие метода только у класса. Поэтому нужен именно класс.

В классе dialogEvents у меня есть метод

boolean DateRange_modified()
{
    ;
    info("111");
    return true;
}

Где DateRange имя моего поля, метод прекрасно срабатывает на изменение этого поля, поэтому можно все обработать, т.к. легко сделать этому классу доступ к репорту.
Солюшен может показаться с подвыпердоворотом, но он надежен и исполняет свою функцию.