<000801be863e$487e8ca0$5c0801c-@fsnjf> wrote:
Original Article: http://www.egroups.com/list/palm-dev-forum/?start=10560
> A proposal for all palm developers... It would be very useful to have some
> kind of published, universal mechanism that would link records together from
> various applications. I have been thinking about this for Datebk3 - someone
> wants to put a drawing in associated with an appointment, for example. How
> could I implement this?
I have thought of doing something like this for my own application
(http://www4.ncsu.edu/~bgdarnel/synapse/).
> Specifically we need:
>
> The Creator ID
> The Unique ID for the record (record number won't work because it will
> change)
>
> In addition, the application might need additional information in order to
> select the record (i.e. name of the database, etc. etc.), and the amount of
> information might be PURELY a function of the application we're linking to.
This can be simplified: we need the creator id of the application, and enough
information to allow the app to locate the target of the link. In the simplest
case (app only uses one database), this information can simply be the Unique ID
(although IIRC, the official word from Palm is that UID's are not to be relied
upon, since there are circumstances which may cause them to change). Other apps
may require both a DB name and record UID. Still other apps (such as Doc
readers) do not use records, and so might use a DB name and an offset into the
document.
>
> How about something like this?
>
> When the user selects a record, they can invoke a menu option with a legend
> like: Mark for Linking. The application then does something like this
> (please don't write me saying there is a bug in this code, ok?<g>)
UI had been one of my biggest stumbling blocks, and a "Mark for Linking" menu
command solves that problem nicely.
>
> When invoking the menu option, the program does something like the above and
> ends up informing the user that they can now switch to the application that
> needs to insert the link. In the target application, I might then select a
> record and issue a menu command like: Pickup Link.
>
> If the <<Feature Num>> argument were assigned to each application. The
> PickupLink command could then display a list of all published links. But
> this could also lead to a lot of dangling links plus more work to implement,
> so I think that just having one link at a time might actually be best. The
> app would check to see if the Feature exists and then bring up an alert that
> says something like:
I agree that only one link should be active at a time.
>
> Set Link to record in CESD Application?
> [YES] [NO]
>
> or complain that it could not find a link
>
> The application subscribing to the link has the handle (linkH) and knows
> that the structure is just three Longs. Presumably it will save that
> information somewhere and release the memory for the handle (since it was
> "disowned" by the creating application). When it needs to invoke this link,
> it uses the creatorID to setup the cardNo and dbID and sets up the
> GoToParamsType block as follows:
I suggest that rather than using the sysAppLaunchCmdGoTo launch code, we
establish a new launch code to be used for this purpose. That way we could
define our own structure, instead of mangling the data to fit GoToParamsType.
>
> The application being linked to just has to check for 0xFFFF in the record
> field and if so, retrieve the uniqueID and look up the current record number
> for that record (or provide an alert if the record was no longer in the
> database and switch then to some List/index view of all records). If the
> extraInfo field was not null, the application should retrieve the
> information it stored there AND also release the "disowned" handle.
This is one of the main problems with having an extra handle. If the memory is
released when the link is followed, then the link can only be used once. If it
is not, then there is no easy way to tell when it should be released, and you
will end up with dangling chunks. The extra handle has other problems, since it
will not be backed up and is destroyed on a reset (unless the application wants
to create a database for storing these link handles, and even then the link could
not survive data loss and restoration, as the handle would change).
Here's my complete idea:
The user executes the "Mark for Linking" menu command in the target application.
That application then allocates a structure containing:
ULong creator_id;
Byte number_of_extra_bytes; /* 256 bytes should be more than enough */
Byte data[number_of_extra_bytes];
For example, if the application uses unique ids to find records, it would
allocate 8 bytes, storing its creator id in bytes 0-3, the number 3 in byte 4,
and the uid of the record in bytes 5-7. It would then disown this structure and
set it as a feature.
The user switches to the application that will contain the link itself, and
executes the "Create Link" command. That app will most likely copy the feature
into its own data structures and then free the disowned memory.
When the user chooses to follow the link, the target application will be launched
with the newly defined launch code, and will be passed its own data structure as
a parameter.
I realize that making the link structure variably sized complicates matters for
applications that store links, but I don't see any way around that.
Let me know what you think.
Ben Darnell
[EMAIL PROTECTED]
