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?
Clearly it makes no sense for me to add yet piles more code to support a
drawing module, especially when there are plenty of good drawing programs on
the market. What I really want to do is just have the user tap on a link
icon and be taken automatically to the drawing application WITH that
particular record selected.
However this is done, it must be INCREDIBLY simple or it won't get adopted
anyway, so let's keep that in mind too. The difficulty is that the
application setting the link might not have a clue as to what the database
structure is that it is linking to.
The global find mechanism provides a perfect solution for FINDING a record
and linking to it. Most applications support the global find, so once I KNOW
the record number, it's pretty easy for me to launch that application with
that record selected.
So how do I know which record to link to? Clearly I need to have a feature
in that application that saves the link information for that record.
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.
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>)
struct LinkStructure
{
ULong creatorID;
ULong uniqueID;
Handle extraInfoH;
}
Boolean PublishLink( ULong myCreatorID, Word recordNum, Handle xInfoH);
linkH = MemHandleNew( sizeof(LinkStructure));
if (linkH != NULL )
{
linkP = (struct LinkStructure *) MemHandleLock(linkH);
linkP->creatorID = myCreatorID // Creator ID
for my application
DmRecordInfo (dbP, recordNum, NULL, &recordID, NULL); // Get unique
ID for selected record
linkP->uniqueID = recordID; // Save unique ID here
linkP->extraInfoH = xInfoH; // Handle or NULL
MemHandleUnlock(linkH);
MemHandleSetOwner (linkH, 0); // Detach owner so handle is not
released by OS on exit
if ( xInfoH != NULL )
MemHandleSetOwner (extraInfo, 0); // Ditto for the extra
information string (IF NEEDED)
//
// Creator is some agreed upon code for Creating these links. FeatureNum
could be a fixed value or perhaps even a unique code for each application
that supports this feature???
//
FtrSet (<<creator>>, <<Feature Num>>, (DWord) linkH); // Publish
the link now
FrmAlert( LinkDoneAlert ); // Tell them to switch now -
link has been published
}
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:
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:
recordNum = 0xffff to signal that we're doing a link rather than a regular
global find.
matchPos = High order 16 bits of the UniqueID (actually just 8 bits here)
matchFieldNum = Low order 16 bits of the UniqueID
matchCustom = DWord value of handle for the extraInfo field (may be NULL)
The Global find would never return a value of 0xffff in the record number
field, so this can be quite safely used to indicate that something special
is going on here.
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 strikes me as a pretty simple mechanism to implement, yet it could add
a lot of very useful functionality to various third party applications. I
will probably implement a scheme like this ANYWAY in the next version of
Datebk3, but before doing that, I was hoping to get some feedback on this
idea as it would obviously be beneficial if a number of us developers could
agree on a mechanism. I have spent all of 30 minutes thinking about a
specific mechanism to do this, so by all means shoot your arrows as there
are probably some blatant oversights somewhere! <g>
I DO think we need to keep it VERY simple. Every now and then I get a note
from some other developer suggesting that I add some feature to Datebk3, but
after looking at a 40k header file and several hundred lines of code to
implement it, I just politely file it away for mananaland.
It has to be easy enough that most developers could implement it in 30 odd
lines of code and test it, all in much less than an hour.
Thoughts anyone? If there is some positive feedback, I would take those
suggestions and provide a draft document describing this mechanism along
with code fragments that I would then publish hopefully for
implementation...
____ ____
/ ___) / ___)
( (___ ( (___
\____)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
. . . . . .
