New question of the day: how to use setHolder

[jreddin1]

OK. My extension now is able to create, retrieve, update and delete data from the DB when run on the host. In addition, I figured out that if I go into the db.xml and add a "holder" tag to one of the entries, then a player can modify or delete that entry. A player still cannot add a new entry.

It has something to do with the way I'm creating a new node. I'm using something like:

local node = window.getDatabaseNode().createChild();

which works fine for the host, but node is set to 'nil' for the player.

I know once I have a node created, I can use addHolder to associate it with the player, but how do I do that when the node is nil?

Obviously, I'm missing something. Who would like to be my helpful educator today? :o

BTW: I was wrong about being able to use addHolder. Only the GM can do that. I found out by actually trying it. So much for what "I know"...

[Trenloe]

Set the holder on the base (parent) node before you create the child.

[jreddin1]

Hmm. Interesting idea, but doesn't work. A player can't add a holder to a node -- only the GM can. I can't add a holder for every player that joins, either, because then they would all see each others entries. Not something I want.

As far as I can tell, the only way to do this is to use:

Interface.requestNewClientWindow("some_window", window.getDatabaseNode().getNodeName());

That's basically how Notes works. It also adds the node with the "holder" tag in place and ready for the player to use. The only thing is, it forces you to open a new window, while adding a DB node. It works, but it's not what I really want.

The way I want it to work, is how it already works on the GM screen: You hit the add button, a new entry appears on the windowlist, and you can edit the entry in place. Nice and clean, easy and obvious. That's what I want the Player to be able to do.

Instead, on the player side, I have to rig it so that when you click 'add', a new window gets created with the new node (which also shows up on the windowlist), that the player can enter data on and close. The entry gets added to the windowlist (although, I haven't figured out how to automatically propagate the change in the window to the entry in the list).

I'm looking at windowlist.createWindow and windowlist.createWindowWithClass, but I'm not hopeful.

[jreddin1]

windowlist.createWindowWithClass() doesn't work either. It works great at adding an entry to the list. It just can't create a DB node for it. So far, the only way I've found for a player to create a new node is using Interface.requestNewClientWindow().

That sucks. Hopefully, someone knows a different way to go.

[Moon Wizard]

Yes, all requests for a player to create a new child node under a parent node they don't own must go through the GM machine. The requestNewClientWindow is one way to do that, and the other way I've seen is to send a special OOB message to the host and take an action based on that message (i.e. create DB entry, add holder, open window, share to player).

Regards,
JPG

[jreddin1]

I saw the OOB message, but hadn't really looked into it. That sounds like it might be what I need. I'm going to play with it, and let you know.

Thanks!

[jreddin1]

OOBMessage works great! It let's me do EXACTLY what I was looking for! Thank you very much! I will be using that a lot more, I think.

Now if I can just get the button cycler to work correctly... I'm so close to having this extension done I can taste it! (And then I'll be writing part 2 of my too long tutorial!)

[TASagent]

jreddin1, do you mind sharing what you're working on?

[jreddin1]

I did a tutorial on creating a window as Part I of a series I'm planning on doing. As part two, I'm adding content to that window that allows the players to enter different types of messages that they use frequently, and then be able to send those with a single button click. I've attached a picture of what it looks like.

10387

[jreddin1]

Fixed the button cycler problem. It was a race condition. When the host received the OOB message and creates the node, the player received the node update before the host could set the holder tag. The trick was just to find the right place to check the button against the node and reset as needed. Actually, final code fix was basically:


btn.setReadOnly(srcnode.isReadOnly());