Xplorer2Hack: Menu++ Customizable menu for Xplorer2

FrizzleFry · Post by **FrizzleFry** » 2007 May 07, 18:02

I would be nice to have a useful tools sticky thread that would document utilities like Menuhack and Menu++ as well as any other tools we like.

The original message could have download links for the favorite tools and for menuhack and menu++ links to the original threads.

Stefan · Post by **Stefan** » 2007 May 22, 14:46

snakebyte, this looks very promising !

I wonder if it would be possible to grey out options which don't establish the prerequisites, for example, disabling "Copy names" because no file or folder has been selected. It actually works with something like this (copy it into a .ahk-file and link a user command to it):

Code: Select all

; Initial stuff
SendMode Input
MouseGetPos MausX
MenuPos:=MausX-110

BackupClipboard := ClipboardAll

; Clear the clipboard before copying paths of selected objects into it.
; (the clipboard will stay empty if nothing has been selected)
clipboard=
send !c ; That's the hotkey for x2's "Copy path" command

; Allow x2 two seconds to carry out the job.
; Note: Some kind of waiting period is necessary -
; otherwise the clipboard may still be empty !!
ClipWait 2

; Fetch the results before restoring the previous clipboard content
SelectedFiles := clipboard
clipboard := BackupClipboard 
BackupClipboard =


; Now we can determine if none, a single one or multiple objects are selected,
; those menu items which won't work with the given selection will therefore be greyed out:


; *** Example Menu ***

Menu, MyMenu, Add, One single object selected, Nothing
if not SelectedFiles
	Menu, MyMenu, Disable, One single object selected
IfInString SelectedFiles,`n	; `n looks out for a carriage return which indicates multiple paths
	Menu, MyMenu, Disable, One single object selected

Menu, MyMenu, Add, Multiple objects selected, Nothing
if not SelectedFiles
	Menu, MyMenu, Disable, Multiple objects selected
IfNotInString SelectedFiles,`n
	Menu, MyMenu, Disable, Multiple objects selected

Menu, MyMenu, Add, One or more objects selected, Nothing
if not SelectedFiles
	Menu, MyMenu, Disable, One or more objects selected


Menu, MyMenu, Show, %MenuPos%

Nothing:
return

It works fine, but there is a snag: If NOTHING has been selected, ClipWait won't get aborted prematurely which will cause a delayed display of the menu.

However, there may be two alternative solutions, but I don't know how to put them into practice because I'm very much a freshman when it comes to AutoHotkey. So, hopefully some of you experts out there can pick up these ideas:

Possible alternative solution #1:

Instead of pulling the selected objects out of the active pane by Alt+c, it might be more efficient to look INTO the pane ! It should work with something like this (targetting the left/upper pane):

Code: Select all

ControlGet ReceivedData,List,Selected,ATL:BrowserListView1,A

... but unfortunately %ReceivedData% stays empty.

This is what AutoHotkey has to say about possible reasons:

1) the target window or control does not exist
2) the target control is not of type SysListView32
3) the process owning the ListView could not be opened, perhaps due to a lack of user permissions or because it is locked

Maybe Nikos can comment to #2 and #3 ?

Possible alternative solution #2:

Simply cloning the state of the original x2 menu items. Note that this won't consider user commands, so this might be the worst method. Anyway, I don't find a way to check wether the x2 menu items are disabled or not. Stupid me.

However, I hope this whole stuff is for some use of you....

vserghi · Post by **vserghi** » 2007 May 22, 15:05

Are you the same Stefan from the pspad forum's by any chance?

Stefan · Post by **Stefan** » 2007 May 22, 15:19

vserghi wrote:Are you the same Stefan from the pspad forum's by any chance?

No, I'm not unfortunately. But who knows, maybe someday I will ...

snakebyte · Post by **snakebyte** » 2007 May 22, 16:41

Stefan wrote:snakebyte, this looks very promising !

Thanks Stefan

Stefan wrote: I wonder if it would be possible to grey out options which don't establish the prerequisites, for example, disabling "Copy names" because no file or folder has been selected. It actually works with something like this (copy it into a .ahk-file and link a user command to it):

This doesn't look easy. Remember Menu++ is completely separate executable from xplorer2 and there is no information interchange between these two, so to implement your suggestion Menu++ has to

1) Maintain a list of all commands which can be in disabled state. Note, this again can be difficult as same command can be specified by using command Ids, menu position or hotkeys(which again can be customized)

2) Implement the grey out logic for all the commands in the above list. This logic can be different for different commands and is not based upon the simple fact whether items are selected or not selected. Its not possible to determine state of few commands like Back, Forward, Paste Link, Folder Junction Paste, mirror scrolling with single pane etc

I don't think that adding all this complexity to menu++ code for graying out few commands is justified.

Stefan · Post by **Stefan** » 2007 May 23, 08:47

Its not possible to determine state of few commands like Back, Forward, Paste Link, Folder Junction Paste, mirror scrolling with single pane etc

Sure, of course there are various items that aren't based on the number of selected file objects. But not be able to have everything shouldn't keep from having all that's possible.

And that's much, since many item do base on the number of selected file objects..

Well, that's what I would do: Determine the number of selected file objects (with the result zero, one or multi). As you see above, these are just a few lines. And then do what's always done when things can't reconciled anymore because of application updates and customization issues:

Leaving it up to the customer. Like this:

Action=Menu,10&,3&,[POSITION_OF_YOUR_USER_COMMAND]&,dependency

Dependency = zero, one, or multi ...
If the user does not make use of %Dependency%, the menu item will always be displayed....

snakebyte · Post by **snakebyte** » 2007 May 23, 20:23

Stefan wrote:Action=Menu,10&,3&,[POSITION_OF_YOUR_USER_COMMAND]&,dependency

Stefan, the problem with this approach is that 'Action=' verb can have unspecified number of parameters and I would always have to check if the last parameter is dependency or not.

I think I have a better solution to this problem. Let me try out this idea. I'll update this post when I have something ready and working.

Stefan · Post by **Stefan** » 2007 May 24, 08:49

The easiest way would be to state 'Dependency=' in a separate line.

This might be more suitable for the users as well. However, I'm very much looking forward to the next version of Menu++.

If you find a fast and reliable way to determine the number of selected objects, please let me know. What makes it so difficult to look into the menu or panes is that x2 uses ATL instead of MFC controls. :(

FrizzleFry · Post by **FrizzleFry** » 2007 May 24, 23:43

Is there a way to specify another editor for the configure menu entry to use?

snakebyte · Post by **snakebyte** » 2007 May 25, 00:51

Menu++ launches the default editor associated with .ini files, which is notepad for most of us.

As long as configuration file is a text file, its extension does not matter. So for instance, you have associated Editor2 for .txt files, then following will launch configuration file in Editor2.

Code: Select all

>"C:\My Downloads\Menu++\Menu++.exe" display.txt

Note: This trick requires configuration file to be passed as menu++.exe parameter explicitly.

FrizzleFry · Post by **FrizzleFry** » 2007 May 25, 02:51

Thanks, I should have figured that out. :oops:

Stefan · Post by **Stefan** » 2007 May 25, 17:33

@ snakebyte:

Yes, me again.

This should not only determine the number of selected objects without any delays, its even faster than the clipboard method:

Big thx to Nikos !! - for pointing me to the LVM_GETSELECTEDCOUNT message !!

Code: Select all

; default number

SelectedObjects=zero

; Finding the control thats focussed

SetTitleMatchMode 2
ControlGetFocus FocussedControl,- xplorer²

; Making sure its a file pane, get its selection
; and change %SelectedObjects% accordingly

StringLeft FControlType,FocussedControl,19
ifequal FControlType,ATL:BrowserListView

{
SendMessage 0x1032,0,0,%FocussedControl%,A ; 0x1032 = LVM_GETSELECTEDCOUNT
NumberOfSelectedObjects=%ErrorLevel%
if NumberOfSelectedObjects = 1
SelectedObjects=OneObjectOnly
if NumberOfSelectedObjects > 1
SelectedObjects=MultipleFiles
}

msgbox %SelectedObjects%

return

That's it. What is left are a few lines inside the loop which parses the ini. If %SelectedObjects% doesn't match a dependency (if its determined) the item gets disabled.

Do you think it suits the needs ?

snakebyte · Post by **snakebyte** » 2007 May 25, 19:27

Thanks Stefan, I'll look into your code.

I have a question. Do you really want to distinguish between single and multiple selected items? Can you list the cases where you would like to enable menu items for only single selected item?

I think instead of having three states, we can have just two states: Items selected and items not selected.

Stefan · Post by **Stefan** » 2007 May 26, 09:48

Yes, I think it is necessary. At least "Change Type" is enabled in x2 only if a single object has been selected. And its definitely advisable in the face of user commands that are based on batch processing, like mass renamers. (*)

There may be 3 possible states, but see:

Single = The item gets disabled if no or multiple objects are selected
Multi = The item gets disabled if no or just one objects are selected

Hence "zero" would mean: "Disable item if something is selected". Whatever function could that be ?? I can't imagine any, so the user can forget about it, he only has to make his mind up between those 2 states you desired. But these are not Items selected/not selected, but single or multi.

Note that the code example does not check for the "zero" state. "zero" is given if dependency is not specified at all. The user doesn't have to care about it, and we don't have to either.

-

(*) Another idea for the future:

Send !c ; Copy paths to clipboard
FileAppend %ClipboardAll%,textfile located in Menu++ folder

People could use this textfile to pass the selection to a user command. Things like batch processing with IrfanView will become possibe !

snakebyte · Post by **snakebyte** » 2007 Jun 02, 20:56

You can now download Menu++ v 1.1 from the original post. I've updated the readme file and the sample config files in the download.

1) This version supports disabled menu items. For determining the number of selected items I'm not doing anything fancy. While launching Menu++ just pass xplorer2 token $S as the second parameter. I'm using this to count the number of selected items. Readme file has the syntax details.

2) I've also added a new action type 'bookmark' for opening folder bookmarks. The difference b/w x2 bookmarks and m++ bookmarks is that, m++ bookmarks open in a new tab instead of current tab.