Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Eclipse Projects » Standard Widget Toolkit (SWT) » OS X Drag&Drop to Finder / InDesign
OS X Drag&Drop to Finder / InDesign [message #451714] Mon, 07 March 2005 11:49 Go to next message
Wolfgang Werner is currently offline Wolfgang WernerFriend
Messages: 10
Registered: July 2009
Junior Member
For me under OS X there are two serious problems with the drag&drop
implementation that I do have to fix in a very short time frame. My
problem is that I do not have a long history in OS X native programming,
so any help is greatly appreciated.

I use the newest 3.1M5a milestone.

Task 1: The OS X DragSource implementation does query the data before
starting the drag and drop operation:

// Immediately get data for transfer. On other platforms, we wait
// until the data is requested, but on the mac, particularly in the case
of files,
// we need to know how many items are being transferred when registering.

// The only way to know this is to get the data.
int index = 0;
for (int i = 0; i < transferAgents.length; i++) {
int[] types = transferAgents[i].getTypeIds();
for (int j = 0; j < types.length; j++) {
TransferData transferData = new TransferData();
transferData.type = types[j];
event = new DNDEvent();
event.widget = this;
event.time = (int)System.currentTimeMillis();
event.dataType = transferData;
try {
notifyListeners(DND.DragSetData, event);
} catch (Throwable e) {
continue;
}
if (event.data == null) continue;
transferAgents[i].javaToNative(event.data, transferData);
if (transferData.result != OS.noErr || transferData.data == null)
continue;
for (int k = 0; k < transferData.data.length; k++) {
byte[] data = transferData.data[k];
OS.AddDragItemFlavor(theDrag[0], index++, types[j], data, data.length,
0);
}
}
}

My problem is, that I need to implement a drag and drop operation that
behaves differently in favor of the DropTarget: If it's an internal d&d, I
only need to call a function; if it's an external d&d, I need to export a
file - which takes some time - this overhead is only acceptable in the
case of the external d&d.

Would be great to get more insight - I would like to understand why this
has been implemented this way.

Task 2: In technical note TN1085 some issues with the Finder event
processing are described. The DragSource - Application is forced to do
some Finder Event Handling to make the d&d actually happen. Question: Waht
would be a good point to register / deregister the event handling routine?
Can this event handling be done in a central place (e.g. the main message
loop?) Is this event handling truely the cause of the problems - the TN is
very old and we are talking carbon here?

Task 3: On OS X there are two FileTransfers : HFS and PromiseHFS. The
second one enables an application to write a file on demand when asked and
provided with a filename by the DragTarget - Application. Is there any
chance that this filetransfer will be implemented?
Re: OS X Drag&Drop to Finder / InDesign [message #451734 is a reply to message #451714] Mon, 07 March 2005 18:22 Go to previous messageGo to next message
Veronika Irvine is currently offline Veronika IrvineFriend
Messages: 1272
Registered: July 2009
Senior Member
> My problem is, that I need to implement a drag and drop operation that
> behaves differently in favor of the DropTarget: If it's an internal d&d, I
> only need to call a function; if it's an external d&d, I need to export a
> file - which takes some time - this overhead is only acceptable in the
> case of the external d&d.

I will have another look at passing null for the dataPtr in
AddDragItemFlavor. Please enter a bug report to track this.

> Task 2: In technical note TN1085 some issues with the Finder event
> processing are described. The DragSource - Application is forced to do
> some Finder Event Handling to make the d&d actually happen. Question: Waht
> would be a good point to register / deregister the event handling routine?

I would hack SWT and use the event registration that already exists (see
Display - there are many Callback objects for the different kinds of event
procs - e.g. appleEventCallback) and enter a bug report with a patch.

> Task 3: On OS X there are two FileTransfers : HFS and PromiseHFS. The
> second one enables an application to write a file on demand when asked and
> provided with a filename by the DragTarget - Application. Is there any
> chance that this filetransfer will be implemented?

The PromiseHFSFlavor "is used when you wish to create a new file when
dragging to the Finder". The idea of creating a new file versus moving or
copying an existing file is not supported by the FileTransfer object. More
API would probably be required to make this differentiation. I will look
into seeing if the DROP_TARGET_MOVE versus DROP_MOVE operations could be
used to accomodate this. Since I have not been able to interact with the
Finder correctly, I have not been providing capabilities that I can not
test.


"Wolfgang Werner" <wwerner@picturesafe.de> wrote in message
news:d0hf3e$9ht$1@www.eclipse.org...
> For me under OS X there are two serious problems with the drag&drop
> implementation that I do have to fix in a very short time frame. My
> problem is that I do not have a long history in OS X native programming,
> so any help is greatly appreciated.
>
> I use the newest 3.1M5a milestone.
>
> Task 1: The OS X DragSource implementation does query the data before
> starting the drag and drop operation:
>
> // Immediately get data for transfer. On other platforms, we wait
> // until the data is requested, but on the mac, particularly in the case
> of files,
> // we need to know how many items are being transferred when registering.
> // The only way to know this is to get the data.
> int index = 0;
> for (int i = 0; i < transferAgents.length; i++) {
> int[] types = transferAgents[i].getTypeIds();
> for (int j = 0; j < types.length; j++) {
> TransferData transferData = new TransferData();
> transferData.type = types[j];
> event = new DNDEvent();
> event.widget = this;
> event.time = (int)System.currentTimeMillis(); event.dataType =
> transferData; try {
> notifyListeners(DND.DragSetData, event);
> } catch (Throwable e) {
> continue;
> }
> if (event.data == null) continue;
> transferAgents[i].javaToNative(event.data, transferData);
> if (transferData.result != OS.noErr || transferData.data == null)
> continue; for (int k = 0; k < transferData.data.length; k++) {
> byte[] data = transferData.data[k];
> OS.AddDragItemFlavor(theDrag[0], index++, types[j], data, data.length,
> 0); } } }
>
> My problem is, that I need to implement a drag and drop operation that
> behaves differently in favor of the DropTarget: If it's an internal d&d, I
> only need to call a function; if it's an external d&d, I need to export a
> file - which takes some time - this overhead is only acceptable in the
> case of the external d&d.
>
> Would be great to get more insight - I would like to understand why this
> has been implemented this way.
>
> Task 2: In technical note TN1085 some issues with the Finder event
> processing are described. The DragSource - Application is forced to do
> some Finder Event Handling to make the d&d actually happen. Question: Waht
> would be a good point to register / deregister the event handling routine?
> Can this event handling be done in a central place (e.g. the main message
> loop?) Is this event handling truely the cause of the problems - the TN is
> very old and we are talking carbon here?
>
> Task 3: On OS X there are two FileTransfers : HFS and PromiseHFS. The
> second one enables an application to write a file on demand when asked and
> provided with a filename by the DragTarget - Application. Is there any
> chance that this filetransfer will be implemented?
Re: OS X Drag&Drop to Finder / InDesign [message #451771 is a reply to message #451734] Tue, 08 March 2005 20:17 Go to previous messageGo to next message
Veronika Irvine is currently offline Veronika IrvineFriend
Messages: 1272
Registered: July 2009
Senior Member
I have changed DND on the Mac so that dragGetData is only called when the
specific data type is requested. No longer does it get all the data up
front. This will be in next week's integration build or tonight's nightly
build.

"Veronika Irvine" <veronika_irvine@oti.com> wrote in message
news:d0i64r$b8k$1@www.eclipse.org...
>> My problem is, that I need to implement a drag and drop operation that
>> behaves differently in favor of the DropTarget: If it's an internal d&d,
>> I only need to call a function; if it's an external d&d, I need to export
>> a file - which takes some time - this overhead is only acceptable in the
>> case of the external d&d.
>
> I will have another look at passing null for the dataPtr in
> AddDragItemFlavor. Please enter a bug report to track this.
>
>> Task 2: In technical note TN1085 some issues with the Finder event
>> processing are described. The DragSource - Application is forced to do
>> some Finder Event Handling to make the d&d actually happen. Question:
>> Waht would be a good point to register / deregister the event handling
>> routine?
>
> I would hack SWT and use the event registration that already exists (see
> Display - there are many Callback objects for the different kinds of event
> procs - e.g. appleEventCallback) and enter a bug report with a patch.
>
>> Task 3: On OS X there are two FileTransfers : HFS and PromiseHFS. The
>> second one enables an application to write a file on demand when asked
>> and provided with a filename by the DragTarget - Application. Is there
>> any chance that this filetransfer will be implemented?
>
> The PromiseHFSFlavor "is used when you wish to create a new file when
> dragging to the Finder". The idea of creating a new file versus moving or
> copying an existing file is not supported by the FileTransfer object.
> More API would probably be required to make this differentiation. I will
> look into seeing if the DROP_TARGET_MOVE versus DROP_MOVE operations could
> be used to accomodate this. Since I have not been able to interact with
> the Finder correctly, I have not been providing capabilities that I can
> not test.
>
>
> "Wolfgang Werner" <wwerner@picturesafe.de> wrote in message
> news:d0hf3e$9ht$1@www.eclipse.org...
>> For me under OS X there are two serious problems with the drag&drop
>> implementation that I do have to fix in a very short time frame. My
>> problem is that I do not have a long history in OS X native programming,
>> so any help is greatly appreciated.
>>
>> I use the newest 3.1M5a milestone.
>>
>> Task 1: The OS X DragSource implementation does query the data before
>> starting the drag and drop operation:
>>
>> // Immediately get data for transfer. On other platforms, we wait
>> // until the data is requested, but on the mac, particularly in the case
>> of files,
>> // we need to know how many items are being transferred when registering.
>> // The only way to know this is to get the data.
>> int index = 0;
>> for (int i = 0; i < transferAgents.length; i++) {
>> int[] types = transferAgents[i].getTypeIds();
>> for (int j = 0; j < types.length; j++) {
>> TransferData transferData = new TransferData();
>> transferData.type = types[j];
>> event = new DNDEvent();
>> event.widget = this;
>> event.time = (int)System.currentTimeMillis(); event.dataType =
>> transferData; try {
>> notifyListeners(DND.DragSetData, event);
>> } catch (Throwable e) {
>> continue;
>> }
>> if (event.data == null) continue;
>> transferAgents[i].javaToNative(event.data, transferData);
>> if (transferData.result != OS.noErr || transferData.data == null)
>> continue; for (int k = 0; k < transferData.data.length; k++) {
>> byte[] data = transferData.data[k];
>> OS.AddDragItemFlavor(theDrag[0], index++, types[j], data, data.length,
>> 0); } } }
>>
>> My problem is, that I need to implement a drag and drop operation that
>> behaves differently in favor of the DropTarget: If it's an internal d&d,
>> I only need to call a function; if it's an external d&d, I need to export
>> a file - which takes some time - this overhead is only acceptable in the
>> case of the external d&d.
>>
>> Would be great to get more insight - I would like to understand why this
>> has been implemented this way.
>>
>> Task 2: In technical note TN1085 some issues with the Finder event
>> processing are described. The DragSource - Application is forced to do
>> some Finder Event Handling to make the d&d actually happen. Question:
>> Waht would be a good point to register / deregister the event handling
>> routine? Can this event handling be done in a central place (e.g. the
>> main message loop?) Is this event handling truely the cause of the
>> problems - the TN is very old and we are talking carbon here?
>>
>> Task 3: On OS X there are two FileTransfers : HFS and PromiseHFS. The
>> second one enables an application to write a file on demand when asked
>> and provided with a filename by the DragTarget - Application. Is there
>> any chance that this filetransfer will be implemented?
>
>
Re: OS X Drag&Drop to Finder / InDesign [message #451815 is a reply to message #451771] Wed, 09 March 2005 15:02 Go to previous messageGo to next message
Wolfgang Werner is currently offline Wolfgang WernerFriend
Messages: 10
Registered: July 2009
Junior Member
Veronika, this helped us a lot! I just grapped your changes from cvs
(jndi-libs, OS.java,
Plattform.java, DragSource.java and gave it a try - works great, we now
have a great
responsiv UI in this area. I will now try to create the patch for the
Apple Events from
TN1085 starting in Display.java. Thanks!!
Veronika Irvine wrote:

> I have changed DND on the Mac so that dragGetData is only called when the
> specific data type is requested. No longer does it get all the data up
> front. This will be in next week's integration build or tonight's nightly
> build.

> "Veronika Irvine" <veronika_irvine@oti.com> wrote in message
> news:d0i64r$b8k$1@www.eclipse.org...
>>> My problem is, that I need to implement a drag and drop operation that
>>> behaves differently in favor of the DropTarget: If it's an internal d&d,
>>> I only need to call a function; if it's an external d&d, I need to export
>>> a file - which takes some time - this overhead is only acceptable in the
>>> case of the external d&d.
>>
>> I will have another look at passing null for the dataPtr in
>> AddDragItemFlavor. Please enter a bug report to track this.
>>
>>> Task 2: In technical note TN1085 some issues with the Finder event
>>> processing are described. The DragSource - Application is forced to do
>>> some Finder Event Handling to make the d&d actually happen. Question:
>>> Waht would be a good point to register / deregister the event handling
>>> routine?
>>
>> I would hack SWT and use the event registration that already exists (see
>> Display - there are many Callback objects for the different kinds of event
>> procs - e.g. appleEventCallback) and enter a bug report with a patch.
>>
>>> Task 3: On OS X there are two FileTransfers : HFS and PromiseHFS. The
>>> second one enables an application to write a file on demand when asked
>>> and provided with a filename by the DragTarget - Application. Is there
>>> any chance that this filetransfer will be implemented?
>>
>> The PromiseHFSFlavor "is used when you wish to create a new file when
>> dragging to the Finder". The idea of creating a new file versus moving or
>> copying an existing file is not supported by the FileTransfer object.
>> More API would probably be required to make this differentiation. I will
>> look into seeing if the DROP_TARGET_MOVE versus DROP_MOVE operations could
>> be used to accomodate this. Since I have not been able to interact with
>> the Finder correctly, I have not been providing capabilities that I can
>> not test.
>>
>>
>> "Wolfgang Werner" <wwerner@picturesafe.de> wrote in message
>> news:d0hf3e$9ht$1@www.eclipse.org...
>>> For me under OS X there are two serious problems with the drag&drop
>>> implementation that I do have to fix in a very short time frame. My
>>> problem is that I do not have a long history in OS X native programming,
>>> so any help is greatly appreciated.
>>>
>>> I use the newest 3.1M5a milestone.
>>>
>>> Task 1: The OS X DragSource implementation does query the data before
>>> starting the drag and drop operation:
>>>
>>> // Immediately get data for transfer. On other platforms, we wait
>>> // until the data is requested, but on the mac, particularly in the case
>>> of files,
>>> // we need to know how many items are being transferred when registering.
>>> // The only way to know this is to get the data.
>>> int index = 0;
>>> for (int i = 0; i < transferAgents.length; i++) {
>>> int[] types = transferAgents[i].getTypeIds();
>>> for (int j = 0; j < types.length; j++) {
>>> TransferData transferData = new TransferData();
>>> transferData.type = types[j];
>>> event = new DNDEvent();
>>> event.widget = this;
>>> event.time = (int)System.currentTimeMillis(); event.dataType =
>>> transferData; try {
>>> notifyListeners(DND.DragSetData, event);
>>> } catch (Throwable e) {
>>> continue;
>>> }
>>> if (event.data == null) continue;
>>> transferAgents[i].javaToNative(event.data, transferData);
>>> if (transferData.result != OS.noErr || transferData.data == null)
>>> continue; for (int k = 0; k < transferData.data.length; k++) {
>>> byte[] data = transferData.data[k];
>>> OS.AddDragItemFlavor(theDrag[0], index++, types[j], data, data.length,
>>> 0); } } }
>>>
>>> My problem is, that I need to implement a drag and drop operation that
>>> behaves differently in favor of the DropTarget: If it's an internal d&d,
>>> I only need to call a function; if it's an external d&d, I need to export
>>> a file - which takes some time - this overhead is only acceptable in the
>>> case of the external d&d.
>>>
>>> Would be great to get more insight - I would like to understand why this
>>> has been implemented this way.
>>>
>>> Task 2: In technical note TN1085 some issues with the Finder event
>>> processing are described. The DragSource - Application is forced to do
>>> some Finder Event Handling to make the d&d actually happen. Question:
>>> Waht would be a good point to register / deregister the event handling
>>> routine? Can this event handling be done in a central place (e.g. the
>>> main message loop?) Is this event handling truely the cause of the
>>> problems - the TN is very old and we are talking carbon here?
>>>
>>> Task 3: On OS X there are two FileTransfers : HFS and PromiseHFS. The
>>> second one enables an application to write a file on demand when asked
>>> and provided with a filename by the DragTarget - Application. Is there
>>> any chance that this filetransfer will be implemented?
>>
>>
Re: OS X Drag&Drop to Finder / InDesign [message #451932 is a reply to message #451815] Fri, 11 March 2005 12:06 Go to previous messageGo to next message
Wolfgang Werner is currently offline Wolfgang WernerFriend
Messages: 10
Registered: July 2009
Junior Member
Hi,

>> Task 2: In technical note TN1085 some issues with the Finder event
>> processing are described. The DragSource - Application is forced to do
>> some Finder Event Handling to make the d&d actually happen. Question:
>> What would be a good point to register / deregister the event handling
>> routine?
>
> I would hack SWT and use the event registration that already exists (see
> Display - there are many Callback objects for the different kinds of event
> procs - e.g. appleEventCallback) and enter a bug report with a patch.

I tried to do this - to keep it simple I started to change my main program
adding
a handler. Handler creation and registration works fine when using already
defined masks, however, when testing different values (guided by apple doc
and
N1085) the handler is not called at all.

[...]
Callback bogusFinderCallback;
int bogusFinderProc;

int bogusFinderProc (int nextHandler, int theEvent, int userData) {
log.info("inside Mac OS X bogus finder callback!");
return OS.noErr;
}

private void installBogusHandler() {
if (OS_IS_MACOS) {
log.info("Enable Mac OS X bogus finder callback... ");
bogusFinderCallback = new Callback(this, "bogusFinderProc", 3);
bogusFinderProc = bogusFinderCallback.getAddress();
if (bogusFinderProc == 0) {
log.error("ERROR - cannot enable Mac OS X bogus finder
callback!");
return;
}

final int kEventClassCWIN = ('c'<<24) + ('w'<<16) + ('i'<<8) +
'n';
final int kEventKindCWIN = 1; // ('*'<<24) + ('*'<<16) + ('*'<<8)
+ '*';
int [] mask = new int[] {
kEventClassCWIN, kEventKindCWIN,
};

int appTarget = OS.GetApplicationEventTarget ();
int result = OS.InstallEventHandler (appTarget, bogusFinderProc,
mask.length / 2, mask, 0, null);

if( result != OS.noErr ) {
log.error("ERROR - cannot install Mac OS X bogus finder event
handler! " + result);
}
}
}

Any idea how to set the mask values properly?
Re: OS X Drag&Drop to Finder / InDesign [message #451985 is a reply to message #451932] Fri, 11 March 2005 22:06 Go to previous messageGo to next message
Veronika Irvine is currently offline Veronika IrvineFriend
Messages: 1272
Registered: July 2009
Senior Member
I gave this a few tries and have yet to achieve success. However, despite
the fact that I can't get my event handler to be called, I was able to drag
things from eclipse and into the Finder and vice versa. I found that the
Finder was a bit sluggish in response to key modifier changes (copy or link
rather than move) but I was able to copy, move and link files from Eclipse
into the Finder. Not sure if this is due to a fix to the Finder with one of
the latest OS X upgrades.

"Wolfgang Werner" <wwerner@picturesafe.de> wrote in message
news:d0s1jr$khc$1@www.eclipse.org...
> Hi,
>
>>> Task 2: In technical note TN1085 some issues with the Finder event
>>> processing are described. The DragSource - Application is forced to do
>>> some Finder Event Handling to make the d&d actually happen. Question:
>>> What would be a good point to register / deregister the event handling
>>> routine?
>>
>> I would hack SWT and use the event registration that already exists (see
>> Display - there are many Callback objects for the different kinds of
>> event procs - e.g. appleEventCallback) and enter a bug report with a
>> patch.
>
> I tried to do this - to keep it simple I started to change my main program
> adding
> a handler. Handler creation and registration works fine when using already
> defined masks, however, when testing different values (guided by apple doc
> and N1085) the handler is not called at all.
>
> [...]
> Callback bogusFinderCallback;
> int bogusFinderProc;
>
> int bogusFinderProc (int nextHandler, int theEvent, int userData) {
> log.info("inside Mac OS X bogus finder callback!");
> return OS.noErr;
> }
>
> private void installBogusHandler() {
> if (OS_IS_MACOS) {
> log.info("Enable Mac OS X bogus finder callback... ");
> bogusFinderCallback = new Callback(this, "bogusFinderProc", 3);
> bogusFinderProc = bogusFinderCallback.getAddress();
> if (bogusFinderProc == 0) {
> log.error("ERROR - cannot enable Mac OS X bogus finder
> callback!");
> return;
> }
>
> final int kEventClassCWIN = ('c'<<24) + ('w'<<16) + ('i'<<8) +
> 'n';
> final int kEventKindCWIN = 1; // ('*'<<24) + ('*'<<16) + ('*'<<8)
> + '*';
> int [] mask = new int[] {
> kEventClassCWIN, kEventKindCWIN,
> };
>
> int appTarget = OS.GetApplicationEventTarget ();
> int result = OS.InstallEventHandler (appTarget, bogusFinderProc,
> mask.length / 2, mask, 0, null);
>
> if( result != OS.noErr ) {
> log.error("ERROR - cannot install Mac OS X bogus finder event
> handler! " + result);
> }
> }
> }
>
> Any idea how to set the mask values properly?
>
>
Re: OS X Drag&Drop to Finder / InDesign [message #453008 is a reply to message #451985] Tue, 29 March 2005 18:56 Go to previous message
Wolfgang Werner is currently offline Wolfgang WernerFriend
Messages: 10
Registered: July 2009
Junior Member
Have you been able to get the handler called at all?
I'm still struggeling around with parameters for masks etc. but my
handler isn't called as well.
D&D to InDesign now has become the number one blocker for our app.
Any help / further suggestions are greatly appreciated!
Previous Topic:how to get ImageDesc riptor for Images
Next Topic:using AbstractTextEditor in an SWT Application
Goto Forum:
  


Current Time: Tue Oct 22 08:34:36 GMT 2019

Powered by FUDForum. Page generated in 0.02751 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top