Script Triggers and Drag Drop incompatible???

[Christensen Design]

I hope I'm wrong about this and that someone has a solution that I haven't found...

As far as I can tell, it's not possible to get a script trigger on an enterable field to execute when text is dragged into the field. Is that correct?

If so, this means that to use 'OnObject' script triggers, developers will more than likely have to turn off Drag and Drop (under Preferences). Otherwise, a user can always circumvent an 'OnObject' script trigger by dragging text into the field. On validate calculations do still execute.

The only way I can see around this is to either turn off drag drop altogether in Preferences or to use a plugin like DoScript.

BTW.. even the plugin has problems when dragging/dropping across records in List View. The script does execute on drop but it executes for the currently selected record which is not necessarily the record the user dragged to. not good...

John

Edited July 31, 2009 by Guest

[bruceR]

I hope I'm wrong about this

You are wrong.

http://excelisys.com/web/downloads/index.php

[Christensen Design]

Uh.. I don't understand how the excelisys link shows that I am wrong. That simple demo does not work on enterable fields at all. Their 'trick' (which is really just another FM kludge) fails when the fields are enterable. The FM triggers do not trigger.

Also.. their simple demo does not involve dragging from one record to another in a list which appears to fail in all conditions (even when using an plugin).

Bottom line is that FM's trigger feature seems to be incompatible with its own drag and drop functionality. Few developers apparently know this.

I think you should at least test out the issue yourself before responding.

Edited August 4, 2009 by Guest

[bruceR]

Then let me try to explain.

The Excelysis example illustrates how the FileMaker onEnter function actually works. It is triggered when you click into the drag source; and the trigger actually fires on mouseup.

The example provides you with the information you need to do what you are trying to do. You can choose to adapt and accomplish your goal if that is the more important outcome.

[Raybaudi]

...dragging from one record to another in a list which appears to fail in all conditions...

A simple validation will not fail dragging BETWEEN records:

IsEmpty ( Get ( ActiveSelectionSize ) )

but fails dragging from a field of the same record.

Interesting: putting that calc into the validation of ONLY one field protects ALL the fields of a record.

[Christensen Design]

Bruce..

I don't think you are understanding the issue here. The key is 'enterable' fields. As I said in the previous post, the excelisys demo does not use enterable fields. Their example is a simple drag and drop of items from one list to another. That is not what I am talking about.

I need to be able to have a script trigger (i.e. not a validation calculation) when a user drags a word into an enterable field. Open the excelisys demo and you will see that you can not drag the word 'Amy' into the word 'George' and get 'GeoAmyrge'. This is because the fields are not entereable. If you make the fields enterable, the script trigger will NOT execute and the demo breaks. THAT is the problem.

FM's script triggers do not support drag and drop which means that on any layout that has a script trigger, you must make sure that the trigger fields are not enterable. Otherwise, users will be able to change field values and circumvent the OnObjectEnter script (or any other script trigger that might be set).

Try it for yourself.

[Christensen Design]

A simple validation will not fail dragging BETWEEN records:

IsEmpty ( Get ( ActiveSelectionSize ) )

but fails dragging from a field of the same record.

I'm not following your example here. But it may be moot because what I need can not be done with a validation calculation.

The only place where a validation calculation could prove helpful also turns out to fail. Specifically, I have tried using the Butler DoScript plugin which allows a FM Script to be triggered through a validation calculation. This works fine on a layout that displays a single record at a time. But.. when you have a listing layout with entereable fields and the user drags some text from a field in one record to a 'doScript' field (i.e. a trigger field) of a different record, FM will execute the specified script but not for the correct record. In other words, FM does not correctly switch to the 'drop' record before running the script. The script runs for the current record which in this case will be the record the user dragged from, not the modified record. And, unfortunately, there is no way to get the record number or ID of the record the user dragged to. So you can't have the trigger script switch records manually and run the update the correct record because you don't know what record that is.

This problem gets worse if you add some enterable global fields to the top of the listing layout. If the user drags some text from an enterable global field to a 'doScript' field of a record somewhere in the list, the script will trigger, but again, not for record dragged to. FM runs the script for the current record which could be any record in the list, not the record dragged to. This obviously can have dire consequences depending upon what the script does.

Now please understand that I'm not blaming FM for the limitations of the 'doScript'-like plugins. That's not FM's fault directly. But.. the fact that new triggers feature of v10 is not compatible with drag-n-drop is a FM issue and not a trivial one.

Edited August 11, 2009 by Guest

[bruceR]

Bruce..

I don't think you are understanding the issue here. The key is 'enterable' fields. As I said in the previous post, the excelisys demo does not use enterable fields. Their example is a simple drag and drop of items from one list to another. That is not what I am talking about.

I need to be able to have a script trigger (i.e. not a validation calculation) when a user drags a word into an enterable field. Open the excelisys demo and you will see that you can not drag the word 'Amy' into the word 'George' and get 'GeoAmyrge'. This is because the fields are not entereable. If you make the fields enterable, the script trigger will NOT execute and the demo breaks. THAT is the problem.

FM's script triggers do not support drag and drop which means that on any layout that has a script trigger, you must make sure that the trigger fields are not enterable. Otherwise, users will be able to change field values and circumvent the OnObjectEnter script (or any other script trigger that might be set).

Try it for yourself.

Your clarification is helpful but nevertheless, what I said before applies. You can do what you want. The Excelysis demo shows you that it is mouseup from the source field that controls the trigger. Everything else is just scripting detai and if you want a script that does something else then write it that way.

[comment]

It is triggered when you click into the drag source; and the trigger actually fires on mouseup.

That's the entire point here: in the Excelysis demo, the trigger is attached to the SOURCE field. In fact, the script has no way of determining what the target is - this information comes from an auto-entered calculation in the target field. As far as the script is concerned, the current record is still the source record, and the active field is the source field.

Now, this can be useful in situations where you know in advance all possible source/s for dragging, and attach script triggers to all of them.

However, I don't see how a script could be triggered upon dropping ANYTHING (or rather FROM ANYWHERE) into the target field - which I believe is the OP's wish.

[RodSierra]

I agree there are some inconsistencies with regards to dropping text in a field that has triggers set. I use drop boxes to allow users to drop text from other apps into a field. Filemaker allows the text to be dropped, but does not trigger on any script options. The field has in fact changed, thus the trigger on modify should activate, but does not, even when the field is entered. If you set the trigger to on entry and drag text in, it requires one click on the field to bring FM to the active app then another to enter the field which triggers the script. I would think that the act of dropping text into a field even though FM is not the focused app should trigger the on field modified option, as the field has accepted new data and has in fact changed.

[comment]

It seems that dropping contents into a field is not considered a layout event - same as setting a field by script.

[Christensen Design]

Your clarification is helpful but nevertheless, what I said before applies. You can do what you want.

All right Bruce.. show us how!

Here's the setup: simple.. three enterable text fields, one trigger script, one layout (set to view as list or as table). When the user drags selected text from within Field1 and drops it somewhere into the text in Field2, a FM script needs to run which places a field value (presumably via the Set Field command) into Field3 of the dropped record. So.. if the user drags from Rec5 to Rec12, the script needs to set the contents of Field3 for Rec12. And remember... all three fields on the layout must be enterable (i.e not calculated fields).

That's it. Go for it.

Edited August 13, 2009 by Guest

[Christensen Design]

It seems that dropping contents into a field is not considered a layout event - same as setting a field by script.

Apparently so. And yet obviously a drag/drop event is a layout event, it's just that FM does not yet support it for script triggers.

What I think they need to do here is one of four things:

1) Extend the functionality of OnObjectModify to support drag/drop. This trigger would presumably have to automatically move the current record to the dropped record if the user dragged between records or windows. FM would then have to decide (or give the developer an option) whether other triggers such as OnObjectSave or OnRecordLoad would run. This could be messy and may be why they have not supported drag/drop yet.

2) Add new OnObjectDrag and/or OnObjectDrop script triggers for any object on a layout. Drag is not totally necessary but would be nice for storing initial values or highlighting 'droppable' fields. Drop would be the really useful one. OnObjectDrop would presumably have move the current record to the dropped record as described above).

or

3) Add an OnLayoutDrop script trigger for any layout and then provide a 'Get()' function that allows the developer to get a reference to the field/record/table/layout that the user dragged from and to. This is similar to what many other database dev apps have.

or

4) Leave everything the same but add some drag/drop-specific Get() commands. For example:

Get ( DragObject ) -> returns the field/record/table/layout of the field dragged from

Get ( DropObject ) -> returns the field/record/table/layout of the field dropped to

Get ( DragContents ) -> returns the text/picture dragged

Get ( DropContentsOld ) -> returns the text/picture in the drop field before it was changed (very useful)

Without adding any new script triggers, these drag/drop Get() commands would have limited use. But.. by using the DoScript plugin (which executes a FM script via a validation calculation), developers could use them and begin to fully support drag and drop in FM.

[comment]

When the user drags selected text from within Field1 and drops it somewhere into the text in Field2, a FM script needs to run which places a field value (presumably via the Set Field command) into Field3 of the dropped record.

Actually, this CAN be done using the Excelysis method - since we know the source field in advance.

And yet obviously a drag/drop event is a layout event

Not trying to justify it, but it's worth noticing that the target field is not activated at any time during the drop. Even the current record doesn't change when you drop into another record. So from this perspective it's much closer to a Set Field[] than to a user action (that requires activating a field in order to modify it).

[Christensen Design]

Actually, this CAN be done using the Excelysis method - since we know the source field in advance.

I disagree. First of all, you don't know the source field in a real solution because there will be many fields on the layout -- all of which can be a source field. My example of three fields is a simplification.

Secondly... even if you did know the source field dragged from, you do not know the RECORD dragged-to!! That is the big issue. Furthermore, FM will not execute a script at all on the drop (even if you drop it on the same record) because the fields are enterable and FM does not trigger on that event. That is where the excelisys demo will fail also.

Just try it. Open their demo, make the drop field enterable and watch it fail.

Edited August 14, 2009 by Guest

[comment]

I disagree. First of all, you don't know the source field in a real solution

Well, I was referring to YOUR example - where you explicitly specified the source field. I already said it cannot be done if the source is unknown - so I don't see what's there to disagree.

Secondly... even if you did know the source field dragged from, you do not know the RECORD dragged-to!!

Yes, I do - but not from the script. I already mentioned this point, too:

the script has no way of determining what the target is - this information comes from an auto-entered calculation in the target field.

I don't think you fully understand the method used in the Excelisys demo. It has very little to do with SOME fields being non-enterable - that's just cosmetics. The actual field accepting the drop is and must be enterable - otherwise it wouldn't work at all.

[Ward]

And yet obviously a drag/drop event is a layout event, it's just that FM does not yet support it for script triggers.

My experience agrees with CD. I found this thread while searching for help with a non-firing trigger script.

I added a script trigger to a URL field in my production database. The way this field it typically used is to drag a URL from a Mac OS X browser, and drop the URL into the field. When I added the trigger script, I found the script isn't performed when a URL is dropped. On the other hand, copying the URL and pasting it into the field triggers the script.

I disagree with the contention that drag-n-drop is akin to a field being modified by a script.

While writing this, I took a detour to the FileMaker "Report a Bug" forum and opened a new thread: ]Invoke a script trigger on drag-n-drop.

[comment]

I disagree with the contention that drag-n-drop is akin to a field being modified by a script.

This "contention" describes the facts. I don't think anyone on this thread said they were happy with it.