comparison libpurple/protocols/msn/slplink.c @ 17137:8ed7b2d32ad1

slpcall now explicitlt references its xfer and unreferences it when it is destroyed. While it *looks* like this should *probably* have happened anyways due to the interactins between xfer_init, xfer_end, and xfer_cancel_remote, having the xfer's owner make this explicit makes the process less fragile and more obvious, and it may fix a crash as the slp is destroyed. Fixes #1070

17136:0b7110b9e368

	slpcall->session_init_cb = send_file_cb;
	slpcall->end_cb = msn_xfer_end_cb;
	slpcall->progress_cb = msn_xfer_progress_cb;
	slpcall->cb = msn_xfer_completed_cb;
	slpcall->xfer = xfer;

	slpcall->pending = TRUE;

	purple_xfer_set_cancel_send_fnc(xfer, msn_xfer_cancel);

17137:8ed7b2d32ad1

	slpcall->session_init_cb = send_file_cb;
	slpcall->end_cb = msn_xfer_end_cb;
	slpcall->progress_cb = msn_xfer_progress_cb;
	slpcall->cb = msn_xfer_completed_cb;
	slpcall->xfer = xfer;
	purple_xfer_ref(slpcall->xfer);

	slpcall->pending = TRUE;

	purple_xfer_set_cancel_send_fnc(xfer, msn_xfer_cancel);