Question about reference to window a tokeninstance is in

[Dachannien]

I hope this question hasn't been asked around here before, but....

How do you get a reference to the imagecontrol (i.e., token container) that a particular tokeninstance is in? Specifically, I already have a reference to the tokeninstance in question, but I want a reference to the imagecontrol containing it. I know you can get the databasenode that contains the tokeninstance's info, but I need a reference to the imagecontrol containing the token so that I can modify that control.

(I'm trying to implement automatic torches/lightsources linked to the combat tracker. Not sure it will work, but it's worth a shot.)

[joshuha]

I have done this before and when I get home tonight I will see what I did. I think you just need to walk up the DB to get to the image window information and I used that with a findWindow() to verify that image was open and get the window instance. From there you could access all the tokens with getTokens() and access what image controls are provided. Note that right now you only have a limited amount of scripting access to image controls and token controls.

[Dachannien]

Well, the getContainerNode() method from tokeninstance gets you the proper image node (e.g., image.id-00001.image). Apparently, I'm uncertain how that is supposed to work with findWindow() due to the somewhat sketchy documentation. It says you're supposed to pass it the windowclass, which should be "imagewindow" in this case, and then a string indicating the data source (which, as far as I can tell, would be like "image.id-00001.image" depending on the id number). But there's a post elsewhere around here where it's implied that you're supposed to hand a databasenode reference directly as the second parameter.

Of course, none of those has actually worked for me, so I'm not sure what to think now. :(

Edit: Okay, apparently it works with either a string or a databasenode reference, but I was giving it the wrong one. It does return a windowinstance with the parent node (e.g., image.id-00001). I'll have to see whether it's the right one, of course.

Another edit: I think I've figured it out. Assuming tref is a tokeninstance reference:


wref = Interface.findWindow("imagewindow", tref.getContainerNode().getParent()).image

gets you a reference to the imagecontrol that contains the token. Note that the windowcontrol that contains the imagecontrol is the only thing you can get with findWindow, because that's the top-level window. That's what getParent() is for. Then you specify image as a child object to get a reference to the imagecontrol. (This is at least how it works in the default ruleset and in variants that use its structure.)

Kind of weird - you go up one level in the database tree, move over to the window tree through findWindow, and then descend one level in the window tree.

As for whether I can do what I'm hoping to do now - well, time will tell, I guess ;)

[Dachannien]

Okay... well, in terms of my original project that brought up this question, there are three ways to go about it:

1. Use a circle pointer to outline the area illuminated by a light source. Can't automate this because pointers are not exposed, and the database is structured in such a way that it can't be manually manipulated to add pointers.

2. Use a bitmapwidget applied to the imagecontrol. I don't know why this doesn't work, but I can't see the bitmapwidget at all when I try to add it. I don't get any error messages, including when I call methods on the bitmapwidget, so I know it's been created - it's just not visible (even when turning on visibility, etc.). Either it's positioned somewhere that I can't see it, or it's just not being drawn.

3. Use a separate token to represent the light source. This doesn't work either, because the tokens are quite large (often covering much of the relevant map space) and there is no way to set a token as being "intangible" (see other topics about the potential for using tokens as map construction pieces).

Anyway, it would have been nice, but it'll have to wait until more of the functionality is exposed to scripting.