Hi,
I found that tl_new and text_new return values owned by others, as the consequence of that, tl_delete deletes the wrong object.
Normally, handles returned by some creation function are "random" numbers, not positive integers as in MC, to maintain its uniqueness and avoid the aforementioned conflict problem.
Any inputs? thanks.
-kernel
tl_new, text_new return values owned by others
- TJ
- Posts: 7740
- Joined: 29 Aug 2006
- Location: Global Citizen
- Has thanked: 1033 times
- Been thanked: 2221 times
Re: tl_new, tl_new return values owned by others
Hi,
I found that tl_new and tl_new return values owned by others, as the consequence of that, tl_delete deletes the wrong object.
Normally, handles returned by some creation function are "random" numbers, not positive integers as in MC, to maintain its uniqueness and avoid the aforementioned conflict problem.
Any inputs? thanks.
-kernel
GIGO
- JoshM
- Posts: 2195
- Joined: 20 May 2011
- Location: The Netherlands
- Has thanked: 1544 times
- Been thanked: 1565 times
- Contact:
Re: tl_new, tl_new return values owned by others
(Just to check we're on the same page: you mention `TL_New()` and `TL_New()` here. Is your question about comparing two of the same keywords?)I found that tl_new and tl_new return values owned by others, as the consequence of that, tl_delete deletes the wrong object.
When you get the trend line ID (like with `TL_GetNext()`), you can specify the drawing origin. With that you can have `TL_GetNext()` return only trend line IDs from trend lines owned by the current script (and thus prevent removing the wrong trend line). (If this is what you meant with "values owned by others".)
If I assume you're comparing `TL_New()` with another drawing keyword (like `Text_New()`), then both keywords can return the same numerical ID. But this is by design and documented. That is, `TL_New()` returns "a trendline-specific ID number"(and no "drawing-specific ID number").
Each text, trend line, or arrow drawing gets its own ID number. And so there is no conflict problem from the standpoint of PowerLanguage.Normally, handles returned by some creation function are "random" numbers, not positive integers as in MC, to maintain its uniqueness and avoid the aforementioned conflict problem.
(There might be in your script, but that's then a conflict that probably should be coded around. Since PowerLanguage provides no native capabilities to iterate over a collection of drawings, features to distinguish between drawings of one type versus those of another are also missing.)