A small correction: TkDND wan't allow drops of HTML messages.
These, are stored in a different format, not recognised by TkDND.
George
"Georgios Petasis" <petasis@iit.demokritos.gr> wrote in message
news:e0qpi2$1a0i$1@ulysses.noc.ntua.gr...
> Is dragging an e-mail from outlook the same as dragging one from
> outlook express? If you install the latest TkDND 2.0 alpha 2, and
> you run the dndSpy.tcl (from the TkDND 1.x demos directory),
> then you can drop an e-mail from outlook express to Tk.
> I tried it and it worked for me. Outlook express seems to be
> using the regular types CF_UNICODETEXT & CF_TEXT (among
> others), which are supported by TkDND 2.x.
>
> George
>
>
> "Ramon Ribó" <ramsan@compassis.com> wrote in message
> news:op.s7e9emiywrbfww@akenatonv.www2.compassis.com...
>>
>> Another case to review would be to drag an email from Outlook. I did
>> not manage to make it work with current tkdnd.
>>
>> Ramon Ribó
>>
>> En Mon, 03 Apr 2006 00:00:55 +0200, Georgios Petasis
>> <petasis@iit.demokritos.gr> escribió:
>>
>>>
>>> <vince.darley@gmail.com> wrote in message
>>> news:1144007842.714153.138480@z34g2000cwc.googlegroups.com...
>>>> Georgios Petasis wrote:
>>>>> I expect to be many problems with such an approach:
>>>>>
>>>>> 1) The uses do not justify the efford put into it. We are talking
>>>>> about
>>>>> a very complex scheme, where the control of the transfer must be
>>>>> passed
>>>>> to the caller (outside of tkdnd). This is dangerous, as there are a
>>>>> lot
>>>>> of
>>>>> things
>>>>> that can go wrong.
>>>>>
>>>>> 2) When the transfer is over, you have to deliver an event to the
>>>>> drag source, to notify that you have finished getting the data, or
>>>>> that
>>>>> you are not interested any more in the drop. How is this to be
>>>>> handled?
>>>>> You must rely on the user to call a function? In 99% of the cases they
>>>>> won't.
>>>>
>>>> But isn't this roughly the model that MacOS X uses?: the source
>>>> _promises_ some data, and then the drop site has to request it. It is
>>>> only at that point that the source actually provides the data. Of
>>>> course things can go wrong, and that's what error conditions are for.
>>>> ("drop cancelled/failed/...", etc).
>>>>
>>>> To me, any API that forces all the data to be provided up front is not
>>>> appropriate for a general drag-n-drop mechanism.
>>>>
>>>> Certainly for many common cases it is easy to provide the data up front
>>>> (and that should be supported), but equally for many other common cases
>>>> it is quite hopeless to provide all the data up front.
>>>>
>>>> Vince.
>>>>
>>>
>>> What are these cases? The only one I know of is under windows, when
>>> dragging files from compressed folders (or from winzip). It would be
>>> interested
>>> to know more cases.
>>>
>>> George
>>>
>>>
>>
>>
>>
>> --
>> Compass Ing. y Sistemas Dr. Ramon Ribo
>> http://www.compassis.com ramsan@compassis.com
>> c/ Tuset, 8 7-2 tel. +34 93 218 19 89
>> 08006 Barcelona, Spain fax. +34 93 396 97 46
>
>
Received on Sun Apr 30 02:57:08 2006