Making grouped objects draggable

[Tan Teow Chye]

I have a group "Sphere_B_parent" comprising an image "Sphere_B", a text field "B" and a group of 8 text fields "e_group_B". I used the mergeTBobjects(HTML) function to merge them together, making sure that parentTBname is set to "Sphere_B_parent". I then used the createDraggableObject(HTML) function to make the image "Sphere_B" draggable. When I export my book to DHTML, the image "Sphere_B" disappears. Can I create a draggable group if one of group's member is an image?

[Clifton]

A screen shot or example may be needed to understand where the missing logic is here.

I just put together a similar test case and the image could be dragged freely around. Perhaps you need to double-check the spelling of tbName parameter when creating the draggable object. Also you should generally merge FIRST, then execute create the draggable object to avoid losing the link to the events that drag the object.

merge_n_drag.zip

Example of this (TB v10.5)

(126.28 KiB) Downloaded 111 times

[Tan Teow Chye]

It works perfectly now. I must have made some mistakes along the way. Regards.

[Tan Teow Chye]

I noticed that the draggable grouped object disappears when I shift the two execute scripts statements to below the "Set left of Group "Sphere_C_group" and "Set top of Group "Sphere_C_group" action statements.

The text field "Debug" also shows the left and top of the group "Sphere_C_group" wrongly as "0, 45" instead of "5700 and 4500". The real time notify of the draggable group also ceased to function.

Besides ensuring that mergeTBObjects comes before createDraggableObject, does it matter where execute scripts are placed?

For the time being, I used "before and after images" to show what happens when a negatively charged sphere is brought into contact with a neutral sphere but I am just very curious over why the order of the two scripts with respect to the other actions matters so much.

[Clifton]

This looks like a rather complicated action sequence.

First let me explain why things disappear or report incorrect positions in this scenario.

When you make an object draggable WITHIN a set of objects that have been merged, it becomes a child object of the new element created by merging the group. Before merging the objects, all reported positions are relative to the upper left corner of the ToolBook page. Once merged, the new origin of the object is the upper left corner of the newly created merged element. So if you drag your object to the upper left corner of the merged group of objects, the position will be 0, 0 regardless of where the entire merged group resides on the page. This is because the child object no longer has the ToolBook page as its parent element. If you need to get the position relative to the origin of the page, you would have to get the position of the parent object of which the draggable object is a child and add the x, y coordinates of the parent to the reported position of the child.

Second, let's explain why things disappear in your action sequence.

When you merge objects, the parent/child relationship of the objects change so they can be manipulated as a single entity. ToolBook is not designed to understand this relationship. Therefore, if you use ToolBook actions to move objects that have been merged, they will be moved relative the page origin but the objects no longer are using the page as it parent. Therefore, the actions that move merged objects potentially will move them outside the bounds of their parent object which may make them off the entire page and out of view. So in your scenario, you have to account for the changed parent/child relationship in order for actions that move object relative to the page to work as expected.

Why did the realtime notify stop working?

There could be several possibilities, but given the complexity of this action sequence, making at least one draggable and then moving things around within the group again, it is possible that the event listener simply fails to fire (having lost its target relationship). You may be able to get it fire correctly and to correct all the other anomalies by at least moving the PowerPac functions to the very end of the action sequence. This may or may not fix all of the related issues because you seem to have some sub-groups here as well.

I'm not suggesting you can't do what you want, but you will need to do some debugging to make sure your actions are really accomplishing what you want before you add additional ones or features. Sometimes a few simple objects are easier to manage than one that has grown so complicated. There also comes a point where you have to set up some delays in the action sequence to ensure that things happen in the right order.

[Clifton]

Of course, it is always a good idea for this type of stuff to keep up to date with the latest beta releases. The beta is soon to be released as a production release, so you be confident that it is ready for use in all your projects.