восстановление предыдущего выделения объектов в проводнике по комбинации клавиш
- Автор темы Alexey
- Дата начала
не буду сейчас ничего говорить насчёт нескольких тысяч, но не далее чем сегодня возникла реальная ситуация, когда нужно было запомнить те самые 932 папки. не могу сказать, что подобные примеры возникают очень часто, но всё-таки они бывают
результаты кое-каких тестирований:
из 4322 папок восстановилось выделение у 3813 (при $iLogItems_Cache = 10,000) и у 4258 (при $iLogItems_Cache = 100,000)
неплохо бы было, конечно, точно знать количество, на которое можно спокойно рассчитывать
вот такой ещё вопрос (нужный, но не самый значимый):
в логе на одну папку приходится только один блок (по умолчанию в данный момент максимум блоков может быть 20,000)
не будет ли сложно сделать так, чтобы каждая папка имела не одну запись, а хотя бы 10? лучше, конечно, чтобы в #Region User Settings была возможность менять данный параметр по своему усмотрению. при появлении 11-го выделения внутри конкретной папки запись о первом стирается и 11-й сразу записывается на место десятого. пример того, как может выглядеть реализация всего этого для папки C:\z :
[1]
0=0x00060EB4
1=
2=C:\z
3=4.txt;6.txt
4=6;8
[2]
0=0x00060EB4
1=
2=C:\z
3=5.txt;6.txt
4=7;8
...
[9]
0=0x00060EB4
1=
2=C:\z
3=2.txt;7.txt
4=4;9
...
[14]
0=0x00060EB4
1=
2=C:\z
3=3.txt;4.txt
4=5;6
[15]
0=0x00060EB4
1=
2=C:\z
3=3.txt;4.txt;5.txt
4=5;6;7
...
[123]
0=0x00060EB4
1=
2=C:\z
3=6.txt;8.txt
4=8;10
это может понадобиться в определённых случаях (и при их наступлении будет данная возможность - просмотреть лог и увидеть небольшую историю выделений конкретной папки)
не будет ли сложно сделать так, чтобы каждая папка имела не одну запись, а хотя бы 10? лучше, конечно, чтобы в #Region User Settings была возможность менять данный параметр по своему усмотрению. при появлении 11-го выделения внутри конкретной папки запись о первом стирается и 11-й сразу записывается на место десятого. пример того, как может выглядеть реализация всего этого для папки C:\z :
[1]
0=0x00060EB4
1=
2=C:\z
3=4.txt;6.txt
4=6;8
[2]
0=0x00060EB4
1=
2=C:\z
3=5.txt;6.txt
4=7;8
...
[9]
0=0x00060EB4
1=
2=C:\z
3=2.txt;7.txt
4=4;9
...
[14]
0=0x00060EB4
1=
2=C:\z
3=3.txt;4.txt
4=5;6
[15]
0=0x00060EB4
1=
2=C:\z
3=3.txt;4.txt;5.txt
4=5;6;7
...
[123]
0=0x00060EB4
1=
2=C:\z
3=6.txt;8.txt
4=8;10
это может понадобиться в определённых случаях (и при их наступлении будет данная возможность - просмотреть лог и увидеть небольшую историю выделений конкретной папки)
пока буду продолжать тестировать - на данный момент не все нюансы я для себя уяснил (не покидает ощущение некоторой ненадёжности скрипта; не получается пока что окончательно понять, какие параметры лучше выставить)
- Сообщения
- 8,671
- Репутация
- 2,481
тогда не нужно заморачиваться. эта возможность лишней не была бы, но не это меня сейчас больше всего интересует
это понятно. имелось в виду, что хотелось бы понимать точнее, какое количество восстановленных выделенных объектов под силу программе, а при каком начинается ненадёжность. ориентировочно-то кое-как ясно - десятки/сотни восстановятся. но слегка некомфортно пользоваться и знать, что в любой момент программа может подвести и не восстановить должным образом выделение. хочу особо подчеркнуть - я ценю усилия, затраченные на написание данного скрипта и не пытаюсь выпендриваться, просто стараюсь максимально вежливо озвучить замеченные минусы
теперь о главном. поскольку много раз ужé доводилось компилировать, то была возможность заметить (далеко неоднократно), что:
- не всегда все выделения записываются в лог
- лог может вообще не создаться (иногда создаётся, иногда - нет)
расписал кратко, поскольку детально объяснить это всё сложно, а я, если честно, порядком подустал от того, что всё никак не удаётся добиться устойчивой работы без беспричинных сбоев; вероятно, если CreatoR вдруг не обнаружит ещё какие-то возможности для улучшения/исправления кода, придётся пользоваться программой вообще без лога; чего не хотелось бы делать, поскольку при этом в значительной степени уменьшаться возможности
вот всё, что я менял в скрипте:
Код:
Global $sLogFile = @WindowsDir & "\Temp" & "\SelectionRestorer.log" ;Log File Path
Global $iLogItems_Cache = 500 ;Log items cache
HotKeySet("#8", "_ExplorerRestoreSelection")ещё один очень важный замеченный досадный момент:
программа, по-видимому, работает только в одном конкретном окне проводника. если открыть ещё такой же, то в нём ужé ничего не работает. если переключиться на первый - работает. это очень существенный минус, поскольку зачастую у меня открыты и нужны для каких-то действий несколько проводников
- Сообщения
- 8,671
- Репутация
- 2,481
Alexey [?]
Теоритический - любое. Программа всего лишь посылает сообщение окну проводника о том что нужно выделить объект.
При $bWriteLogFileAlways = True пишет при каждом выделение.
См. выше.
Ещё раз повторяю, работа программы не полагается на лог, т.е от лока почти ничего не зависит.
Давай договоримся, ты сначала проверяешь скрипт в том виде в котором я его выложил, и в случае удачной работы начинаешь делать изменения в настройках ;)
Да, это обойти пока не удалось, видимо я в этом направлений копал недостаточно.
жаль, что до меня только сейчас дошло: пока программа работает только в одном конкретном окне проводника, то все остальные главные проблемы разом нивелируются по причине того, что использование лога в любом виде не имеет ни малейшего смысла (к большому сожалению), а выставление $iLogItems_Cache = 20,000 и подавно представляется чуть ли не фарсом. какие уж там 20,000 блоков, если истории выделений, записываемой в лог, суждено прожить в большинстве случаев считанные часы, а то и вовсе десятки минут (проводник всё-таки перезапускается мной время от времени)
тогда интересно было бы понять:
- с чем может быть связано то, что в ряде случаев (масштабных, с тысячами объектов) восстановление беспричинно обрывается, не дойдя до конца? ведь ничто не мешает завершить задание
- какова причина радикальной разницы в скорости восстановления? (в начале - не мгновенно, но достаточно быстро; ближе к концу - всё медленнее; в конце (если объектов хорошо за тысячу) - безумно медленно, выделение идёт буквально по жалкому десятку объектов в секунду)
то есть, при false программа может позволить себе не всегда в лог записывать? мне вот этот момент непонятен. получается, что в таком случае значение $bUseLogFile = True стаёт муляжом, ни на что не влияющим параметром - лог хоть типа и создаётся, но может и не создаться, в него что-то пишется, но может и не писаться
Добавлено:
Сообщение автоматически объединено:
только что попробовал пользоваться скриптом, отключив все настройки, имеющие отношение к логу, чтобы убедиться, что хотя бы основная функция работает, но не тут-то было
оказалось, что программа не просто работает только в одном конкретном окне проводника. она вообще отказывается работать, если это окно подверглось закрытию, а позднее запущено другое. выгружать и снова запускать её при появлении каждого нового окнá проводника мне представляется крайне неудобным занятием
судя по всему, варианты имеются следующие:
1) оптимальный - попытаться решить вот это:
2) сомнительно-обходной - прописать что-то типа автовыгрузки скрипта при закрытии проводника и автозагрузки скрипта при запуске проводника
третий вариант - оставить как есть и не пользоваться вообще, но об этом думать бы не хотелось
чуть позже мне стало ясно, что всё-таки эта функция тоже очень важна. по большому счёту, достаточно было бы истории, хранящей всего 2 выделения. это на те случаи, когда по ошибке выделение не снимается вообще, а каким-то образом меняется (ctrl+a, shift+home, shift+end...)
для меня это особо актульно по причине наличия ряда клавиш (F2, F3, F4, F5), назначенных как раз на изменение выделения
F2 - select to end
F3 - select to beginning
F4 - select all
F5 - select by type
F3 - select to beginning
F4 - select all
F5 - select by type
- Сообщения
- 8,671
- Репутация
- 2,481
Alexey [?]
Кстати есть идея как ускорить этот процесс в некоторых случаях. Например, если нужно восстанавливать число выделенных объектов превышающее число всех объектов в папке, то можно просто выделить всё, и снимать выделение с тех объектов которые не должны быть выделенный, так должно быть быстрее.
Это не так. Программа работает с заголовками.
Смысл в том чтобы восстановить настройки после перезапуска программы.
При чём здесь перезапуск проводника, я уже писал для чего нужны эти блоки.
С разными внешними программами, которые так или иначе действуют на проводник? у меня есть предчувствие, что у тебя их немло
Медленный процессор, забитая всяким хламом система?
Кстати есть идея как ускорить этот процесс в некоторых случаях. Например, если нужно восстанавливать число выделенных объектов превышающее число всех объектов в папке, то можно просто выделить всё, и снимать выделение с тех объектов которые не должны быть выделенный, так должно быть быстрее.
При False будет писать только при выходе, и только в случае если $bUseLogFile = True.
- Сообщения
- 8,671
- Репутация
- 2,481
Пытаюсь адаптировать тему к Win7.
Использую следующее:
http://www.autoitscript.com/forum/topic/89833-windows-explorer-current-folder/page__view__findpost__p__930963
http://forum.oszone.net/thread-213094.html
Единственная проблема, так это выделение файлов.
Есть свойство SelectItem, но во-первых оно выделяет файл и снимает выделение с других, а во-вторых очень медленно :(.
Использую следующее:
http://www.autoitscript.com/forum/topic/89833-windows-explorer-current-folder/page__view__findpost__p__930963
http://forum.oszone.net/thread-213094.html
Единственная проблема, так это выделение файлов.
Есть свойство SelectItem, но во-первых оно выделяет файл и снимает выделение с других, а во-вторых очень медленно :(.
