And thanks for answering 
.
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.
That just lets scripts know the mouse was clicked in the image viewer, and which button was clicked. It isn't for the file display.
Awwwwww 
Okay...
May I ask, what your exact usecase is?
I also read the 1st thread you linked, I still do not understand what you try to accomplish.
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.)
Can you post some examples on how you would use this? I'm curious how you would make use of that.
@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.
Not sure what you mean. We have added it.
Then I must've missed the memo or something :).
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.
https://www.gpsoft.com.au/help/opus12/index.html#!Documents/Scripting/Func.htm
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?
https://www.gpsoft.com.au/help/opus12/index.html#!Documents/Scripting/StartupData.htm
I am checking what scripting capabilities I have before I make a purchase
Information about the selected files is of course available, and it's all documented in the manual. StartupData is empty because at the moment there's no information that needs to be provided - it's a placeholder object for future development.
If you're holding off purchasing until we add exactly the scripting interface you feel you need you're probably wasting your time, because it's quite unlikely we would do that for an unregistered "evaluator".
If you'd bought the program four years ago and then requested improvements to the scripting interface there's every chance we would have implemented them already, if they weren't already possible. We do that a lot for our registered users, as a browse of the forum would quickly reveal.
1 Like
OnClick/ClickData is used in toolbar buttons and hotkeys which run scripts, and is called when the button or hotkey is pushed. It tells you which qualifiers are down, and if you need to know which mouse button was used to activate a toolbar button then there are ways to do that, although it doesn't really make sense for that kind of script to check which mouse button clicked on it; it should be up to the user which commands are assigned to which mouse buttons on a toolbar button, and the script should just run when/what it's told to run. Checking qualifiers makes sense, and is made really easy, so that scripts can react differently to shift+click or similar. (Shift+click runs the same script as a normal click. Right-click runs a completely separate script or command, which could in turn call the main script with added arguments specified by the user.)
OnClick/ClickData is for telling your script that the button or hotkey it is attached to has been invoked, not for tracking arbitrary mouse clicks over any part of the window.
As Jon says, it's empty because there's nothing that needs to go in it. It just tells the script Opus has started, so the script can do things if it needs to. (Most scripts don't need to handle that event at all.) What do you think it is missing exactly?? This seems like complaining for the sake of it now.
@Jon yes, I've been around this forum for years now and have seen how dedicated you guys are. I respect that, quite a lot actually. Even in this thread, you've shown more than necessary for an "evaluation" user, I really feel that. So I'll buy the program and jump straight in with the conversion to it when time allows. To clarify: I'll buy now and start using it when I can afford the time to start migrating from my rather heavily customized Total Commander.
@Leo No, I'm not complaining for the sake of it. It was a legitimate curiosity over the completion of your documentation. I see now the reason why there is nothing in that particular section and I think the answer is satisfactory .
Anyway, now I'm "legitimately" in the crowd :). Happy to be here and good job for everything so far. Looking forward what you will be doing in the next years. I'm in for the long haul
1 Like