Yes this would be smart and convenient, particularly since a value in a field could then take on all kinds of attributes, not just the "$" prefix. One could use (and convert) international currencies by extending the nyNumberFormatFunction() hypothesized.
This all falls under the rubric of field functionality extension. My interest in this is in attacking the problem of a *variable* number of currency values on a field -- a problem that I've had to deal with in all .*card implementations. Definitely, if we can assume that a field will hold exactly 1 number value, then the posted solution is by far the best one (Geoff had also suggested this one). What I wish (an unreasonable wish prior to MC v.15) is the ability to setprop for things logically defined or declared within a field, rather than for the whole field itself. As I see it, the assumed standards for software design nowadays are pushing developers to new levels of sophistication, and often that means that interfaces are more complex, more active. Fields often don't just hold unformatted text anymore; the apps we create use fields in creative ways that execute special functionality not available in ge! neric text fields. One constructive example of this is the clickText() hypertextual ability of fields introduced in HC and still in MC. Message extensions on fields are also powerful interface possibilities, the scrollDrag message is one of the best examples. Another of the smart extensions in MC toward the potential of the field-as-active-software-function (rather than just a field-as-data-bucket) is the ability to read and write files into and out of the fields with a simple GET and PUT command via URL modifier. If we could invoke getprop on user-definable logical field *elements* then GET URL and PUT xx into URL would become exponentially more powerful.
What further extensions of field functionality do we need? (I'm getting carried away, I know). The transformation of functionality from "field" as immanent dumping ground of data to field as active element in executing the objectives of the software product is inevitable and increasingly prevalent.
(Apologies for editorializing).
Dave Cragg <[EMAIL PROTECTED]> wrote:
At 11:56 am -0700 2/10/01, Geoff Canyon wrote:
>At 10:53 AM -0700 10/2/01, F. Ricardo, Ph.D. wrote:
>>Now, it does nothing about the "$" prefix, which if absolutely
>>necessary would need implementation in something like the following
>>abominable manner. In apps like Excel, the "$" in cells are not
>>part of the data. Rather they are part of the metadata of a cell,
>>which means that something similar would need to be reflected in
>>MetaCard. Among the 2 options are to store the data in one (hidden)
>>metadata field and to display the "pretty" version of it in
>>another. This means building a 2-field management subsystem. The
>>hidden metadata field would keep a totally different version of the
>>data, for instance,
>>
>>cellH:A
>>cellV:1
>>rect:25,50! ,65,80
>>val:25.50
>>prefix:$
>>name:Net Sales
>
>Instead of using another field, couldn't you simply use custom
>properties of the field with the data in it?
>
Or go one step further and use a setprop handler. Something like:
setprop cpCurrencyValue pValue
set the cpCurrencyValue of me to pValue
put myNumberFormatFunction(pValue) into tData
set the text of me to "$" & tData
end cpCurrencyValue
But this could probably be refined some. (After coffee perhaps.)
Cheers
Dave Cragg
Archives: http://www.mail-archive.com/[email protected]/
Info: http://www.xworlds.com/metacard/mailinglist.htm
Please send bug reports to <[EMAIL PROTECTED]>, not this list.
Francisco J. Ricardo, Ph.D.
Do You Yahoo!?
Listen to your Yahoo! Mail messages from any phone with Yahoo! by Phone.
