First - thanks to many for the discussions surrounding this idea. Based on
feedback, it sounds like there is sufficient interest here to pursue it a
bit further. I think the OVERRIDING consideration is to keep it simple.
There have been many excellent schemes proposed in the past, but they are
just too complex for the average developer to choose to implement them. If
it's truly simple, even if it fails to meet everyone's requirements, we'll
still be better off than where we are now.
I'm rather inclined to agree at this point that it would be better to just
allocate a fixed block of say 64 bytes for the link as that should be
sufficient for most users. And if MORE information were needed, an app could
always stuff a handle into that block that pointed to a block saved in
persistent storage and manage that when the link is expanded at a later
time.
I have also been thinking about trying to make it easier for the end-user as
well.
Note that the mechanism as I first proposed it is a bit 'fidgety':
I am working in application A, have a record selected and say - gee I'd like
to link to a record in APP B
1. Switch to App B
2. Find the record
3. Publish the link
4. Switch back to App A
5. retrieve the link
So I think reducing the number of steps is important. I like the idea that
when I return to App A I do as little as possible. I also like the idea of a
scheme with no dangling stuff (64 bytes is not much to worry about, but it
could well expand in a future implementation) - i.e. so if features are
used, they are also automatically released as well.
So, after a bit of thought, I've come up with a simpler way of doing this:
User in APP A wants to link a record in some other app to the
currently selected record.
1. App A brings up a picklist dialog of all applications that support
linking
2. APP A launches selected APP B after setting a feature F1 with APP A's
CreatorID and the selected Record #
3. APP B now allows the user to select a record and invoke the LINK AND
RETURN function
Everything now is automatic. APP B stores its creatorID and uniqueID plus
optional info in Feature F2 and then "returns" to APP A using the global
find feature with the record # previously saved in feature F1.
APP A in the global find realizes that its job is to set a link and then
goes ahead and sets it. Note that if someone selects this function and
issues the publish without the first part of this sequence, APP B could
either ignore the function, or post an Alert.
One advantage of this scheme is there is no clean up problem. The feature F1
is created, APP B is launched, the information extracted, and the feature
released in one non-interruptible sequence. On the way back, the feature F2
is created, APP A is launched with the Find, and APP A releases the feature
after saving the information, again in one non-interruptible sequence.
APP A could also invoke this function without having a record selected (i.e.
user might want to browse the links and THEN choose which record to link to
in APP A). If this happens, when APP B "returns" to APP A with the global
find, APP A sees a record number of 0xFFFF. At that point, it could save the
link information locally, let the user select a record, and then wait for
the user to invoke the link explicitly with a command.
The picklist of apps could run through each app and send it a special custom
launch code which a "linking-aware app" responds to by setting a feature
that is then used to figure out that it should be included in the dialog. If
this is a bit slow, the list could be remembered, and a button in that
dialog could invoke a refresh of the contents of that dialog.
If I do implement this scheme, I would of course post all the source code
associated with it hopefully in such a way that it would make it as painless
as possible for other developers to include the code in their applications.
____ ____
/ ___) / ___)
( (___ ( (___
\____)heers! \____)ESD
Pimlico Software, Inc.
Home of DateBk3 and WeekView: www.gorilla-haven.org/pimlico
The Dewar Wildlife Trust, Inc.
Home of Gorilla Haven: www.gorilla-haven.org
. . . . . .
