Hello, XYplorer Club!
I would like to have arguments for input commands like input, inputfile, inputfolder, inputselect
that allow to define a desired position for dialog windows being opened by this commands.
Example for input command:
input(topic, [notes], [default], [style=s|m|w], [cancel], [width=800], [height=400], [positionX], [positionY])
New arguments [positionX] and [positionY] would allow to move opened dialog windows on X- and Y-axes
so that they do not obstruct the view to the content of the pane, tree, catalog, info panel or to an other interface part.
Thank you!
Position of dialog windows
Position of dialog windows
Last edited by zakhar on 07 Jul 2018 20:47, edited 1 time in total.
Re: Position of dialog windows
And this feature would be useful not only for input, inputfile, inputfolder, inputselect commands
but also for all other available dialog windows too (echo and msg).
Example:
Imagine you run a script, that renames items shown in the list - folders Program Files, Program Files (x86), Users and
Windows (only as example here ). Before renaming the script pops a dialog window allowing to choose or enter something.
This dialog window will now unavoidable overlap the names of the folders you want to rename while the dialog window appears in the center. The new arguments [positionX], [positionY] would allow to move the dialog window automatically aside -
- automatically as it is defined in the script. This arguments would also allow to move the dialog window to avoid overlapping of tree or catalog and to move these dialog window
to an expected position.
I presume that XYplorer's interface elements stay in the same position and the XYplorer's window has the same size and form,
so that the current user does not need to change the arguments in the script.
Some additional alternative flags would be not meaningless for above mentioned commands, they could prevent overlapping of
other interface parts without definition of [positionX] and [positionY] arguments and make the dialog windows sticky.
but also for all other available dialog windows too (echo and msg).
Example:
Imagine you run a script, that renames items shown in the list - folders Program Files, Program Files (x86), Users and
Windows (only as example here ). Before renaming the script pops a dialog window allowing to choose or enter something.
This dialog window will now unavoidable overlap the names of the folders you want to rename while the dialog window appears in the center. The new arguments [positionX], [positionY] would allow to move the dialog window automatically aside -
- automatically as it is defined in the script. This arguments would also allow to move the dialog window to avoid overlapping of tree or catalog and to move these dialog window
to an expected position.
I presume that XYplorer's interface elements stay in the same position and the XYplorer's window has the same size and form,
so that the current user does not need to change the arguments in the script.
Some additional alternative flags would be not meaningless for above mentioned commands, they could prevent overlapping of
other interface parts without definition of [positionX] and [positionY] arguments and make the dialog windows sticky.
Re: Position of dialog windows
there is a long-time wish that i have. it would be great if xyplorer could accurately remember the coordinates and sizes (of all its sub-windows)
i speak about not only usual coordinates but also about those coordinates which are partially outside of the visible screen area
xyplorer already remembers something concerning several sub-windows. examples from my ini-file:
SelSpecLeft=674, SelSpecTop=327, SelSpecWidth=600, SelSpecHeight=525
RPLeft=29, RPTop=26, RPWidth=650, RPHeight=1152
LMLeft=29, LMTop=66, LMWidth=1891, LMHeight=1111
ALLeft=29, ALTop=75, ALWidth=1895, ALHeight=1127
SVLeft=315, SVTop=128, SVWidth=1401, SVHeight=951
QFVLeft=916, QFVTop=0, QFVWidth=1006, QFVHeight=1200
HRLeft=476, HRTop=70, HRWidth=1043, HRHeight=1132
ScriptTryLeft=797, ScriptTryTop=29, ScriptTryWidth=548, ScriptTryHeight=267
FPLeft=887, FPTop=27, FPWidth=1039, FPHeight=1149
various examples:
- 'action log' looks good (coordinates+sizes are remembered)
- 'configuration' looks normally (coordinates are remembered) (sizes are not changeable which is fine in this case)
- 'customize toolbar' looks bad (coordinates are not remembered) (sizes are not changeable which is bad in this case)
- 'batch rename' looks bad (coordinates are not remembered) (sizes are not changeable which is not good but bearable)
- 'new folders' looks very bad (coordinates+sizes are not remembered)
- 'edit item names' looks very bad (coordinates+sizes are not remembered): this is really inconveniently
i speak about not only usual coordinates but also about those coordinates which are partially outside of the visible screen area
xyplorer already remembers something concerning several sub-windows. examples from my ini-file:
SelSpecLeft=674, SelSpecTop=327, SelSpecWidth=600, SelSpecHeight=525
RPLeft=29, RPTop=26, RPWidth=650, RPHeight=1152
LMLeft=29, LMTop=66, LMWidth=1891, LMHeight=1111
ALLeft=29, ALTop=75, ALWidth=1895, ALHeight=1127
SVLeft=315, SVTop=128, SVWidth=1401, SVHeight=951
QFVLeft=916, QFVTop=0, QFVWidth=1006, QFVHeight=1200
HRLeft=476, HRTop=70, HRWidth=1043, HRHeight=1132
ScriptTryLeft=797, ScriptTryTop=29, ScriptTryWidth=548, ScriptTryHeight=267
FPLeft=887, FPTop=27, FPWidth=1039, FPHeight=1149
various examples:
- 'action log' looks good (coordinates+sizes are remembered)
- 'configuration' looks normally (coordinates are remembered) (sizes are not changeable which is fine in this case)
- 'customize toolbar' looks bad (coordinates are not remembered) (sizes are not changeable which is bad in this case)
- 'batch rename' looks bad (coordinates are not remembered) (sizes are not changeable which is not good but bearable)
- 'new folders' looks very bad (coordinates+sizes are not remembered)
- 'edit item names' looks very bad (coordinates+sizes are not remembered): this is really inconveniently
Re: Position of dialog windows
I accidentally have found similar (see my first post here) functionality in
popupmenu(itemlist, [x=-1], [y=-1], [start=1], [count=-1], [flags=0], [sep_itemlist="|"], [sep_item=";"], [on_cancel=""]) -
- the wanted arguments are [x=...] and [y=...].
The difference between inputselect() and popupmenu() is that the user can check multiple items in inputselect() and
only one item in popupmenu(), so that the popupmenu() can not replace inputselect().
popupmenu(itemlist, [x=-1], [y=-1], [start=1], [count=-1], [flags=0], [sep_itemlist="|"], [sep_item=";"], [on_cancel=""]) -
- the wanted arguments are [x=...] and [y=...].
The difference between inputselect() and popupmenu() is that the user can check multiple items in inputselect() and
only one item in popupmenu(), so that the popupmenu() can not replace inputselect().
Last edited by zakhar on 08 Jul 2018 10:36, edited 1 time in total.
Re: Position of dialog windows
@zakhar, I realize you are asking for native support, but if you are at all interested in an alternative in the meantime, then this works: CMDOW, a quick example:
You could also do it through something like AHK but I find this easier. You probably won't be satisfied with this solution because there is a momentary flash when it moves, but I thought I would present it as an option anyway, personally I consider it a perfectly acceptable way to provide the functionality you are asking for.
Code: Select all
run "cmdow.exe Input /MOV 20 20", , ,0;
input();
run "cmdow.exe MOVEME /MOV 20 20", , ,0;
inputselect(7:="MOVEME");
run "cmdow.exe ""Browse for Folder"" /MOV 20 20", , ,0;
inputfolder();
run "cmdow.exe Xyplorer /MOV 20 20", , ,0;
echo;
run "cmdow.exe ""Xyplorer <xyver>"" /MOV 20 20", , ,0;
msg;
run "cmdow.exe ""Open"" /MOV 20 20", , ,0;
inputfile();
Re: Position of dialog windows
@jupe:
Thank you for your interesting suggestion about CMDOW!
I am acquainted with CMDOW but I would newer think that it would work with a window that is not already opened!
I hope that there will be the native support of the [x=...] and [y=...] arguments for dialog windows but
in the meantime I will try to use CMDOW so as you suggested it.
The momentary flash is finally not so bad - seeing what must be renamed is more important than a momentary flash
Thank you, jupe, one more time!
Thank you for your interesting suggestion about CMDOW!
I am acquainted with CMDOW but I would newer think that it would work with a window that is not already opened!
I hope that there will be the native support of the [x=...] and [y=...] arguments for dialog windows but
in the meantime I will try to use CMDOW so as you suggested it.
The momentary flash is finally not so bad - seeing what must be renamed is more important than a momentary flash
Thank you, jupe, one more time!