Latest post of the previous page:
NightRoman, и как мне это проверять?ps:$Dialog.StayOnTop = $true InvalidOperation: The property 'StayOnTop' cannot be found on this object. Verif y that the property exists and can be set.
Latest post of the previous page:
NightRoman, и как мне это проверять?ps:$Dialog.StayOnTop = $true InvalidOperation: The property 'StayOnTop' cannot be found on this object. Verif y that the property exists and can be set.
Code: Select all
$Global:Dialog = $Far.CreateDialog(-1, -1, 52, 4)
$Dialog.StayOnTop = $true
$b1 = $Dialog.AddBox(0, 0, 0, 0, 'box')
$t1 = $Dialog.AddText(1, 1, 50, 'text')
$Dialog.Open()
Code: Select all
ps: .\dialog.far.ps1
Code: Select all
ps: $Dialog.Close()
6457.NightRoman wrote: Sat 29 Mar, 2025 05:01 FarNet 9.0.19 включает экспериментальный флаг StayOnTop и должен быть доступен PowerShell скриптам.
Code: Select all
$Global:Dialog = $Far.CreateDialog(-1, -1, 52, 4)
$Dialog.StayOnTop = $true
$b1 = $Dialog.AddBox(0, 0, 0, 0, 'box')
$t1 = $Dialog.AddText(1, 1, 50, 'text')
$Dialog.Open()
Start-FarTask -Data Dialog {
Start-Sleep 5
job {
$Data.Dialog.Close()
}
}
Code: Select all
ps: .\dialog=2.far.ps1
Code: Select all
job {...}Code: Select all
far.SendDlgMessage dlg,F.DM_SETINPUTNOTIFY,1
Подписка на DN_INPUT нужна для получения событий от мыши и прочих сырых консольных сообщений (в отличии от DN_CONTROLINPUT туда приходят события об отпусканиях клавиш и пр.)
drive.moon не учитывается что в момент перезагрузки макросов активным может быть окно отличное от панелей
Code: Select all
lua:Keys"F4" far.MacroLoadAll()drive.moon.это просто пример, который я использовал для отладки.John Doe wrote: Sun 30 Mar, 2025 19:57 В drive.moon не учитывается что в момент перезагрузки макросов активным может быть окно отличное от панелей
пока — да.John Doe wrote: Sun 30 Mar, 2025 19:57 Собственно как я понимаю сейчас невозможно "привязать" диалог к не текущему окну.
а почему вы не хотите рассказать подробнее? я в реализации основываюсь на тех знаниях, что у меня есть. если есть какой-то полезный пример использования, а я его не знаю, то он абсолютно никак не влияет на мои действия.John Doe wrote: Sun 30 Mar, 2025 20:21Или мои элементы управления имеют смысл во всех редакторах, и я хочу не создавать отдельный aot-диалог для каждого редактора, а использовать единый.
это интересно, но возможно не все такие проблемы есть возможность сразу исправить.
оно разрешает приход DN_INPUT в диалоговую процедуру. в диалоги с флагом FDLG_STAY_ON_TOP пока (или не пока) DN_CONTROLINPUT не приходит, поэтому обработка DN_INPUT — это единственный способ получать ввод.
Поскольку речь о гипотетических примерах, подробнее можно только фантазировать.
и в чём преимущество перед персональными диалогами? минус, необходимость обрабатывать переключения окон и, если содержимое диалога уникально для каждого редактора, обновление содержимого диалога.John Doe wrote: Mon 31 Mar, 2025 19:40 Можно представить себе один "диалог", обрабатывающий все редакторы.
Гипотетически: в каких-то случаях (и на чей-то вкус) может быть рациональней, логика проще.
Мне вот это кажется вполне достойным примером:
Как и вообще любая панелька, взаимодействующая с окружением вне Фара и вне зависимости от того, что пользователь в данный момент делает в Фаре.
я точно с человеком разговариваю? я привёл конкретно то, что будет сложнее, вы выражаетесь максимально общими категориями.John Doe wrote: Mon 31 Mar, 2025 21:29Гипотетически: в каких-то случаях (и на чей-то вкус) может быть рациональней, логика проще.
хороший пример, и логика будет сложнее как раз у одного окна.John Doe wrote: Mon 31 Mar, 2025 21:29Если выдумывать пример, то сходу приходит на ум элемент управления, отображающий несколько элементов клипбоарда.
примером чего? полезности одного диалога на все редакторы?