Всегда ли надо прописывать список переменных в pack?

[Владимир Максимов]

Цитата:

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

Вариант 1 плох: клиент-сервер таки нужно поддержать, если хочется перфекционизма

Так он и поддерживается. Просто не создается "двухпалубная" система классов обслуживания формы диалога. Ну, когда к исходникам, созданным на сервере, создается дубликат на клиенте

Т.е. стоим несколько "в раскоряку". Немного избыточный сетевой трафик.

Цитата:

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

Вариант 2 плох: класс можно вызывать из кода, без диалога, если хочется перфекционизма

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

Цитата:

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

Вариант 3: там где-то метод можно перекрыть, что-то вроде allowSaveLast (либо метод, либо переменная, объявленная на уровне RunBase). Но, если не ошибаюсь, это поломает передачу параметром клиент/серер. Стоит проверить.

Переменная getLastCalled - определяет, был ли уже вызов метода getLast(). Есть метод по ее установке setGetLastCalled(), но он private. Т.е. из наследников не вызовешь

Т.е. я бы назвал это "хакерским трюком". Очень не стандартное решение. Будет предельно сложным в сопровождении такого класса в будущем

Цитата:

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

Вариант 4: я бы шел классическим путем:
- сохраняем вашу переменную в pack/unpak как положено.
- в диалоге аналогично, стандартно, чтобы инициализировалось переменной.
- в методе main, принудительно вызываем getLast(), после чего обнуляем переменную. Вы же написали parm метод?
- ну и все. getLast() второй раз не вызывается, так задумано. Будущему программисту вы этим явно покажете, что сделано это осознанно. Универсальность класса сохранится - овцы сыты, волки целы.

Да, да. "И пастуху вечная память"

Смысл как раз в том, чтобы не делать различных "приседаний" вокруг создания с последующим обнулением переменных. Это как-то напрягает. Создать, чтобы тут же удалить.