How to remap Ctrl + Mouse Wheel Up/Down to scroll left/right instead of changing view?

[Jack66]

I am using the most current version for both:

Version 1.5.0.1262a (x64)
and
Version 1.4.1.1015 (x64)

I've been running the beta version for a while now and it's amazing, and somehow I am able to press - Ctrl + Mouse Wheel Up/Down - to scroll left/right to access the columns that overflow the edges.

But for the other, normal version, it's stuck on changing the view. I'm assuming for the beta version it possibly defaults to that? No, I can't remember, but regardless of what it defaults to, I would have searched hard for the solution.

If I did figure it out before, I can't remember now. I also can't find the page that helped me figure it out. I've been trying to figure this out for a while, but I got tired of searching, so I figured I'd ask.

I found this post and did that in the about:config in Firefox, but it didn't fix it for me, as I said it works with my beta version but not the original.

[raccoon]

You can change the mouse_wheel actions in 1.5 via custom ini config commands. They are explained at the page below.

viewtopic.php?f=12&t=9994#ctrl_mouse_wheel_action

Type the command, eg, /ctrl_mouse_wheel_action=3 to make ctrl+wheel perform a horizontal scroll.

By default, this is already the action of shift+wheel

@void: It may be useful for these wheel behaviors to be added to about:keys

[NotNull]

When you are using Everything 1.5 - the alpha version is available for testing - you can use the ctrl_mouse_wheel_action setting.

In your case: enter the following in the search bar and press ENTER:

Code: Select all

/ctrl_mouse_wheel_action=3

The effect of that command will be shown in the statusbar for a couple of seconds.


This is not possible in Everything 1.4.

[void]

@void: It may be useful for these wheel behaviors to be added to about:keys

I have put this on my TODO list.
Thank you for the suggestion.

[Jack66]

In your case: enter the following in the search bar and press ENTER:

Code: Select all

/ctrl_mouse_wheel_action=3

NotNull, thanks so much for this, and sorry for the delayed response, I've been away from my PC for a while. But yeah, I knew it was fully possible on 1.5 and was wondering if there was some workaround on 1.4.

EDIT:
Although, after testing, it's not doing anything for me.

And on a side note, almost every post I've made on this forum void has responded in some way, and others also, I am extremely impressed with the dedication that those who work on this project give to answering questions on the forums. Everything is such an awesome program also, it is essential for me, I couldn't use my PC for any amount of time without using it.

So thank you for a badass program and badass support.

[void]

Everything 1.5.0.1301a adds mouse bindings to about:keys.

[KaiStarkk]

Everything 1.5.0.1301a adds mouse bindings to about:keys.

Hi Void - is it currently possible to set a (ctrl) mouse wheel action for zooming in/out the preview view? I believe this was default functionality in 1.4

Reason: would like to zoom in/out of PDF viewers. Everything had become my primary PDF viewer, but without zooming it doesn't work for that case anymore.

[void]

Thank you for your feedback KaiStarkk,

The preview handler should handle the CTRL + mouse wheel event.

Could you please let me know what PDF viewer are you using so I can do some tests my end.

[KaiStarkk]

Thanks, the PDF viewer I'm using is Bluebeam Revu.

The preview handler being used by 1.5 does seem different to the one used by other applications (e.g. MS Outlook / File Explorer).
Also strangely in some cases it shows me a file directory tree instead of a preview in the preview windows.

Attachments provided to show what I mean. Apologies I haven't figured out clear repro steps just yet

everything.png (17.35 KiB) Viewed 4827 times

file explorer.png (18.79 KiB) Viewed 4827 times

showing a directory tree.png (54.22 KiB) Viewed 4827 times

.

[raccoon]

Also strangely in some cases it shows me a file directory tree instead of a preview in the preview windows.

Double check that the errant .pdf isn't actually a .html in disguise. This could be due to faulty download of the file kicking back an Index Of listing instead at time of download. Inspect the questionable .pdf with a hex editor or Notepad.

@void: What do you think of an option to rename the "Preview" caption to "Preview - htmlfile ihandler.yadda.yadda" at least while 1.5 is in alpha?

[KaiStarkk]

Thanks @racoon, no in this case it's a standard PDF.

Signature below if this assists - hopefully nothing here that I missed when redacting

Code: Select all

%PDF-1.5
%Ç쏢
8 0 obj
<</Length 9 0 R/Filter /FlateDecode>>
stream
<<REDACTED - binary stream>>
endstream
endobj
5 0 obj
<< /Title(\376\377\000S\000h\000e\000e\000t\000s)
/Dest [null /XYZ null null null]
/Count 1 /Parent 4 0 R
/First 6 0 R /Last 6 0 R
>>
endobj
32 0 obj
<</Type/Metadata
/Subtype/XML/Length 1551>>stream
<?xpacket begin='' id='W5M0MpCehiHzreSzNTczkc9d'?>
<?adobe-xap-filters esc="CRLF"?>
<x:xmpmeta xmlns:x='adobe:ns:meta/' x:xmptk='XMP toolkit 2.9.1-13, framework 1.6'>
<rdf:RDF xmlns:rdf='http://www.w3.org/1999/02/22-rdf-syntax-ns#' xmlns:iX='http://ns.adobe.com/iX/1.0/'>
<rdf:Description rdf:about='uuid:fb848a25-a665-11ec-0000-678a7f2d0fe4' xmlns:pdf='http://ns.adobe.com/pdf/1.3/' pdf:Producer='PDF Writer - bioPDF / http://www.biopdf.com / FSG / Personal Edition (not registered)'/>
<rdf:Description rdf:about='uuid:fb848a25-a665-11ec-0000-678a7f2d0fe4' xmlns:xmp='http://ns.adobe.com/xap/1.0/'><xmp:ModifyDate>2022-03-15T10:49:07+08:00</xmp:ModifyDate>
<xmp:CreateDate>2022-03-15T10:49:07+08:00</xmp:CreateDate>
<xmp:CreatorTool>PDF Writer - bioPDF (12.2.0.2905)</xmp:CreatorTool></rdf:Description>
<rdf:Description rdf:about='uuid:fb848a25-a665-11ec-0000-678a7f2d0fe4' xmlns:xapMM='http://ns.adobe.com/xap/1.0/mm/' xapMM:DocumentID='uuid:fb848a25-a665-11ec-0000-678a7f2d0fe4'/>
<rdf:Description rdf:about='uuid:fb848a25-a665-11ec-0000-678a7f2d0fe4' xmlns:dc='http://purl.org/dc/elements/1.1/' dc:format='application/pdf'><dc:title><rdf:Alt><rdf:li xml:lang='x-default'><<REDACTED>></rdf:li></rdf:Alt></dc:title><dc:creator><rdf:Seq><rdf:li><<REDACTED>></rdf:li></rdf:Seq></dc:creator></rdf:Description>
</rdf:RDF>
</x:xmpmeta>
                                                                        
                                                                        
<?xpacket end='w'?>
endstream
endobj
2 0 obj
<<REDACTED - oct representation>>
endobj
xref
<<REDACTED - dec representation>>
trailer
<< /Size 33 /Root 1 0 R /Info 2 0 R
/ID [<947BB709D53E14E4D2AE5C4CF1C63510><947BB709D53E14E4D2AE5C4CF1C63510>]
>>
startxref
776772
%%EOF

[raccoon]

Can opening or previewing specially crafted PDFs leak requests to the internet, to query a webaddress? Eg, <iframe> attack.

[void]

I have tested Everything 1.5.0.1304a with Bluebeam REVU x64 Extreme 20.2.60 on Windows 10 1903 18362.239.

Unfortunately, I have not been able to produce the issue.
Everything shows PDF previews with Bluebeam REVU preview handler.


There might be an issue with Everything loading the incorrect preview handler for you.

Could you please send some debug output:

• In Everything, from the Tools menu, under the Debug menu, click Start Debug Logging...
• Select a different PDF file in Everything so the preview changes.
• From the Tools menu, under the Debug menu, click Stop Debug Logging...
  -This will open your Everything Debug Log.txt in Notepad.
• Could you please send this file to support@voidtools.com

-The logs should indicate which preview handler is being loaded and from where in the registry the preview handler was found.

Can opening or previewing specially crafted PDFs leak requests to the internet, to query a webaddress? Eg, <iframe> attack.

It will depend on the third party preview handler.

[void]

Everything is incorrectly loading previews from HKEY_CLASSES_ROOT\.pdf\shellex\{8895B1C6-B41F-4C1C-A562-0D564250836F} when HKEY_CLASSES_ROOT\<.pdf class>\shellex\{8895B1C6-B41F-4C1C-A562-0D564250836F} exists.

Windows Explorer loads the previews from HKEY_CLASSES_ROOT\<.pdf class>\shellex\{8895B1C6-B41F-4C1C-A562-0D564250836F} first.

The next alpha update of Everything will do this.


For now, please try manually disabling the HKEY_CLASSES_ROOT\.pdf\shellex\{8895B1C6-B41F-4C1C-A562-0D564250836F} entry:

• From the Start menu, search for regedit
• Click Regedit
• In the Registry Editor, rename the following key:
  HKEY_CLASSES_ROOT\.pdf\shellex\{8895B1C6-B41F-4C1C-A562-0D564250836F}
• to:
  HKEY_CLASSES_ROOT\.pdf\shellex\_{8895B1C6-B41F-4C1C-A562-0D564250836F}
  (Note the _ prefix)