BUG: drag-drop portal-created records? poof!

[ESpringer]

Earlier I thought I had a corrupt file. But the recipe for losing recently-created related records has nothing to do with my particular file:

(1) Create two tables related via a key. The first "main" table needs only the key. Second "Details" table has a Details text field, and also the key. Draw Relational link between Key fields, and edit relation to allow creation of related records in Details table.

(2) Make a portal on main layout to the related records, and put the Details field there.

(3) Go into browse mode, generate a record in the main table with any ID#.

(4) Now drag and drop text from another application onto the Details field in the portal. It *seems* dragged data is accepted and new related records are being created, and FM7 keeps opening up another blank portal row for data entry. Notice that you can switch to the Details layout and see what look like the records just created.

(5) Close the database.

(6) Open it again. All related records have vanished. Poof!

Can any of you confirm this?

[Deep Thought II]

no... it doesn't happen to me.

[ESpringer]

Aha, so I suspect it may be OS-specific? Any Mac-Users willing to try it? It strikes me that FM7 may have trouble committing the related records if FM7 is not the front-most application at the time the records are created...

[andygaunt]

Hi -

Just tested on Mac. You are correct in that it does lose things.

However, if you commit the records then the information stays.

I just tested with a closing script that loops through the records on the main layout with the portal and commits the records.

Once reopened the information stayed. So you may wnat to look at some way of running a commit records command on your record once the information has chnaged. You could use one of the new event plugins that are free (http://www.softs4humans.com/FMPro_Plugins.html) to run a script once you leave that field.

[ESpringer]

Thanks for checking it out, Andy...

I do realize that there are work-arounds at least sometimes. However, it's certainly a bug, insofar as one can browse through all these distinct records for minutes on end, and even *change data*, and the newly created records are never committed except by script. (I guess I always imagined that only one record at a time would remain uncommitted, though I don't know why I assumed that!). I should also confirm that the disappearance is not absolutely consistent: sometimes half a batch *has* gotten committed! So I wonder what the trigger is!

Also (I haven't yet isolated when it happens exactly), many times if I try to edit those new records directly in their table, FM7 complains that the records are already being accessed via another layout (or table? I don't remember what the alert claimed). When this happens, nothing I do can salvage the records, because as soon as I close the relevant other windows, these records disappear. When that happens, I believe the commit script doesn't complain, but also doesn't work.

I'll follow through more later once I have a chance. (At any rate, much of the advantage of creating related records via portal using drag-and-drop is negated if one has to track which records were created and run a script afterwards. I believe FM6 used to handle these things fine.)

[ESpringer]

I'm suspecting that even the event-trigger plug-ins would not be able to seize the opportunity while another app is frontmost, dropping data into empty portal rows to create records... after all, there's no tabbing or clicking out of any field. Does anyone have a different impression?

[Ugo DI LUCA]

Hi,

Here's on that seems to work without a plug in.

You can either :

- enter some text : just exit the field with a tab after the entry

- drag some text : drag, drop, select the field and tab out

HTH

DragDrop.zip

[Ugo DI LUCA]

One side-note.

If you select the field above the portal, then goes to the external file and drag/drop back into your FileMaker file, as the field was selected, just exiting the field will "trigger" the portal update.

[ESpringer]

Thanks, Ugo.

Still, having to bring FM forward and mouse/key around is exactly what one did not have to do in FM6. One could hang out in a text editor app and keep drag-dropping text-bits onto blank portal rows *in a background window* and the new records would all just *work* (without having to click to bring FM to the front, click on the field, and hit tab to make each drop "stick"). Apparently FM7 for Windows *does* behave correctly here? The beauty of system-wide drag-and-drop was not having to switch apps with each deposit of text into FM's visible window's records/rows; switching apps and poking around after each drag is... well, *more* than a drag!

Perhaps I'm the only one with a situation in which the ability to run whole sequence of drag-drops (from outside FM) to create related records is an important feature... Hm.

[Ugo DI LUCA]

I never tried it back since this post, and now that I'm in need, it seems to work fine.

Was it alreasy solved by the latest patch for 7 ?