The problem with your way is that if someone uses onDragEnd, it’ll be triggered with your fake click, potentially breaking things.
This is what’s happening. I’m using a string representing from which slot the dragging starts. It’s set in onDragStart, but your way bypasses this, and for good reasons, but because of that, the variable is null and crashes the whole thing.
I’ll stick with my version for now.
@madjack said: The problem with your way is that if someone uses onDragEnd, it'll be triggered with your fake click, potentially breaking things.This is what’s happening. I’m using a string representing from which slot the dragging starts. It’s set in onDragStart, but your way bypasses this, and for good reasons, but because of that, the variable is null and crashes the whole thing.
I’ll stick with my version for now.
Is the draggable actually starting from this droppable? If so, it is already being stored in DragElement as the element itself. You can access it calling:
[java]
DragElement.getParentDroppable();
[/java]
Just remember to call clearParentDroppable() if you’re swapping things via code.
This example shows how:
This is how I create a new draggable. It’ll be put inside a drop container.
[java]
Element slotHolder = screen.getElementById(“slotNum” + ie.getNewSlot());
DragElement is = getInvSlot(screen, ie.getNewSlot(), pos, size, new Vector4f(), imgPath);
is.bindToDroppable(slotHolder);
[/java]
That’s it.
When that happens, the icon is centered inside the container. onDragStart and onDragEnd are not triggered or called. They don’t need to be. Your way fakes a click and -that- triggers onDragEnd.
The draggable isn’t started from anywhere. It’s attached to the container and that’s it.
@madjack said: This is how I create a new draggable. It'll be put inside a drop container.[java]
Element slotHolder = screen.getElementById(“slotNum” + ie.getNewSlot());DragElement is = getInvSlot(screen, ie.getNewSlot(), pos, size, new Vector4f(), imgPath); is.bindToDroppable(slotHolder);[/java]
That’s it.
When that happens, the icon is centered inside the container. onDragStart and onDragEnd are not triggered or called. They don’t need to be. Your way fakes a click and -that- triggers onDragEnd.
The draggable isn’t started from anywhere. It’s attached to the container and that’s it.
Ok… so what does getInvSlot do? And getNewSlot?
You may not need to do what’s contained in these functions. If you just create the DragElement and bind it to the droppable, everything else should happen for you.
EDIT: GUI-wise that is. You’ll obviously need to manage the data side of things however you do.
getInvSlot() returns a DragElement… I thought that was obvious.
If you must know, ie = InventoryEvent. That class contains all the info I need when there’s a Gui event. In short, it doesn’t affect the GUI itself at all.
What does ie.getNewSlot() do?
What code is contained in onDragEnd that would not work if the element was added this way?
I’m trying to narrow down the differences between what you are doing and what I’m doing in the example I posted above. The example above works without problem. I’m using both onDragStart and onDragEnd for dynamically created DragElements and I’m still not seeing a problem when binding the drag element.
To test this, uncomment these two lines in onMouseButtonEvent in the example (which sets up the scenario you are using, minus the network messaging):
[java]
// evt.setConsumed();
// de.bindToDroppable(screen.getElementById(“InvSlot1″));
[/java]
Chris, calm down.
I didn’t say it didn’t work. I said your way triggers onDragEnd, causing issues because I do things when I start dragging. The other commits you made seems to have removed the other problems I was having.
So, except for the above, it’s fine.
With that said, I will still continue to use my way because it does the job without broadcasting any event. I will warn you though, if someone else uses bindToDroppable and sets things in startDrag to be used in endDrag, they will have some issues. null will have to be checked or whatever, depending on what they’re doing.
Didn’t notice the question.
Imagine something like this:
[java] DragElement itemslot = new DragElement(screen, pos, size, v4, path) {
private String fromSlot;
@Override
public void onDragStart(MouseButtonEvent evt) {
fromSlot = ((Element) this.getParent()).getUID().substring(7);
}
@Override
public boolean onDragEnd(MouseButtonEvent evt, Element dropElement) {
// do stuff with that variable. fromSlot will be null. CRASH!
someMethodToDoThings(Integer.valueOf(fromSlot));
}[/java]@madjack said: Chris, calm down.I didn’t say it didn’t work. I said your way triggers onDragEnd, causing issues because I do things when I start dragging. The other commits you made seems to have removed the other problems I was having.
So, except for the above, it’s fine.
With that said, I will still continue to use my way because it does the job without broadcasting any event. I will warn you though, if someone else uses bindToDroppable and sets things in startDrag to be used in endDrag, they will have some issues. null will have to be checked or whatever, depending on what they’re doing.
Didn’t notice the question.
Imagine something like this:
[java] DragElement itemslot = new DragElement(screen, pos, size, v4, path) {
private String fromSlot;
@Override
public void onDragStart(MouseButtonEvent evt) {
fromSlot = ((Element) this.getParent()).getUID().substring(7);
}@Override public boolean onDragEnd(MouseButtonEvent evt, Element dropElement) { // do stuff with that variable. fromSlot will be null. CRASH! someMethodToDoThings(Integer.valueOf(fromSlot)); }[/java]</blockquote>Ok… this is starting to help me narrow down the issue. Is there a drag element actually in slot 7 already? Or is slot 7 your cursor or something?
Actually, I think the null check is necessary in your code.
You have two possible scenarios that could happen, but your only accounting for one in the onDragEnd method.
If you know this variable could be null depending on where you’re adding the drag element from, why wouldn’t you perform the null check?
Reason I even mention this is, the method I use for placing these ensures that no matter how you set up the drag element it will lock to it’s parent or return to it’s previous parent or remove itself completely exactly how you defined the drag element to work. This might not be a problem in your case, but if by some chance you have a situation that does not follow the rules you set up for inventory in your bind routine, you’ll end up having to change it.
Using the provided method with a null check will stop this from ever occuring in the future.