Latest post of the previous page:
Добавил пункты 5..9 к замечаниям.И пункты 4..5 к багам.
Как это может быть на практике? Ввели из командной строи нечто типа macro:load ? Ну да, такого я не рассматривал. Как-то это нежизненно. Да и не знаю, как сделать. А разбираться ради какой-то нереальной ситуации - ну это ж не моя работа. Просто сделал удобное, решил поделиться.
И что делать? Типа если не получилось, так и не выполнять ничего?
Да, я знаю. Я писал среди того, что не сделано, но хотелось бы - блокировку сохранения. Как это сделать, я не знаю. Знаю, правда, где смотреть, но дело опять упирается в то, что мне долго... А Вы можете сделать это быстро: наверняка есть опыт...
Спасибо, посмотрю. Там что-то про editor.RealToTab, кажется.
Очень даже жизненно. И для этого есть event: ExitFAR.
Что-то типа этого:
Code: Select all
local ei=editor.GetInfo()
if not ei then return end
Сказано же: EE_SAVE
Нажмите кнопку с кавычкой, и узнаете.
Я же не знаю идеологии: в какой момент выполняется присвоение в локальную переменную; если макрос вызывается из нескольких редакторов, то (а) будет ли вызываться этот оператор каждый раз, или только при загрузке макроса в память единожды; (б) возвращает ли вызовJohn Doe wrote: Что-то типа этого:Code: Select all
local ei=editor.GetInfo() if not ei then return end
editor.GetInfo()
одну и ту же таблицу, или зависит от копии редактора. Ну и интересно всё же узнать условия, при которых GetInfo() может возвращать nil... При том, что макрос вызван из редактора. Впрочем, я сделаю как Вы написали, это не проблема.ExitFAR
и EE_SAVE
- опять возвращаемся к обработке событий, которую я не понял совсем. И документация написана какими-то назывными предложениями; по-моему, чтобы её прочитать, надо сначала прочитать инструкция к инструкции... Основной блок выполняется однократно, при загрузке (и перезагрузке) скрипта.
Разные экземпляры таблиц в любом случае. Или я не понял вопроса.
Бывают определённые условия.
Но EditorInput вы же как-то обрабатываете.
Вот в этом случае как раз и возникал Stack overflow. И это - ещё до того, как я стал "оперировать" с цветами, делал только Editor.SetTitle. Насколько я понимаю, причина была в том, что при SetTitle возникает событие EE_REDRAW, что вызывает обработчик и т.д. . И блокировка типа переменной Processing=true не помогала (возможно, из-за того, что перерисовка происходила асинхронно). Короче, с EE_REDRAW у меня не получилось.
AltBS
для восстановления первоначального состояния файла, но после перезагрузки macro:load
это не срабатывает.Делать временную копию файла как-то некрасиво, плохой стиль... Уж очень по-микрософтовски... Хотя, наверно, некоторые проблемы и решились бы, но противно... Если б можно было редактировать некий файл в памяти... Но я не знаю, как это сделать.
Исправлено...
В мануале есть статья Ограничения в использовании некоторых функций
Проверил с editor.UndoRedo, не пропадает.
Созданный файл и будет только в памяти, до тех пор пока его явно не сохранить.
Пункт 1 надо лучше было понять буквально.
На это уже ответил выше под спойлером.
Естественно! Информация-то меняется.buniak_a_h wrote:Увы, editor.GetInfo приходится вызывать каждый раз, когда делается что-нибудь (перемещение по файлу, выход с или без сохранения позиции).
Отступы используются без системы, что делает применение скрипта к собственному коду проблематичным. Прямо парадокс какой-то.
Это не так, и проверяется легко.
Так и делал. Всё падало при добавлении editor.SetTitle() .
Code: Select all
local F = far.Flags
Event{
group="EditorEvent";
action=function(EditorID,Event,Param)
if Event==F.EE_REDRAW then
editor.SetTitle(EditorID,tostring(EditorID))
end
end
}
На самом деле они каждый раз инициализируются перед вызовом
action
в процедуре condition
. Я подумал, что вся клауза action
выполняется как одна транзакция, т.е. переключение на другой контекст до выхода из функции невозможно. Это не так? Если это так, то хуже стать всяко не должно... Или condition выполняется не всегда при нажатии на соответствующую горячую клавишу?Зачем гадать, не легче ли прочитать соответствующую статью в документации (macroapi_manual.ru.chm), она не такая большая и не такая сложная. Это избавит вас от необходимости задавать вопросы, по которым сразу становится ясно, что документацию вы не читали.
Я понимаю.
Разбил на две функции (проверки наличия контекста редактора и активности макроса) при борьбе с ExitFAR. Не получилось, но возвращать обратно не стал, т.к. не мешает.
1. Не нужно каждый раз писать проверку, не nil ли GetInfo()
action{/c]. А какая разница? Тоже самое, но один раз написал и забыл. Впрочем, дело вкуса.
3. А общие переменные для всех функций в данном случае, по-моему, это правильно. Отражает, что это - реально одно и то же.
[quote="Shmuel"][post]131522[/post] Зачем гадать, не легче ли прочитать соответствующую статью[/quote]
Прочитал, потому и был спокоен. Раз появились замечания, то (а) я неправильно понял описание; или (б) описание не соответствует программе (программирую с 1974-го года, с таким сталкивался часто. Если Вы не сталкивались - что ж, молод истчо! :quiet: ); или (в) из-за ошибки в программе есть ситуации, когда [b]condition[/b] не выполняется. Или в ФАРе нет ошибок?