akvvohinc

Igor Korolyov
_screen.activeform периодически будет "not an object". Напрямую так писать нельзя - надо проверками окружать...

Taran
Вторым постом в данной теме надо было сказать про activeform и забыть.

Как же забыть, если самое интересное как раз и начинается после "not an object"?
Неужели у ТС не возникнет вопрос "И что делать?"
Ну, проверили мы и получили этот "необъект", а дальше?

1) ждать, когда "not an object" станет "object";
2) заставить необъект стать объектом;
3) наплевать, что команда в этот раз не будет выполнена ("Ну не шмогла я, не шмогла!");
4) наплевать на нестабильно работающий способ, заменив его на надежный (может, KeyPress()? ) ;
5) что-то еще...

Стояли на форме, запустилась функция и из неё модальная форма.
Модальная закрылась и кто станет активным как не предыдущая?
Пунктов всяких размышлительным можно и более пяти наваять.
И прогу писать левой ногой, а потом обработчик ошибок на тыщу строк.
Здесь пяток профессоров не могут прийти к консенсусу, а ты ТС что предлагаешь?
Я предложил элементарное решение его проблемы.
Потом вырастет.

Т.е. его =seek() в первом посте не смущает и ни о чем не намекает?

Но... Если платят за строки, то это понятно.

Igor Korolyov
Смысла что-то делать с неактивной формой нет.

Не совсем понял - какая разница, в какой форме (активной или нет) нам надо проделать какие-то манипуляции с объектами из обработчика?

Олег решил что всегда в активной.
Возможно, в том конкретном примере активная форма и форма, в которой нужно что-то сделать из обработчика, - одна и та же форма. Но в общем случае это может быть и не так.

Так что - каждую ситуацию решать разными способами или все же каким-то способом всегда передавать обработчику нужную ссылку?

Igor Korolyov
В любом случае никакой KeyPress в такой ситуации всё равно не сработает - просто до него не дойдёт дело, если форма не активна

Я не это имел в виду, и не конкретный пример ТС, а использование activeform внутри обработчика в общем случае:
1) В активной форме нажимается нужная кнопка;
2) С помощью ON KEY LABEL или KeyPress вызывается обработчик;
и уже находясь в обработчике в нужный момент либо не станет активной формы, либо изменения требуется сделать в неактивной форме.

Taran
Т.е. его =seek() в первом посте не смущает и ни о чем не намекает?

Без твоих пояснений - не намекает (да я и не вдумывался в то, что делает его обработчик - ведь не в этом суть).
Я тоже пользуюсь этой функцией время от времени.

akvvohinc

Igor Korolyov
Смысла что-то делать с неактивной формой нет.

Не совсем понял - какая разница, в какой форме (активной или нет) нам надо проделать какие-то манипуляции с объектами из обработчика?

При чём тут какие-то объекты из обработчика?
Стоит вопрос - отловить нажатие кнопки и запустить метод формы. Метод формы всегда имеет доступ к форме, даже если он чего-то "левое" вызывает, он может передать ссылку на форму. нигде далее - никаких _screen.activeform не требуется.
А вот для отлова кнопки - в случае использования ON KEY LABEL или же пункта главного меню (возможно с хоткеем) - как раз удобнее всего _screen.activeform использовать.
НО ни нажатие хоткея, ни выбор пункта меню не имеют смысла если форма НЕ активна - ну банально ж не понятно к какой из открытых но неактивных форм это действие следует применить. Потому твои 5 вариантов имеют лишь 1 разумный пункт - забить.

akvvohinc
Олег решил что всегда в активной.

Напомню - речь идёт про ON KEY LABEL - смысла этой конструкции работать НЕ с активной формой нет никакого, абсолютно.
Про какой-то гипотетический код вне формы слева речи НЕ шло. Но если бы вдруг и зашла речь, то всё свелось бы опять же к точке вызова этого гипотетического кода - и это был бы либо метод формы (где не проблема взять и передать далее ThisForm) либо тот самый пункт меню/on key label - где см.выше, либо _screen.activeform (с защитной проверкой), либо, если он таки null, вообще ничего не делать, т.к. понятие "активная неактивная форма" - просто бред.

akvvohinc
Я не это имел в виду, и не конкретный пример ТС, а использование activeform внутри обработчика в общем случае:
1) В активной форме нажимается нужная кнопка;
2) С помощью ON KEY LABEL или KeyPress вызывается обработчик;
и уже находясь в обработчике в нужный момент либо не станет активной формы, либо изменения требуется сделать в неактивной форме.

Естественно в код (если это не метод формы) следует явно передать ссылку на тот объект для которого данный код предполагается использовать. А не пытаться брать что-то из _screen.activeform. Из контекста где "активная форма" всё ещё активна (on key label), или же она и есть ThisForm (KeyPress) для вызывающего "левое действие" кода.
В общем проблемы нет ну вообще никакой

Igor Korolyov
Стоит вопрос - отловить нажатие кнопки и запустить метод формы. Метод формы всегда имеет доступ к форме, даже если он чего-то "левое" вызывает, он может передать ссылку на форму. нигде далее - никаких _screen.activeform не требуется.

В чем разница между "запустить метод формы" и "запустить сторонний PRG"?
Наверно в том, что в методе формы мы можем свободно манипулировать ее объектами.
Но кто решил, что манипулировать всегда требуется объектами той формы, которая была активна в момент нажатия кнопки?
И чем тогда метод формы лучше любого PRG?

Ну, есть у нас "прямой" доступ к одной из форм - с ней работаем через _screen.activeform, а с остальными?
Так почему бы не использовать единый способ общения?

Из примера ТС - допустим по нажатию F2 на форме A ему бы в результате потребовалось "преобразить" форму B.
Метод какой формы будет это делать? Поможет здесь _screen.activeform?



Исправлено 1 раз(а). Последнее : akvvohinc, 18.11.19 01:46

Балаболы.

_screen.activeform нужен в on key label, в обработчиках пунктов главного меню, ну может ещё в 1-2 сильно специфических местах.
Более он нигде не требуется. Если какому-то коду требуется доступ к некоторой форме (и это не ThisForm), то ссылку на данную форму в этот код необходимо передать ЯВНО.