WApplication::eraseEncodedObject() ?

Hi,

I'm using Wt's drag and drop system in this fashion:

When I drag a widget to a destination widget, the destination
widget responds to the drop by using the source widget's pointer
(passed from drop event) to get useful data such as a key to a
database record. Then, the destination widget deletes the source.

Here's the problem:

When dragging a source widget to a destination widget twice at
almost the same time (while Wt is 'loading'), a crash happens
(program tries to access a source widget that's already deleted).

I did a (quick) grep and it seems as if the source widget's
implementation does not
delete its entry in WApplication::encodedObjects_ before being destroyed by the
destination widget. As a result, WApplication::decodeObject()
is giving me an invalid pointer to a source widget instead of a null one.

If I could put a function like: app_->eraseEncodedObject(this)
in the destructor of my source widgets, my destination widget
will be able to ignore drop events that carry null pointers to source widgets.

Will Wt provide a function like the above so that encodedObjects_ can
be managed by the user?

I appreciate your time.

Re: WApplication::eraseEncodedObject() ?

------------------------------------------------------------------------------

_______________________________________________
witty-interest mailing list
witty-interest@...
https://lists.sourceforge.net/lists/listinfo/witty-interest

Re: WApplication::eraseEncodedObject() ?

> How do you "delete"? Do you call removeWidget(..)?

No, I delete like this:

delete widget;

Regards,
David

------------------------------------------------------------------------------

Re: WApplication::eraseEncodedObject() ?

------------------------------------------------------------------------------

_______________________________________________
witty-interest mailing list
witty-interest@...
https://lists.sourceforge.net/lists/listinfo/witty-interest

Re: WApplication::eraseEncodedObject() ?

------------------------------------------------------------------------------

_______________________________________________
witty-interest mailing list
witty-interest@...
https://lists.sourceforge.net/lists/listinfo/witty-interest

Re: Methods to create widgets. Points of view.

------------------------------------------------------------------------------

_______________________________________________
witty-interest mailing list
witty-interest@...
https://lists.sourceforge.net/lists/listinfo/witty-interest

Re: WApplication::eraseEncodedObject() ?

> What reason to call delete explicitly?
> As I understand, you works with pointers to WWidget. So, you should use
> removeWidget(..) to let Wt remove widget from the widget tree instead
> of explicitly delete them "manually".

Are you saying explicit deletion doesn't cleanup connections properly?
Using delete also calls the destructors of the widget's base class and
removes itself from the parent just like removeWidget() along with
removing itself signal/slot system before the widget is deleted.

Using removeWidget() will work but managing widgets with no parents
and knowing the right time to delete them is going to be awkward (I
don't know if there will be another signal triggering it's deletion
again).

Let me explain my tricky situation:

In the destination widget's dropEvent(), the source widget doesn't get
directly deleted. Instead the destination widget uses the source
widget's database record key for a server push. This push signals all
listening sessions to delete the widget that has that key. This is an
effort to keep all renderings of the source widget sync'd across all
sessions.(I'm making an interactive map of a building and people
should see each other's influences on objects in the map in
real-time.)

The problem is that the widget doesn't disappear instantly enough from
the screen while during the deletion process and its possible during
the tiny time frame to drag and drop a widget more than once and cause
a crash.

WApplication::encodedObjects_, which is a std::map, helps in
identifying c++ objects in the javascript that deals with dragging and
dropping. Objects set as draggable have an entry created in
encodedObjects_ . But once those widgets are deleted, their entries
still remain. This is an issue because their entries resolve from
unique id strings to invalid source widget pointers that are emitted
by WDropEvents.

There are work-arounds for my problem but it would be neat if a
removeEncodedObject() method existed.

Regards,
David

------------------------------------------------------------------------------

Re: WApplication::eraseEncodedObject() ?

------------------------------------------------------------------------------

_______________________________________________
witty-interest mailing list
witty-interest@...
https://lists.sourceforge.net/lists/listinfo/witty-interest

Re: WApplication::eraseEncodedObject() ?

On Sat, May 1, 2010 at 9:58 PM, David Galicia <dgalicia89@...> wrote:
> I found out an alternative solution that's safer and does away with my
> pointer problems. I also found out why my server pushes made my app slow.
> I'm such a dork for having to create a topic!

It would be good to list the reasons in case anyone else encounters
something similar.  :)

------------------------------------------------------------------------------

Re: WApplication::eraseEncodedObject() ?

>> I found out an alternative solution that's safer and does away with my
>> pointer problems. I also found out why my server pushes made my app slow.
>> I'm such a dork for having to create a topic!
>
> It would be good to list the reasons in case anyone else encounters
> something similar.  :)

In my map program, users can see others drag and drop objects around a
grid of container widgets.

I don't use the dragged widget as a source anymore for a drop event;
instead I use the dragged widget's container as the source. The
container will at least have a longer lifetime than the dragged
widget. For my old way, I couldn't guarantee the dragged widget still
existed (someone may have dragged it to a trashcan widget or it could
have been deleted in a graphic update).

Then, from the destination widget, I would emit a signal at the source
container widget's side that says: "the drop has been completed and
here are the destination coordinates."

Draggable widgets inside the source container will interpret this
signal to see if the drop event applies to any of them. If it does
apply, the respective drag widget will alter its record in the
database with the location of its new parent container.

Then the dragged widget passes its destination and origin coordinates
on the map to a service object that manages server pushes. Any
container widgets having the above coordinates will actualize their
contents again. As a result, everyone on the map program will see the
dragged widget be put in its new spot.

(main point: )
I like communicating via signals versus pointers. With pointers, I
have to hope the pointer I'm using to communicate is still valid.
Also, it keeps my container widget's implementation clean: I don't
want it to keep track of my draggable widgets.

As for me making my server push process go faster, my widgets weren't
interpreting the update event properly: all widgets were refreshing
their contents versus certain ones.

Sorry for being verbose.

Regards,
david

------------------------------------------------------------------------------