Tried following simple code while testing things with people on the german forum:
@set folderName={dlgstring|Name des Ordners:|{file$|noext}}
@runonce
Copy MOVE HERE CREATEFOLDER="{$folderName}"
After I run this, the little dialog asking for the foldername pops up, the files get moved, but then the DO lister is not responding to mouse inputs anymore (whenever you click, you hear some kind of ding / bell sound only). It also seems, the DO window is gone from the "Tasks / Windows" list (this CTRL-Tab thing), in this situation. For some odd reason the keyboard still works for some input into the lister, but it does not help much to recover from this.
I can only close the window via taskbar, no other options seem to work.
I already had this "cannot click / only bell-sound" situation within the last week or something, could not reproduce, since multiple progress / windows and things were involved, but this is easy to reproduce here.
Well, a specific thing sounds good, much more easy to find than the unspecific stuff!? o)
Thanks for trying, Hardkorn also tried with no unusual result, mhh..
Update for Leo:
The lister goes into "bell sound" mode, even if the dlgstring dialog is "Cancel"ed and the button code does not run any further, maybe that helps in some way while looking into the dump.
No emergency here, other dlgstring based dialogs seem to be ok.
Maybe somebody likes to try with the full button code, you never know, maybe it's the name?
<?xml version="1.0"?>
<button backcol="none" display="label" textcol="none">
<label>Move Into New Folder - Test</label>
<icon1>#newcommand</icon1>
<function type="normal">
<instruction>@set folderName={dlgstring|Name des Ordners:|{file$|noext}}</instruction>
<instruction>@runonce </instruction>
<instruction>Copy MOVE HERE CREATEFOLDER="{$folderName}" </instruction>
</function>
</button>
EDIT: Nope, it's not the name of the button and a different toolbar also does not make a difference (I had the button on my "hidden" test toolbar). All currently opened listers get into "bell sound" mode after using the button.
EDIT2: I have 3 displays connected to the computer, maybe that is confusing the window handling in some way?
Looking at the process snapshot, Opus itself is normal and not busy with anything, so it should be processing input normally.
I noticed a couple of tools loaded into the process which are related to things that hook/modify other windows (RBTray and MouseImp). Those often get confused by Opus's threads and dialog hierarchy, so it's worth trying with them uninstalled to see if they're involved somehow.
Thank you big time for looking at this special case.
You have a point here, somewhat! o)
MouseImp is in use here for 20+ years, there were no issues in the past. To make sure, I checked with MouseImp disabled, no difference. Then I checked with some more tools disabled, including RBTray and yes.
RBTray and DO v13 don't seem to like each other. I just wonder, why the DO lister does not enter this weird "bell sound" mode all the time when {dlgstring.. } is used - this is very strange of course.
Anyway, I do not run RBTray any longer, since there was at least one more problem like this in combination with progress dialogs or other requesters. It's the easy way out of this, but no satisfaction really, right? o)
RBTray hasn't been updated since 2011 and has a number of open issues for conflicts with other software, so I guess it'll never be fixed at this point.
I'll see if we can detect it and show a message if it's installed, since it breaks things so badly.
Not sure, if it's that bad, I was using the version from 2022, no problems until now.
I have no problem letting RBTray go, I really don't care, I find something else.
What I am most interested in, is HOW this can be an RBTray problem, since it only occurs with DO v13 (beta! o) and the same dialogs yield different results. I just want to make sure, we don't have an issue in DO, really, that's what I actually care about, not the RBTray thing.
This dialog does not "stall" the lister (notice the missing "|{file$}" in the button code): Copy MOVE HERE CREATEFOLDER="{dlgstring|NameOfTheFolder:}"
This one does: Copy MOVE HERE CREATEFOLDER="{dlgstring|NameOfTheFolder:|{file$}}"
As a developer I look at this and think..
It really does not seem very likely that RBTray is the real issue here. It is basically the same dialog, same title etc., the only difference is in the button code itself, where RBTray cannot look into, so.. you know? o)
Yes, thank you!
I was running a 2022 version iirc, and I also updated to this current release to see if it makes a difference, but it did not.
Tools that hook every other process need to be written very carefully, as they're interfering in other people's code. They often make a lot of assumptions, e.g. that the parent and child window (or even every window in the process) are going to be on the same thread, which is often true but not always.
Why it goes wrong, I don't know. I don't know how it works. But we've seen the same issue with dialogs and the viewer window from similar tools. Sometimes they fix things, sometimes they don't (e.g. MaxTo is another tool that hooks other software, where a similar problem was reported and still hasn't been fixed over a year later).
You'd have to ask someone who works on the tools why they go wrong.
I would expect DO to always fail in combination with RBTray, if this is a regular incompatibility or some kind of bad code going on on either side, but the actual trigger of the fault seems to be the DO button code (for now), which I find quite intriguing. If you don't and you are still confident, that it's not DOs fault, then ok! o)
