Documentation
Target (queryTarget)
More extensive documentation of EENum Target.
Meaning of Each Option
ROOT → The top-level workspace that contains everything. Think of it as the overall project space.
RESOURCE → The specific file you are working on (in this case, LightControllerExample.oaam).
MODELROOT → The main model defined inside the file — the core structure of your system.
EDITORROOT → The object that serves as the starting point for what you are currently editing in the model editor.
PARENT → The direct container or upper-level element of the current object (for example, the task or function that contains your current item).
Example
Go to https://xgee.de/en/ and start the demo verison of XGEE, open the LightControllerExample.oaam file, and navigate to the Functions editor and go to the Task Task Bool DS Sensor 1.
Enum Option |
For Task Bool DS Sensor 1 |
|---|---|
ROOT |
Workspace |
RESOURCE |
LightControllerExample.oaam |
PARENT |
Functions |
MODELROOT |
Architecture |
EDITORROOT |
Functions |
Explanation
In short, queryTarget tells the system at which part of your model the query starts — whether it’s the top-level root, the parent object, or the current editor context. Most often, you will choose PARENT.
Moreover, in XGEE (and EOQ in general), everything is treated as an object i.e., including features such as associations and containments.
For example, the Functions is an instance of the class Functions. It has the functions containment that contains all the individual tasks in the model However, it’s not a visible model element in the eclipse editor — it exists as a structural container in the underlying model.
So when you set the queryTarget to PARENT, it means that the query is evaluated in the context of the Functions object, which holds all task instances in the model. This design allows for very flexible and powerful querying within the XGEE environment, since queries can dynamically traverse and reference various model layers.
For instance, if you have a signal connecting two functions, that signal itself is also treated as an object with features such as source and target. This consistent “everything-is-an-object” concept makes it possible to query and manipulate nearly any aspect of your model in a uniform way.