Вопросы про RunBase

[Wamr]

Прошу прощения за формулировки вопросов.

1. имелся в виду "один из параметров, который выводится в диалог и пользователь может его сменить".
Я сомневаюсь, что dynalink в классах работает без программирования, а добавлять в диалог DS, чтобы с ним подвязался исходный курсор, как-то тоже "нелегкое" решение.
То что args в main принесет мне данные, я понимаю. Что дальше с ними делать? Пихать в объект через parm метод? А как к этому отнесется getLast при вызове диалога (известно как потрет нафиг)?

2. У меня было мнение, что при установке свойства класса CalledFrom и RunOn=Server на менюитем, получается диалог с пользователем на клиенте без лишнего общения с АОСом и исполнения функционала на сервере. Таким образом, мы можем управлять местом исполнения настройками менюитема. А сделав construct серверным, мы лишаемся такой возможности, не понятно что получив взамен.

[db]

Цитата:

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

Прошу прощения за формулировки вопросов.

1. имелся в виду "один из параметров, который выводится в диалог и пользователь может его сменить".
Я сомневаюсь, что dynalink в классах работает без программирования, а добавлять в диалог DS, чтобы с ним подвязался исходный курсор, как-то тоже "нелегкое" решение.
То что args в main принесет мне данные, я понимаю. Что дальше с ними делать? Пихать в объект через parm метод? А как к этому отнесется getLast при вызове диалога (известно как потрет нафиг)?

потрет. использую в таких случаях в main()
.getLast()
.parmXXX(...)
.saveLast()

[sukhanchik]

Цитата:

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

2. У меня было мнение, что при установке свойства класса CalledFrom и RunOn=Server на менюитем, получается диалог с пользователем на клиенте без лишнего общения с АОСом и исполнения функционала на сервере. Таким образом, мы можем управлять местом исполнения настройками менюитема. А сделав construct серверным, мы лишаемся такой возможности, не понятно что получив взамен.

Вообще-то - для кода один фиг - как он был вызван на сервере - при помощи установки свойства RunOn у менюитема, у класса или жестко зашит в construct.
С т.з. разработки - в целом тоже не сильно разнится - изменение свойства менюитема также относится к программированию, как и редактирование текста кода класса.

Разница лишь в том, что выставляя свойство RunOn=Server у менюитема - мы можем создать второй менюитем, не трогая класс, у которого поставить RunOn=Client.
В коде же (метод promptPrim) идет проверка - что если класс запущен на сервере и нет ограничений для создания копии себя на клиенте - то создается копия себя на клиенте. А если класс запущен изначально на клиенте - то копия класса не создается в принципе.

[Wamr]

Цитата:

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

Вообще-то - для кода один фиг - как он был вызван на сервере - при помощи установки свойства RunOn у менюитема, у класса или жестко зашит в construct.
...
В коде же (метод promptPrim) идет проверка - что если класс запущен на сервере и нет ограничений для создания копии себя на клиенте - то создается копия себя на клиенте. А если класс запущен изначально на клиенте - то копия класса не создается в принципе.

а теперь смотрим метод canSwapBetweenCSPrim
и видим, что копия делается только если класс CalledFrom

[sukhanchik]

Цитата:

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

2. В Tutorial_RunbaseBatch метод construct серверный. Таким образом, настройка RunOn в менюитем не играет никакой роли. Это так было задумано и считается правильным или просто так получилось в данном случаи?

Цитата:

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

а теперь смотрим метод canSwapBetweenCSPrim
и видим, что копия делается только если класс CalledFrom

Согласен. Но наличие серверного construct никак не связано с настройкой runOn у класса. Т.е. да, согласен - что создание копии на клиенте - связано со свойством RunOn у класса. Но с т.з. создании копии без разницы - что побудило ее создать - свойство RunOn у менюитема или серверный construct