createDisplay

[ManDay 0]

Any idea how this works?

Requires a top-node/parent. First I though (findDisplay 0) [=GUI] may serve as a parent but it literally displays nothing when called.

From what the name is I think a display is supposed to offer a way to actually "display" something without blocking the movement or any other kind of interaction. Just like cutText may fade the screen with a black Widget (BLACK IN) while the player can still fully interact.

By the way it's somtimes irritating as you can refer to dialogs as displays (findDisplay etc. works for dialogs and returns a "display"-handle for it).

Edit: I was just browsing through "DM24 Road Rage" (Celery) where there is actually an EventHandler assigned to a display. Celery however just used another, already existant display with id=46. It seems that there are several of those root-existant displays. Maybe I find my luck whith one of them.

[ManDay 0]

Okay, is the "Yes I know" to be a joke or do you really know. If yes then go and tell us, please.

[ManDay 0]

/* snipped */

I'm not sure but I got a suspition with regards to the display and dialogs terminology (thanks BIS for your awesome help with that issue. maybe you should claim it in the forum rules so many ppl wont register senseless: "Even tho this is the official forum don't exspect any support from us! We generally don't support our community as other firms do!" - pfff...).

Whatever:

"Displays" refer to absolutl ALL components of the dialog thing. Even Dialogs are Displays. Controls are Displays. Evrything is displays. While dialogs is the name for the top container node which can be spawned root, actual "displays" need a parent node to spawn from.

missiondisplays meanwhile are created without relation to the dialogs -cannot be closed by pressing esc - and interact even after the mission has finished.

so will you break my monolog now and donate me soem comments?

[crashdome 3]

While this thread by itself has certain value to it...

I think you just won the "Most Worthless Poll - EVER" award.

[ManDay 0]

At least a reply

[ManDay 0]

I made a short test right now and it confuses me that the actual interface (Weaponselector,Actionmenu) doesnt seem to belong to Displays at all:

<table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">_str_out = "";

_disp_temp = displayNull;

_ctrl_temp = ctrlNull;

_float_checksum = 10000.0;

_bool_onlyText = true;

for[ { _int_diag = 0; },{ _int_diag < 400 },{ _int_diag = _int_diag + 1; } ]do

{

if( !isNull findDisplay _int_diag )then

{

_str_out = format[ "%1Display #%2 Controls:\n",_str_out,_int_diag ];

_disp_temp = findDisplay _int_diag;

for[ { _int_ctrl = 0; },{ _int_ctrl < 400 },{ _int_ctrl = _int_ctrl + 1; } ]do

{

_ctrl_temp = _disp_temp displayCtrl _int_ctrl;

if( !isNull _ctrl_temp &&( ( ctrlText _ctrl_temp )!="" || !_bool_onlyText ) )then

{

_str_out = format[ "%1%2 (%3,""%4"")\n",_str_out,_int_ctrl,ctrlType _ctrl_temp,ctrlText _ctrl_temp ];

if( ( _int_ctrl%2 )== 0 )then

{

_float_checksum = _float_checksum*_int_ctrl;

}else{

_float_checksum = _float_checksum/_int_ctrl;

};

};

};

};

};

hint format[ "%1\nChecksum: %2\n\n",_str_out,_float_checksum ];

Which returns me only the actual general GUI but not the "sub-interface" itsself. Some of the returns controls are of type 82, but i dont know how to deal with that "container"-type. if anyone knows, please tell me.

€: I tested it in a selfrunning loop while opening my gear-menu. it returns the gear menu as idd = 106.

But in the cpp there is nothing special about it. even tho i can move whilst the gear dialog is open.

i want to create a dialog which does not prevent the player from moving while open. if i just could track the whole stream back to the point where the user calls the action - the last (first) step which is not hard-coded.

any idea where this part can be found?

[UNN 0]

Quote[/b] ]€: I tested it in a selfrunning loop while opening my gear-menu. it returns the gear menu as idd = 106.

But in the cpp there is nothing special about it. even tho i can move whilst the gear dialog is open.

Out of curiosity can you open the gear menu using your own script and still move the camera about?

If you can't then Arma's default engine might be using something different to the CreateDisplay command. Which would explain why we cant recreate the same effect.

If you can, then can you override the display with your own dialog using the same id of 106? That might suggest the Arma engine has the id numbers hadcoded.

Quote[/b] ]At least a reply

It can be a lonely business when your trying to figure out something nobody else has done (or at least nobody else wants to share). Sorry I can offer any help just yet. I want to start using displays myself. Only atm, I have plenty of other things to figure out before I get to that point.

Anyway, thanks for sharing your results.

[ManDay 0]

No I cant when I open the dialog with a normal createDialog-cmd. That's why I want to track the gui back to where it starts. I guess it there MIGHT be a thing depending on how a dialog is called (which would be more a kind of workarround - but would be intresting to know anyway).

but actually the main thing which made me wondering and testing all this is the createDisplay command (as said) requirering a parent-node as the first parameter i wonder which would be the root for all displays. creating a display from one of those existing ones (e.g. 0,12,26,46... etc.) just doesnt work. it will simply not be created.

€: i correct myself. spawing a new display from one of the existing one causes strange behaviour (getting smacked back to the main-menu; causing the mission to terminate.) etc.

nonetheless i think to get a feeling for all this. gimme some more hours and ill know how to create Displays.

[man its 1100 AM over here but its darker than fuckin night... can u believe that ? ]

There are some other questions arising:

While the command for creating a display (for testing purpose the gear-one) in a trigger create the display properly - the same command called within a script causes arma to crash.

[ManDay 0]

Ok that's how I got so far - with testing and even more testing:

createDisplay

Results: Many

Conclusion: None

"PARENT createDisplay NEW" didn't do absolutly anything until called with PARENT equal to "findDisplay 0".

But even with something self defined in the description.ext (custom dialog) it didn't work. Thus, ( findDisplay 0 )createDisplay "myTestDiag"; didn't work.

The only thing I got it to work was with Dialogs already defined in the config.cpp. Therefore ( findDisplay 0 )createDisplay "RscDisplayCampaignLoad"; works - but only if called from the onActivation-Line of a trigger.

If called from a script the application crashes!.

Now may someone send BIS a bomb to wake those ...guys up - so they will help us with their program. It's just ridiculous they let us guess and desperate here in their support-forums. Don't bother BIS, with that sort of commited support you will loose any needs for support in the future.

[sickboy 13]

I'm not sure but I got a suspition with regards to the display and dialogs terminology (thanks BIS for your awesome help with that issue. maybe you should claim it in the forum rules so many ppl wont register senseless: "Even tho this is the official forum don't exspect any support from us! We generally don't support our community as other firms do!" - pfff...).

Sent Suma a pm? That's how I get my answers.

Quote[/b] ]Now may someone send BIS a bomb to wake those ...guys up - so they will help us with their program. It's just ridiculous they let us guess and desperate here in their support-forums. Don't bother BIS, with that sort of commited support you will loose any needs for support in the future.

They seem to be "AFK" since few days/weeks, maybe they're back at or before Queens Gambit Release? In the usual days, there's an answer by Suma here and there.

[Spooner 0]

"Displays" refer to absolutl ALL components of the dialog thing. Even Dialogs are Displays. Controls are Displays. Evrything is displays. While dialogs is the name for the top container node which can be spawned root, actual "displays" need a parent node to spawn from.

This is what I had assumed from what I'd read, but so far I've only defined dialogs in description.ext. I'd supposed that a dialog would be what I'd usually call a "modal window" and a display would be a "widget/component"?

I would also very much like to see if it is possible to create displays that don't interfere with normal play as you've described. Please do keep us informed of your progress.

I'll be moving onto looking at displays themselves soon, since I've been considering if it was feasible to create a window manager API by creating widgets on the fly with createDisplay. What I'd like to make is some of the normal GUI API components such as widget spacers and widget packers. Hopefully, this would make dialogs a lot easier to lay out for everyone and allow for more dynamic creation and alteration of dialogs and dialog components. I'm assuming, of course, that such an API hasn't already been created and I just don't know about it!

[ManDay 0]

Just my words/thougts in your mouth. I think the point where I will continue from gonna be display #46.

assumedly it's the sorta presumed root-node we need. indication and evidence is brought along by some effects:

closing #46 will terminate the mission with the according end-code. => this seems a reasonable sign as "our" displays (child-nodes) are only supposed to run within a mission.

#46 is not filled with any elements/controls by default. it seems quasily preordained for beeing filled with extern dataleaves.

#46 is (beside #0 - the "uber-gui" containing the mainmenu for instance) the only one responding to a createDisplay instruction.

Now this is what I can give you as a hint. What I still fail to do is getting my own displays to work there. as said only the rsc´s defined in the config.cpp work so far.

now let me say some words to that data in the config.bin/cpp: the classes which can be called are derived from a simple template RscStandardDisplay

access = ReadAndWrite;

movingEnable = 0;

enableSimulation = 0;

enableDisplay = 0;

Still, the classes which can be called are under ::-top-namespace. different from - for instance - Ressources. Ressources (which can be called with cutRsc etc.) have to be defined under RscTitles::-Namespace and wont work under toplevel-NS.

But still defining my own classes in the description.ext for a call from createDisplay doesnt commit. Using the script i posted above in a loop you can observe all open dialogs/displays and you will see literally nothing when demaning your custom dialog.

sometimes you even find a more special behaviour which implys that there is another part in the arma data-archives determinating how createDisplay will work on certain dialogs.

opening the "teamswitch"-dialog with "RscDisplayTeamSwitch" will bring along a surprising side-effect: the timeAcceleration is suddenly changing to =0.1 and will drop back to normal when the dialog is closed even tho there is no implication in the actual definition of the dialog.

beside all that there is a common thing along all those dialogs: they close when the appropriate button is pressed. there are also other divergences which cannot be founded in the config.cpp definitions but rather have to be defined somewhere else. anoter example:

"RscDisplayGear"-display will appear in the list of open displays (see my script) while the "RscDisplayTeamSwitch"-display doesnt. it just exists without appearing there. atm i cant tell whehter the teamswitch is ony a exception so i will try further default-displays.

as you see: i still got a lot to figure out.

€: okay- im absolutly sure now: there is further information stored somewhere else. information which controls how a certain default-display behaves. example:

2 displays: "RscDisplayMissionEnd" and "RscDisplayInterrupt"

both contain roughly the same data (just some buttons, text and stuff) and no additional attributes apart from the idd. both derived from the same class (defaultdisp) they still behave completly different when called.

so there we need to find something.

[weedomatic 0]

Hello,

does it really have to be the createDisplay command? I myself tried getting createDisplay to somehow create a modal dialog, but I gave up due to insufficient documentation and too much time wasted due to knowledge induction processes, i.e. trial and error mainly. I found this Thread and especially the contained example particularly useful in creating displays that do not require any direct user interaction, i.e. non-blocking dialogs as some here put it.

To put my part in a nutshell: Switching from createDisplay to titleRSC[] did it for me. Also, having the line onLoad = "GUI=(_this select 0)";  in your GUI-definition (mine is contained within a RscTitles class) gives you a nice reference (GUI in this case) to control your GUI-elements. If you didn't understand the last part, maybe you will after studying the example mentioned above or after some less lazy person has explained it. If, however, you are "just" trying to do something like this ('non-blocking' display, controllable controls), I might elaborate a bit more. I am not being arrogant, just lazy.

Bye,

W

Edit: Grammar

[crashdome 3]

Has anyone tried to define a "display" in an addon config rather than the description.ext file?

[UNN 0]

Quote[/b] ]Has anyone tried to define a "display" in an addon config rather than the description.ext file?

Take a look at the EditorUpdate V1.02 addon, that does.

[ManDay 0]

Hello,

does it really have to be the createDisplay command? I myself tried getting createDisplay to somehow create a modal dialog, but I gave up due to insufficient documentation and too much time wasted due to knowledge induction processes, i.e. trial and error mainly. I found this Thread and especially the contained example particularly useful in creating displays that do not require any direct user interaction, i.e. non-blocking dialogs as some here put it.

To put my part in a nutshell: Switching from createDisplay to titleRSC[] did it for me. Also, having the line onLoad = "GUI=(_this select 0)"; in your GUI-definition (mine is contained within a RscTitles class) gives you a nice reference (GUI in this case) to control your GUI-elements. If you didn't understand the last part, maybe you will after studying the example mentioned above or after some less lazy person has explained it. If, however, you are "just" trying to do something like this ('non-blocking' display, controllable controls), I might elaborate a bit more. I am not being arrogant, just lazy.

Bye,

W

Edit: Grammar

Yes. As I said in my one of my above Posts ressources are a way to create it when redefined in RscTitles. unfortunally ressources just dont offer as much interactivity and customisation as displays do. with ressources you are just way to restricted.

anyway: i'll try to just mod my bin.pbo and add a own dialog (just a facsimile of one of the default displays) with a different nae - just to try out whether this will work. if it works we got a starting point for further research.

ill do this tomorrow - hopefully you achieve some results too.

[weedomatic 0]

unfortunally ressources just dont offer as much interactivity and customisation as displays do.

Really? I did not have any problems in telling the displays to do heterogeneous and dynamic/runtime actions (, yet!. Explain, please.

[ManDay 0]

Well, at least for me - I dint get any access to the controls in ressources thru scripts (like ctrlSetText etc.) they somehow dont exists to the gui api. Nonetheless ressources are always limited to a certain amount of time (duration) and they are forced to fade in and fade out (~0.5sec).

[weedomatic 0]

Things have come to a temporary halt for me as well. Access and dynamic interaction to/with resources worked well ... as part of a mission with some custom .hpp's,  description.ext. Porting the knowledge and code from  that to an addon, i.e. config.cpp, was trickier than I thought first, though. I have never gone really deep into making addons before, so I might be missing things due to lack of knowledge. However, my biggest problem atm circles around not being able to get hold of the display. Hence, I cannot get control of its children. Neither via idd nor via var' or the like does it seem possible to find(Display) it and assign the display to a var in order to manipulate its children. Changing idd's was not of great help, too. Your difficulties remind me of mine now, somehow . I will do some more research and tests later.

[ManDay 0]

I can't follow you right now. What exactly do you mean? May you please respond straight to the points I listed in my above post

btw: I need a BIN-Encoder right now to load in my facsimle. Where can I get one from?

Okay. Laza-Editor works great for that. Ok - ill try my facsimile now. Lets hope for the best:

edit:

(at least not with laza-editor) this means i still need a working BIN-packer. does anyone have one for me?

[weedomatic 0]

Quote[/b] ] I can't follow you right now.

Using, manipulating, and raping displays/resources was not a problem as long as I was testing things on mission-level, i.e. I used description.ext, some hpp's and sqf's to build a custom, controllable display. My plan was to first get experience with resources per se by what I just said and then port it to a more generic level (addon) so no missions have to be altered to use the custom display(-s). Currently, the main problems are the dependency on the main ingame-UI (my display fades in/out, uncontrollably) and inability to manipulate the display during runtime. These problems I had not had and seen, before I switched to config-level -- and now I see more parallels to your "paradigm" as well.

Right now I am trying to make the display a global object via variable-assignment in its onLoad-attribute, so that scripts within the addon can directly manipulate it. So far, all I get is a null-object, no matter how I try to make the display available to scripts within the addon. Calling scripts in onload of the display is successful -- passing the display to them as argument or assigning the display to a global var in onLoad did not work, sadly. I'll go and waste some more of my vacation and see if I can do something about that annoyance.  

Edit: Here's some more tools for your purpose: ArmA: Community Tools.

[ManDay 0]

Again: Are you able to use ctrlSetText on Data spawned with cutRsc?

btw: In this thread I don't want to talk about how to get all this ideas running with modding the config - as you see in my above post modding is nothing for me. No UnRap is only for unpacking - it cant pack .cpp into .bin.

[weedomatic 0]

Again: Are you able to use ctrlSetText on Data spawned with cutRsc?

Yes, plus more -- but only within a mission, i.e. by means of custom files and code in the mission folder at the moment.

Edit: Apologies, I was using titleRSC.

[sickboy 13]

ManDay, you can get rapify from mikero dos tools or use Eliteness by mikero.

There should however not be a reason to rebin it, especially not for testing, just remove the bin and keep the cpp.

[ManDay 0]

Again: Are you able to use ctrlSetText on Data spawned with cutRsc?

Yes, plus more -- but only within a mission, i.e. by means of custom files and code in the mission folder at the moment.

Edit: Apologies, I was using titleRSC.

1.) Do you have a bin-packer for me? I know the list you posted.

2.) I don't understand how you were able to access a data spawned with titleRsc as they dont register (read above). At least for me it doesnt work. I.e: If I call titleRsc I cannot access the spawned Ressource with findDisplay. So will you please tell us you achieved that?

3.) I don't loose the feeling you are getting away from the topic (createDisplay) - will you please either stick there or stop to confusing me?

€: Thanks a lot sickboy. I was already desperate. Ill just keep the cpp then.