It's just a detail, but I hope the Opus documentation is not going to lag behind too much. I was looking for a while how Dialog.window is used exactly, but I couldn't find it - I guess I copied it from some user script a while ago.
At a first glance, the dialog properties documentation (Control [Directory Opus Manual]) does not yet document the following:
Dialog.Window
Dialog.WindowCmd
Dialog.State
Maybe others know about other missing documentation. Or is there another way to submit remarks about docu? Because this isn't really about bugs of course.
In fact I was searching for a way to open a dialog on my second screen. I didn't yet find it. I thought maybe it is Dialog.Show(1) or something like that, but that doesn't do it, and this is just ignorant guesswork.
This is the right place to submit documentation issues (missing or incorect parts).
Note that if you're looking for Dialog properties on the Control object, you might find missing properties
The Dialog object manual (Dialog [Directory Opus Manual]) is referencing window and state properties. Dialog.WindowCmd is a method of the Dialog object and can be found on the Dialog manual page (at the very bottom).
Usually documentation gets updated quite quickly (in general at the same time changes are released).
I've never came across that need. Usually, I tend to open dialogs on the window where the lister that launched the action is (using the sourcetab in the ScriptCmdData object).
You might be able to get something from SysInfo.Monitors with the Rectangles positions of the different monitors, and then by specifying Dialog.x and Dialog.y before showing your Dialog.
Note that, from the docs, the Dialog.Show method takes no parameter.
@PassThePeas Yes, both Dialog and Control pages are on my bookmarks for frequent use. And you're right I glanced over the WindowCmd docu, thx.
Some of these things are a bit confusing indeed, but that's because of the technical nature of the matter, I get that. Something I still find a bad idea is that the documentation for a simple dialog and a complex scripted (detachable) on, is all lumped together, while in my view those are really two different kinds of dialog systems.
They're different on the way they manage the message loop, but they're built in the same way, share the same properties and methods (as being the same object).
The difference is that the detachable gets you the ability to interact with the dialog during it's use (in the message loop), which makes it interesteting for complex dialog where one action (button click, texfield input, ...) will lead to a change in the dialog itself.
If your dialog is simple enough that you only need to retrieve user inputs/choices you can skip getting into the message loop and just get the info once the "final" action (the one that closes the dialog) has been taken.
EDIT: And for "simple" dialogs (ones you don't design the content), they're here for very basic usage where the dialog is so simple that it's easier/quicker to design through some properties of the Dialog. Yet, it's still a dialog object with the same inner working, hence it's the same class.
But I see what you mean by having all this mixed: if you're going for a dialog with a template, some properties are useless (choices, buttons, ...).
I did
I have my Opus always on my main screen, but from the moment I attach my second screen (which is only when I'm in a particular room) I want my dialogs to open on the other screen.
I'm not expecting a solution for this though. Opus is pure magic, but perfect magic is something for utopian minds who want too much in life.
Oh but I do that all the time. I use js functions like this:
function DlgPositionInit(dlg, factory, fo) {
//Position definitions (right after the dialog has been created) + caching some values
fo.dlgStartPos = 'botleft'; //4 choice top/bottom etc.: botright, botleft, topright, topleft (case-insensitive)
fo.dlgset_top = 1;
fo.dlgset_left = factory.SysInfo.WorkAreas(0).left -4; //Positioning to the left of the screen.
fo.dlgset_right = factory.SysInfo.WorkAreas(0).right - dlg.cx +6; //Positioning to the right of the screen.
fo.dlgset_bottom = factory.SysInfo.WorkAreas(0).height - dlg.cy +6; //Positioning at the bottom
fo.dlgmem_height = dlg.cy; //Cache for reset purposes;
fo.dlgmem_width = dlg.cx; //Cache for reset purposes;
}
function DlgPositionReset (dlg, fo, location) {
dlg.y = -1;
switch(location.toLowerCase()) {
case "topleft" : dlg.x = fo.dlgset_left; dlg.y = fo.dlgset_top; break;
case "topright": dlg.x = fo.dlgset_right;dlg.y = fo.dlgset_top;
dlg.cx=fo.dlgmem_width; break;
case "botleft" : dlg.x = fo.dlgset_left; dlg.y = fo.dlgset_bottom; dlg.cy=fo.dlgmem_height; fo.dlgminenlarge=fo.lviewMinLines; break;
case "botright": dlg.x = fo.dlgset_right;dlg.y = fo.dlgset_bottom; dlg.cy=fo.dlgmem_height; fo.dlgminenlarge=fo.lviewMinLines;
dlg.cx=fo.dlgmem_width; break;
}
}
Still, I couldn't find how to open a dialog on the second monitor (while Opus is on the first). But, as I said, I need no perfection. It is much more important that Opus remains stable than to be perfect.
When you have multiple monitors they form one large virtual desktop with a contiguous coordinate system.
So if as an example, you have two 1920x1080 monitors, then monitor 1's coordinates would span 0,0 - 1919,1079. If monitor 2 is positioned to the right of it, monitor 2's coordinates would span 1980,0 - 3879,1079.
To put a dialog on monitor 2 just pick some coordinates in that range and it'll appear on monitor 2.
It works. It requires to pre-define a lot of things (hardcoded) but it can be done.
Just one more question (to @Jon , @Leo , @PassThePeas or other Opuswizzards) before I implement a solution: am I correct that while Opus can detect the screen resolution of our original PC or laptop screen, it has no tools to let us detect the screen size (resolution) of our extended screens?
