| 08-03-2007, 10:41 PM | #1 |
I have heard that they do... if they do leak is it worth the trouble of cleaning of not? |
| 08-03-2007, 10:43 PM | #2 |
Do you mean conditionfunc? (and boolexpr) If yes then they don't. Trigger conditions don't leak. |
| 08-03-2007, 11:29 PM | #3 |
conditions in the GUI not in JASS |
| 08-03-2007, 11:48 PM | #4 |
The GUI ends up doing a lot of weird things with conditions, but I don't think they end up leaking. Edit: I'm fairly certain they don't leak, as I think they only create one handle and reuse it and they don't make any assignments that need to be nullified. Also, the conditionfunc and boolexpr are what end up being created regardless of whether you're using the GUI or not. |
| 08-04-2007, 06:42 AM | #5 |
They don't if you don't make boolexpr local variables. Pass them directly as arguments and all will be fine. |
| 08-04-2007, 08:52 PM | #6 |
i think they would because like if i use Trigger: ![]() Condition
![]() ((Triggering unit) is in (Units in (Playable map area))) Equal to Truewouldn't that create a unit group??? |
| 08-04-2007, 09:22 PM | #7 |
There is nothing special about a condition, it is just another function. so the GUI conditions of that kind do leak. but I guess you figured that out already. |
| 08-04-2007, 09:40 PM | #8 |
so then to clean those up it would require me to set all the conditions like that into an if then statement ;/ well least i know that it does leak... |
| 08-04-2007, 11:27 PM | #9 | |
Quote:
boolexprs do NOT leak, as the functions employ some sort of caching. |
| 08-04-2007, 11:50 PM | #10 |
ok but would a NON boolean condition leak? |
| 08-05-2007, 12:37 AM | #11 |
... GUI conditions are held withing a functionthat returns boolean.... the function is then passed to Condition() as an argument... Condition() returns a boolexpr which is used as a triggers condition... this booexpr does not leak, unless you only intend to use it once... and if you want to fix such a leak, you will have to use JASS. (as in fully converted, not just a few lines) and, all condition statements, eg: 1 greater then 0 resolve to true or false. (boolean) |
| 08-05-2007, 12:41 AM | #12 |
Yes, conditions can contain a leak (regardless of which comparison you do), works pretty much the same way as with actions. ((Triggering unit) is in (Units in (Playable map area))) Equal to True Bold=leak. Problem is...you can't fix these in GUI. However a solution would be wrapping your whole trigger inside one If..Then and thus simulating conditions. For example instead of Trigger: Trigger: Trigger![]() ConditionsEdit: Just saw post #8, guess you already knew this, sorry ![]() |
| 08-05-2007, 02:09 AM | #13 |
its amazing to me how there is the yes AND the no answer so definitely from so many ppl ;P |
| 08-05-2007, 03:40 AM | #14 |
That's because people thought you were talking about two different things. So it's not a definite yes or no answer to a single question, but rather a definite yes to one question and a definite no to a different one. Just to reiterate what has already been said in case it isn't clear; boolexprs and conditionfuncs are fine and the handles they use will not leak when using the GUI, but there may be things assigned inside those functions that might leak like groups or regions because there is no way to clean them up using the GUI other than doing something like what SFilip suggested.. |
