Almost a year ago I wanted to purchase this program. It seemed so much more capable than Total Commander. Unfortunately, it didn't quite cut it since I couldn't do a tiny but important thing with it, which concerns the mouse.
//Ignore all other left click behavior: do not toggle selection, however, *do* move the caret to the location of the left click.
@script jscript
function OnMouseClick(data)
{
if (data.leftClick)
{
Item.focused = true; //I do not know the command for this so I'm writing in "pseudocode".
if (Item.selected) data.func.command.RunCommand("rename inline");
}
return;
}
Since then, I noticed some changes:
Added the SysInfo script object which lets scripts access mouse and monitor coordinates.
Added mouse property to the DoubleClickData object, to indicate which button launched the double-click (left, middle, none).
So maybe we can see a OnMouseClick event soon? .
And yes, I'm a persistent fellow . And as I said before, I'd be willing to pay a premium for you guys to make your scripting engine more powerful .
Hey. I'm resurrecting this for good reason. The reason being that I think I can finally buy this software after waiting for almost 3 years for the mouse events to be implemented. But... it seems to me like they finally are!!! Can you please confirm? :). I read this in the release notes of 12.4:
Added two new options to the various mouse button settings on the Viewer / Mouse Buttons page in Preferences:
Expand/Scroll Image: When this option is enabled, and the displayed image is reduced from the original size, clicking and holding the appropriate mouse button displays the image in its original size for as long as the mouse button is held
Script event: When enabled, any script add-ins that implement the OnViewerEvent script event will be triggered when the button is clicked. The event type will be "click", "dblclk" or "mclick" as appropriate.
Of course you may ask . I'm currently using Total Commander and I am accustomed to do certain things in certain ways which I consider efficient. The problem is that I can't reproduce some of those features in Directory Opus. Here is the thread that actually made me realized I need mouse scripting in order to accomplish what I want:
I am very impressed by Directory Opus in general, but I find it kind of staggering that the scripting engine doesn't allow mouse events scripting. That would really open up Directory Opus for very useful contextual scripts. I would need 3 licenses of Directory Opus and that's a pretty penny, but if I'm to spend it, I want this program to be absolutely all that I wish it to be. Mouse event scripting is essential for me not only because of the thread I linked above, but I consider that it would add a lot of potential to the investment I would be making
Could it be you underestimate the complexity in handling mouse events in a full blown application a bit? o)
I am a developer myself and once you have an application which handles the mouse here and there, there is a lot of work handling the various messages coming in, going through and blocking some of them. If users were allowed to mess with the event handling where they want to, I really think most implementations would screw up what works fine by default.
It surely is possible to some extend, but to allow for such custom event handling a lot of brain work has to be done and even more work on the whole event dispatching in DO. This is something which will probably not happen very soon, if ever.
It makes more sense the way things are by now, very specific events where you can run custom functionality. The current implementation is already able to open a can of worms if done wrong, things can get really bad if you were allowed to handle raw mouse event data and such. If the DO developers disagree to this, I'd be very surprised.
We may add some events triggered when files are selected/deselected, at some point, although we're still thinking about the pros and cons of that, and how best to implement it without causing problems while still being able to do what people want with the events.
Probably nothing lower level than that as it would be a can of worms, as you say.
I can't think of many apps that allow low level mouse event scripting, so I am surprised that anyone is surprised Opus (or anything else) doesn't have it.
Hey guys. First of all, thank you for answering and being so involved. @Leo , you and the rest of your team are really dedicated, I am very impressed by this :).
Secondly, to be clear: I'm not looking for LOW level mouse event scripting. Far from it. As my original post mentions, I simply would like to get notified when the user clicks a file in the file list and be able to trigger a script that manipulates that file or, in my specific case, the selection state . I did go a bit in too much detail saying that it would be nice to get mouse coordinates and perhaps get item under mouse, but that's not so important. The file list is .
I'd like to be able to attach scripts to left / right / double clicking on files. There should be an option for the script to replace standard Directory Opus behavior. I'm sure that there are plenty of users who are well aware of how modifying a program can break it and such cases could very well be not covered by support.
@tbone: I'm not underestimating it because I've been developing software for the past 20 years, including in C++.
@Leo: me being "staggered" (as I wrote) isn't related to Directory Opus not offering the world+dog to the user. It was related to it being such a powerful program WITH a scripting engine that already allows a LOT of things to be done with it, but for some reason there's no way to attach scripts to file interactions which I consider to be the most important thing a user does with such a program ;).
To be honest it's not only mouse that interests me. It's keyboard as well. I mean... if you open the file list to such scripting you could allow users to create all sorts of keyboard navigation scripts for Directory Opus, conversions of functionality and other funky stuff . Often, developers themselves are surprised to see what the users can come up with if you offer them a potent API!
Hello again :). 4 years later and you're still rocking. I've been doing some yearly checks around the "what's new section", and checking this discussion board too. I love the level of dedicated support you give to us. Very impressive!
I've been using Total Commander for more than 20 years. I'm still looking to switch to DOpus, but when I do it, I want to turn my DOpus into the command center for the next 20 years :). And for that, I am waiting to achieve what I said in the OP.
Basically, I'm hoping that one day you guys will make the clicked item (and all its data), available for scripting. To be clear, I don't want low level access to any mouse movements, just that when the user clicks, right clicks or middle-clicks, the item with which the mouse interacts is passed inside the script. I'm mostly interested in the file list, but imagine what we could do if say, you give the mouse-wheel movements on some button bar. People could write some interesting scripts with this stuff, such as multi-line button bars or who-knows-what-crazy-stuff.
I'll end this "comeback" post with what I said during my last previous post:
Often, the developers of an API themselves (in this case, YOU) are surprised to see what the users can come up with if you offer them a potent API!
Scripts can use Dialog.WatchTab to be notified when a folder tab's selection changes. (The script dialog does not have to be visible, so this can be a background thing if your script doesn't need to display any UI.)
@tbone what you're after is in my OP. @Leo that's good to know actually! Does the file list have a click handler? In that case, I could perhaps script something so that when the file list is clicked (anywhere), I get the current selection.
Would still love to get more data about the clicked object . Nobody was so far really clear with me why you aren't adding this. My perception is that this program is the kind of rocket that thrives on a whole new level of flexibility for a file manager, which then allows users to extend it greatly.
The method I mentioned in my previous reply notifies scripts when the selection changes. You don't need anything else (and there isn't anything else ).
You can get detail about the clicked items from the scripting API.
I'm looking in the documentation and can't find how I can retrieve what buttons have been clicked (and potentially modifiers such as CTRL/ALT), neither the precise file entry that was clicked.
If you use Dialog.WatchTab, you'll be told when the selection changes within a folder tab. Your scrit can then look at the folder tab object to see what is selected.
You won't be told which mouse button was used to select the files.
Please link your account if you want to continue discussing this.
As I said before, I haven't purchased yet because I was looking to see if the program offers the scripting flexibility that I'm looking for :). Perhaps I don't understand the matter fully, or the documentation is not clear enough, but the data received in ClickData seems... insufficient. If I click a button in a program that offers me scripting, I expect to receive some data about the object I clicked upon. Or, the opposite, to be able to tie a click handler to all objects I'm interested in.
Maybe it's just not documented? I just checked some other parts of the documentation and for example this StartupData object is... empty?
.
.
Okay...
. I'm currently using Total Commander and I am accustomed to do certain things in certain ways which I consider efficient. The problem is that I can't reproduce some of those features in Directory Opus. Here is the thread that actually made me realized I need mouse scripting in order to accomplish what I want:
. Nobody was so far really clear with me why you aren't adding this. My perception is that this program is the kind of rocket that thrives on a whole new level of flexibility for a file manager, which then allows users to extend it greatly.