Mc MacH Mach chesnuts

On 2008-12-03 19:23:34 -0800, Grip said:

> On Dec 3, 5:16 pm, Chris Brown
> wrote:
>> Hi,
>>
>> moving on from simple proper based calcs, and having implemented
>> SmarterProper, the problem still remains of how to handle:
>>
>> MacSomething and Machinski
>>
>> Anyone ideas on how to deal with this, other than removing all auto
>> enter calc formatting?

At some point human intelligence is the last resort. You could try
keeping a table of common "Mac" last names with appropriate
capitalization and flag the entries that dont' quite match, for human
intervention. But that's a big pain in the...

It becomes too unwieldy to keep the last name table, because you've got
O'Malley and Omar to worry about, Van De Voort and Vandevender, etc.

Best bet is to get a caring data entry person (hey some of us started
out that way) and/or to offer rewards for fewest mistakes.
--
Lynn Allen
--
www.semiotics.com
Member Filemaker Business Alliance
Long Beach, CA
 >> Stay informed about: Mc MacH Mach chesnuts 

And your question is what exactly?

Hans Besjes


On 12/04/2008 01:16:41 Chris Brown wrote:

> Hi,

> moving on from simple proper based calcs, and having implemented
> SmarterProper, the problem still remains of how to handle:

> MacSomething and Machinski

> Anyone ideas on how to deal with this, other than removing all auto enter
> calc formatting?
 >> Stay informed about: Mc MacH Mach chesnuts 

You can't. A machine can not know difference between MacIntosh and
Macintosh, which both a valid spellings. Rely on user input.

Keep well, ursus

"Chris Brown" schreef in bericht

> Hi,
>
> moving on from simple proper based calcs, and having implemented
> SmarterProper, the problem still remains of how to handle:
>
> MacSomething and Machinski
>
> Anyone ideas on how to deal with this, other than removing all auto enter
> calc formatting?
 >> Stay informed about: Mc MacH Mach chesnuts 

Chris Brown wrote:
> Hi,
>
> moving on from simple proper based calcs, and having implemented
> SmarterProper, the problem still remains of how to handle:
>
> MacSomething and Machinski
>
> Anyone ideas on how to deal with this, other than removing all auto
> enter calc formatting?


thanks to all.

As Lynn suggested human intelligence was what I was hoping for; but
applied after the initial auto enter result from a custom function.


Agree with Grip, a proper calc is never going to be right all the time;
but if the cf could enter an initial suggestion, with the field then
allowing the user to correct the auto entry; that would be ideal.


Lyn, as for the apostrophe , van etc variations, the SmarterProper cf
seems quite flexible.

I was expecting that using the cf as an aec , and checking 'do not
replace existing value if any' would allow:

typing in the name,
the cf then forces its format
with a now existing entry, the user can correct the capitalisation,
without the cf re-triggering.


But FM !

If there is no existing value, when the first entry is made, when does
FM think it is going to apply the aec other than the first entry? I have
been converting calcs to aec as a general approach in a number of
solution revisions for the last 12 months, though probably always
unchecking the do not replace . So I am familiar with aec, but this just
doesn't compute in the cortex at the moment.
 >> Stay informed about: Mc MacH Mach chesnuts 

On Dec 4, 3:21 pm, Chris Brown
wrote:
> I was expecting that using the cf as an aec , and checking 'do not
> replace existing value if any' would allow:
>
> typing in the name,
> the cf then forces its format
> with a now existing entry, the user can correct the capitalisation,
> without the cf re-triggering.
>
> But FM !
>
> If there is no existing value, when the first entry is made, when does
> FM think it is going to apply the aec other than the first entry? I have
>   been converting calcs to aec as a general approach in a number of
> solution revisions for the last 12 months, though probably always
> unchecking the do not replace . So I am familiar with aec, but this just
> doesn't compute in the cortex at the moment.

FM has two options for auto-enter calcs...replace existing values or
not. That means the calc is evaluated at either record creation,
which is pretty helpful, or whenever any of the stored referenced
fields in the calc (including the field itself) are modified which is
also pretty helpful.

It sounds like what you're looking for is a way of having the calc
trigger when the field is modified the first time after record
creation. That can be done in a variety of ways.

One that comes to mind is to have a second field, Name Modified which
has the auto-enter Data checked and empty (for duplicating records)
and the auto enter calc box checked. That calc would be:
Let(
trigger = Name Field;
1)

Then the calc in the Name Field would be:
Case(not Name Modified ; SmartProper(Name Modified); Name Modified)

Both auto calcs should be unchecked to always replace.

On record creation, Name Modified would be null. When a name is put
in the Name field for the first time, it would enter the SmartProper()
result. That entry triggers the Name Modified calc which becomes 1
and suppresses the SmartProper() from occurring again.
 >> Stay informed about: Mc MacH Mach chesnuts 

HiGrip,


thanks;



Grip wrote:

>
> It sounds like what you're looking for is a way of having the calc
> trigger when the field is modified the first time after record
> creation. That can be done in a variety of ways.

yes, that's what I was after. Should have occured to me to use a control
field


>
> One that comes to mind is to have a second field, Name Modified which
> has the auto-enter Data checked and empty (for duplicating records)
> and the auto enter calc box checked. That calc would be:
> Let(
> trigger = Name Field;
> 1)
>
> Then the calc in the Name Field would be:
> Case(not Name Modified ; SmartProper(Name Modified); Name Modified)
>
> Both auto calcs should be unchecked to always replace.
>
> On record creation, Name Modified would be null. When a name is put
> in the Name field for the first time, it would enter the SmartProper()
> result. That entry triggers the Name Modified calc which becomes 1
> and suppresses the SmartProper() from occurring again.


My result
entry field: LastNameSP
control field: LNMmod

LastNameSP aec, allow replace existing:
If(
LNmod = 1; NameLastSP;
SmarterProper ( NameLastSP ; 2 ; "" ; "Mc" & "¶" & "Mac" )
)


LNMmod, aec, allow replace existing:
If( IsEmpty(NameLastSP) ; "" ; 1)




thanks

Chris
 >> Stay informed about: Mc MacH Mach chesnuts