On Tue, Sep 03, 2002 at 02:40:08PM +1000, George Bassili wrote:
> This is my fourth post of this and no one has answered - i can find
> anything in the archives or other sources. Someone please just tell me if
> this is just not done.
Okay: this is just not done. If noone's answering, it's because the
information you are giving has not moved anyone to answer. Just reposting
the same question over and over again is merely annoying. It's possible
that some exasperated person will respond to these reposts, but only at
the cost of your reputation. If you want to get an answer and retain
your reputation, IMHO what you need to do is show that you are continuing
to think about your problem and demonstrate the results of your further
research when you repost your question, or, rather, when you post another
(better) question related to your particular issue.
But in fact, me, I became a little bit interested in this after your
third posting...
>> I'm searching more than one database in my app and calling FindSaveMatch to
>> store each hit.
>> I [need to store] the Database Type [somehow] to
>> retrieve it later if i need tro resume the search.
When you say "resume the search" I suspect you're talking about the way
you get a second sysAppLaunchCmdFind launch command if you have more
results to display and the user taps on "Find More". So I think your
question is about communicating information from one sysAppLaunchCmdFind
launch to the next.
Given that, I'm surprised that in the week you've been posting this
question, your ongoing research hasn't led you to a palm-dev-forum
search for "FindParamsType", which turns up the following thread,
obscurely :-) entitled "Find in Multiple Databases":
http://www.escribe.com/computing/pcpqa/m52751.html
http://www.escribe.com/computing/pcpqa/m52798.html
And also the thread of which this is an interesting part (but read the
surrounding messages too):
http://www.escribe.com/computing/pcpqa/m714.html
>> I'm storing the Database Type in the appCustom Field which is a UInt32 to
>> retrieve it later if i need tro resume the search.
>>
>> However I am having problems retrieving its value. I use this code but it
>> doesn;t seem to work:
>>
>> UInt32 dbType = findParams->match[(findParams->numMatches -
>> 1)].matchCustom;
Now that we realise that what you want to do is remember which database
you're looking at from one sysAppLaunchCmdFind to the next, we can look
at how to record that information. It seems to me that there are three
basic options:
1. Depend on someone else's (namely the operating system's) record.
This is what you are trying to do by peering into findParams->match[..].
This is IMHO such a bad idea that I'm not even going to talk about it.
That's a big complicated data structure, and you have no reason to
believe that the OS is doing with numMatches what you hope it might
be, or that the next OS will do the same thing. Well, you might
study the OS source code to give yourself a reason, but the big hint
in the headers that these fields are subject to change is a big hint!
IMHO we should Just Say No to peering at undocumented complicated OS
data structures like this, especially when there is no real need to
do so.
2. Record it yourself, within (the public part of) your FindParamsType
argument.
The documented way that sysAppLaunchCmdFind communicates what you
have to do to you is via findParams->recordNum. So for example you
could likely encode your extra data here; e.g. if you have three
databases and DB1 has N1 records and DB2 has N2 records, then within
your find routines, decode so that
recordNum <= N1 means DB1 record #recordNum
N1 < recordNum <= N1+N2 means DB2 record #(recordNum - N1)
N1+N2 < recordNum means DB3 record #(recordNum - N1 - N2)
You get the picture. Unfortunately this breaks down if your
databases are large (you must satisfy N1 + N2 + N3 <= 64K instead of
the looser N1 <= 64K, N2 <= 64K, N3 <= 64K).
The other field clearly in the public part of FindParamsType is
reserved1, and inconclusive testing shows that it is indeed preserved
between sysAppLaunchCmdFind launches, at least on some OS versions.
You could easily store a database number 1, 2, 3, ... in there; but
some people would call this crazy :-).
3. Record it yourself, outwith your FindParamsType argument.
Reentrancy isn't a concern here, so you can use the standard C hack
of storing your extra information that you need to remember in a
static global variable. Of course, in a sysAppLaunchCmdFind launch
you don't have real "global variables"! The thing we use on Palm OS
when we want to remember static data but we don't have global variables
is a feature. So you can record the information you need to remember
in a feature, as Mark suggested in the thread above.
>> I also note the header files indicate these fields should not be accessed,
>> but why is this field there if we can;t use it!
Because the OS uses it internally, presumably. Of course, one wonders
what it's doing in a public header file, but that's another story :-).
>> The docs say you can use. From the ref guide - "appCustom Extra data the
>> application can save with a match."
What the docs say is that the cookie you pass (via appCustom) to
FindSaveMatch will be recorded somewhere and, if the user selects the
corresponding UI item, will be given back to you later when you are
CmdGoTo launched (via matchCustom in your GotoParamsType argument).
The docs do not say that you get to fiddle in-between-times with what
the OS has recorded, wherever it might have done so! :-)
John
--
For information on using the Palm Developer Forums, or to unsubscribe, please see
http://www.palmos.com/dev/support/forums/
