OFPEC Forum
Editors Depot - Mission Editing and Scripting => ArmA - Editing/Scripting General => Topic started by: Worldeater on 19 May 2009, 21:41:32
-
I've recently started getting my feet wet with all the display/dialog/control stuff.
Has anyone tried to build a "window manager" for Arma yet? In theory it should be possible to create "windows" with CT_CONTROLS_GROUPs:
- When there are multiple CT_CONTROLS_GROUPs the one that has the focus will be the top-most. So you can bring the "windows" to front by clicking them (just like in any other window manager).
- Move/Resize can be scripted (movingEnable/moving/ST_TITLE_BAR won't work here). BIS has done this in "The Armory" (but I would prefer a non-hardcoded solution using missionConfigFile to collect the needed IDCs).
- The windows can even be themeable (since you can specify custom properties in the class definitions for dialogs/controls).
Note: I'm not sure if it's a good idea to have resizable and themeable windows since this requires writing a layout manager. :dry:
My first tests look pretty promising. But before I invest lots of time: is there anything I should be aware of? Are there any nasty bugs/pitfalls/shortcomings in Arma's dialog/control stuff?
-
I have considered making a window manager a few times, but have always stumbled since you have no control over Z layer for any components (the only way to affect Z is for a single component that can be pulled to the front via setting the currect focus, which is far from useful in this context). I noticed CT_CONTROLS_GROUP mentioned but with no examples or documentation for that control type, I couldn't use it. The total crapness of the armoury probably didn't encourage many people to delve into it, but if you've found at least the basics of how that control works I think a lot of people, including myself, would be grateful if you could explain its use. Would be nice if you could save us all searching for the examples and doing all the tests you have presumably done on this already.
Both i0n0s and I (and probably others) have implemented systems to manage dragging groups of controls in order to make pseudo-windows. i0n0s's system is used in RTE but has already been released as a separate script, but mine is only used within SPON Map.
-
DialogShowModal (http://www.ofpec.com/forum/index.php?topic=32784.0)
But please explain more about CT_CONTROLS_GROUP since I haven't heard anything about them.
-
Oh, I'm sorry for not explaining Control Groups. I really thought this is "common knowledge" and I just rediscovered the wheel (once more)...
class RscDialog {
...
class objects {};
class controlsBackground {};
class controls {
class MyControlGroup {
type = CT_CONTROLS_GROUP; // 15
x = 0.1;
y = 0.1;
w = 0.4;
h = 0.4;
class VScrollbar { color[] = {1,0,0,1}; width = 0.025;};
class HScrollbar { color[] = {1,0,0,1}; height = 0.03;};
...
class controls {
class MyText : RscText {
x = 0.2;
y = 0.2;
...
};
class MyPicture : RscPicture {
x = 0.8;
y = 0.8;
...
};
// ... more controls for the control group ...
};
};
// ... more controls for the dialog...
};
};
You can think of a Control Group as an iframe in HTML.
- It is a container for other controls.
- It defines a new origin for its controls (MyText would be draw at 0.3/0.3).
- It has scrollbars to access the controls that does not fit in the visible area (you'd have to scroll to see MyPicture). The scrollbars can be turned off by setting height/width to 0.
As soon as one Control Group (or one of its controls) gets the focus this Control Group becomes the foremost control.
I can't provide a clean example yet (only a very messy one) but if you want to dig deeper take a look at the Armory and it's description.ext (search for "class G_Dialog", it defines the "dialog" that you see when you enter the Armory).
To be continued...
-
Hmm, I don't have this in my library.
Is it possible to give an idc to the control group? Otherwise the only advantage would be that it brings the controls in the foreground.
-
Sure. Here's the definition that Arma uses (extracted via dumpConfigTree):
class RscControlsGroup {
type = 15;
idc = -1;
style = 0;
x = 0;
y = 0;
w = 1;
h = 1;
class VScrollbar {
color[] = { 1, 1, 1, 1 };
width = 0.021;
};
class HScrollbar {
color[] = { 1, 1, 1, 1 };
height = 0.028;
};
class Controls {};
};
-
Gave it a try, but didn't manage to display background controls in the ControlsGroup :(
-
Yes, class controlsBackground { ... } seems not to be supported. But you probably won't need them for "windows" anyway (at least I can't think of any useful application for them in this case).
When I realized that every "windows" would require several IDCs for its controls (so I can modifiy them on-the-fly) I came up with the idea of having IDC-less controls: Who needs an IDC if you have a reference to the control stored in a variable?
Hrmm, how to get these references? Event handlers! Well, too bad the "onLoad" event is not supported for controls. The next event I took a look at was "onTimer" but I couldn't get it to work at all (wtf is the "setTimer function"?). :(
Edit: "Active texts" and "buttons" support quite a lot of events. Looks like I have to build the windows out them instead of "static texts".
-
I can think of lots of useful applications with background ;)
Image the RTE without the black background and try to use the interface. This is something strange and ugly.
The problem without background is that you need to fake background. But I already faked the background and won't gain any advantage.
ControlsGroup seems a nice idea, but looks like BIS didn't finished work on it :(
About your references:
Just use idcs. There is no problem on them since they only have to be unique for the dialog.
The dialog itself don't need an idd because of OnLoad.
-
:D No doubt, backgrounds are useful! My point was there is no need for a separate controlsBackground class because you can simply put your background element in the controls class. I fail to see the sense in having two "stacks" of controls.
About the IDCs: I'll use the preprocessor for auto-numbering the controls until I find a better solution.
-
I've no idea why we actually need backgroundControls and controls in displays. They seem to do the same as if everything is together in one of the lists. If you know of a functional difference, then I'd be curious to know.
-
Background controls don't get in front of foreground controls. This can be useful in some cases.
-
When I realized that every "windows" would require several IDCs for its controls (so I can modifiy them on-the-fly) I came up with the idea of having IDC-less controls: Who needs an IDC if you have a reference to the control stored in a variable?
I found another way: adding "methods" to the classes. But I don't really like it...
class MYTAG_RscBorder {
...
MYTAG_Resize = "_control ctrlSetPosition [_offsetX, _offsetY, _winW, _winH]";
...
};
class MYTAG_RscBackground {
...
MYTAG_Resize = "_control ctrlSetPosition [_offsetX + _borderW, _offsetY + _borderH, _winW - 2*_borderW, _winH - 2*_borderH]";
...
};
So each control knows how to calculate its own size. The "resize" code then looks like this:
_borderW = ...
_borderH = ...
_offsetX = ...
_offsetY = ...
_winW = ...
_winH = ...
{
_control = ...
_controlCfg = ...
call compile getText (_controlCfg >> "MYTAG_Resize");
} forEach _listOfControls;
Edit: this does not allow for IDC-less controls but keep the resize code much cleaner and (mostly) separated from the controls involved (except for the variable initialization part).
Edit #2: All it takes to resize a window now it to change two variables. The rest is done automagically...
-
Looks nice :)
Continue to work on it!
-
Very nice indeed. :good: