"C. E. Steuart Dewar" wrote:
> 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
On the other hand, suppose I'm working in app B (e.g. a drawing program), and
say - gee I'd like to attach this to a record in app A (e.g. an appointment in
datebk3). In this case, the old way would be better, and the new way becomes
'fidgety':
1. Switch to app A
2. Find the record
3. Choose 'create link' command
4. Switch to app B
5. Find the record
I'm not sure which direction the 'average user' would usually take; I'm not
even sure which way I would usually go. I've got an idea that could be the
best of both worlds; I'll explain in detail at the end of this message.
>
> 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 #
CreatorID and record index is not enough; App A might also have multiple
databases. I would suggest that another 64-byte chunk be used here.
>
> 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.
Using the global find feature here is not a good idea; how would the app
distinguish between this and a normal find request? I recommend a custom
launch code which would pass the data structure mentioned above. In fact, if
the new way is the only way links are made, features could be avoided
altogether, as everything could be passed with launch codes.
>
> 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.
It is interruptible, unless you want app B to disable the hardware buttons and
other means of switching applications (a very bad idea IMO).
>
> 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.
>
I don't have any data to back me up on this, but my gut feeling is that
broadcasting a launch code in this way would be unacceptably slow. Apps are
just resource databases; why not just have all linking-aware apps contain a
special resource? I know the gnu tools can add arbitrary resources to a .prc
file; can CW?
Here is my complete proposal:
Each linking-aware app would define a LinkType structure (of up to 64 bytes;
the first 4 bytes must be the CreatorID). For most apps, it would be
struct LinkType {
ULong CreatorID;
ULong RecordID;
Char DBname[32];
}
We could provide a function that would fill in such a structure from a
DmOpenRef and an index, to make this easier for authors.
All link targets (apps that can publish links) would provide a "Publish link"
command to the user. When this command is selected, the app would create a
LinkType structure, then call the PublishLink function.
void PublishLink(LinkPtr linkdata);
This function could be either pasted into the app's code or put in a shared
library (I've never used shared libraries on PalmOS, so I don't know how
hard/practical this would be)
This function would copy the link data into a 64-byte disowned handle and
publish it with FtrSet (call it F2). It would then check for the presence of
feature F1. If that feature is present, it will launch the app whose creator
id appears in the first 4 bytes of F1, using the launch code LinkPublished and
passing F1 as a parameter. If F1 is not present, an alert will be shown,
telling the user that the link has been published.
An app that can contain a link would provide a "Create link" command to the
user. When this command is selected, it would check for the presence of
feature F2. If F2 is present, it will use that data as its link (possibly
after getting confirmation from the user) and delete it. If F2 is not present
(or the user chooses not to use it), it would give the user a list of all
link-aware apps. The app would set a feature F1 containing a reference to the
record that will contain the link, then launch the selected app normally. The
user will publish a link, at which time the containing app will be relaunched
with the LinkPublished launch code. When this happens, the app will store the
link in F2 in the record designated by F1, then delete both features.
Much of the code to implement this would be provided in either a shared library
or a C file developers could just compile into their programs, so modifying an
existing app to be a link target would be quite simple.
What do you think?
Ben
