Цитата:
Сообщение от
DSPIC
Вариант 1 плох: клиент-сервер таки нужно поддержать, если хочется перфекционизма
Так он и поддерживается. Просто не создается "двухпалубная" система классов обслуживания формы диалога. Ну, когда к исходникам, созданным на сервере, создается дубликат на клиенте
Т.е. стоим несколько "в раскоряку". Немного избыточный сетевой трафик.
Цитата:
Сообщение от
DSPIC
Вариант 2 плох: класс можно вызывать из кода, без диалога, если хочется перфекционизма
При вызове без диалога и проблемы нет, поскольку нет конфликта между созданием экземпляра класса на сервер и необходимостью открытия формы диалога на клиенте. Вне зависимости от способа реализации
Цитата:
Сообщение от
DSPIC
Вариант 3: там где-то метод можно перекрыть, что-то вроде allowSaveLast (либо метод, либо переменная, объявленная на уровне RunBase). Но, если не ошибаюсь, это поломает передачу параметром клиент/серер. Стоит проверить.
Переменная getLastCalled - определяет, был ли уже вызов метода getLast(). Есть метод по ее установке setGetLastCalled(), но он private. Т.е. из наследников не вызовешь
Т.е. я бы назвал это "хакерским трюком". Очень не стандартное решение. Будет предельно сложным в сопровождении такого класса в будущем
Цитата:
Сообщение от
DSPIC
Вариант 4: я бы шел классическим путем:
- сохраняем вашу переменную в pack/unpak как положено.
- в диалоге аналогично, стандартно, чтобы инициализировалось переменной.
- в методе main, принудительно вызываем getLast(), после чего обнуляем переменную. Вы же написали parm метод?
- ну и все. getLast() второй раз не вызывается, так задумано. Будущему программисту вы этим явно покажете, что сделано это осознанно. Универсальность класса сохранится - овцы сыты, волки целы.
Да, да. "И пастуху вечная память"
Смысл как раз в том, чтобы не делать различных "приседаний" вокруг создания с последующим обнулением переменных. Это как-то напрягает. Создать, чтобы тут же удалить.