Fileman question.

[Kevin Toppenberg]

I have a custom file with the 0.1 field looking like this:

File: TMG MEDICATION                      
REF  NODE;PIECE     FLD NUM  FIELD NAME
==================================================
  1  0;1                .01  GENERIC NAME                             [RFJ64X]
     .02;0              .02  GENERIC ALIASES                <-Mult [22733.022]
  2   -0;1              .01   -GENERIC ALIAS NAME                     [MFJ64X]

With detail looking like this:

--------------------------------------------------------------------------------
  FIELD NAME:       GENERIC NAME

  FLD NUMBER:       .01             FLD TITLE:
  NODE;PIECE:       0;1            HELP FRAME:

      ACCESS:       RD:    DEL:    WR:

   DATA TYPE:       Free Text
                    Required field
                    Input Transform has been modified in Utility Option

  INPUT TRANSFORM:  S X=$$UP^XLFSTR($G(X)) K:$L(X)>64!($L(X)<2)!'(X'?1P.E) X

  PROMPT MESSAGE:   Answer must be 2-64 characters in length.

 OLD-STYLE INDEXES

  INDEX: B
     Type: REGULAR
     Node: 1        S ^TMG(22733,"B",$E(X,1,30),DA)=""
     Node: 2        K ^TMG(22733,"B",$E(X,1,30),DA)

  INDEX: ABSP
     Type: MUMPS
     Node: 1        DO KILLXR^TMGRX004
     Node: 2        DO KILLXR^TMGRX004
     Node: DT       3171008

I want to focus on that input transform:

INPUT TRANSFORM:  S X=$$UP^XLFSTR($G(X)) K:$L(X)>64!($L(X)<2)!'(X'?1P.E) X

This input transform was automatically generated when I created the text field with size between 2-64 chars.  

If one were to edit the field, it would look like this

Select VA FileMan Option: MOdify File Attributes
Do you want to use the screen-mode version? YES// NO

Modify what File: TMG MEDICATION//        (568 entries)

Select FIELD: .01  GENERIC NAME
LABEL: GENERIC NAME//
TITLE:
AUDIT:
AUDIT CONDITION:
READ ACCESS (OPTIONAL):
DELETE ACCESS (OPTIONAL):
WRITE ACCESS (OPTIONAL):
SOURCE:
Select DESTINATION:
Select GROUP:
DESCRIPTION:
  Edit? NO//
TECHNICAL DESCRIPTION:
  Edit? NO//

DATA TYPE OF GENERIC NAME: FREE TEXT   (FIELD DEFINITION IS NOT EDITABLE)
MAXIMUM LENGTH OF 'GENERIC NAME':  (1-250): 64//
IS GENERIC NAME ENTRY MANDATORY (Y/N): Y//   YES
....
'HELP'-PROMPT: Answer must be 2-64 characters in length.
           Replace
XECUTABLE 'HELP':

Select FIELD:

Notice that there is no mention in the above that punctuation chars can not be used to start the value stored in this field. 

The specific part of the input transform is the last part

S X=$$UP^XLFSTR($G(X)) K:$L(X)>64!($L(X)<2)!'(X'?1P.E) X

To decode the syntax, the input transform will KILL X if any of the following conditions are med:

• $LENGTH(X)>64
• $LENGTH(X)<2
• NOT MATCHING PATTERN MATCH: 
  • X IS NOT 1 PUNCTUATION CHAR, THAN ANY NUMBER OF OTHER CHARS

The double negation is a bit confusing to me. Are not the following the same?

'(X'?1P.E)

X?1P.E

Example:

X="Apple"

test:         result:

-------       ----------

X?1P.E        false

X'?1P.E       true

'(X'?1P.E)    false

X=".Pear"

test:         result:

-------       ----------

X?1P.E        true

X'?1P.E       false

'(X'?1P.E)    true

Questions:

• Why does Fileman automatically add an exclusion for punctuation characters in character position #1?  What if I wanted to be able to store "*value", for example?  Would it mess up the cross-referencing behavior?  (I suspect this is the answer)
• Why does it use '(X'?1P.E) and not X?1P.E  ?

Thanks in advance,

Kevin

[Sam Habiel]

> Why does Fileman automatically add an exclusion for punctuation characters in character position #1?  What if I wanted to be able to store "*value", for example?  Would it mess up the cross-referencing behavior?  (I suspect this is the answer)

I don't know the exact reason, but I looked at the documentation and it's clearly documented (and has probably been so for more than 30 years). See https://www.hardhats.org/fileman/u2/cr_mod.htm. If George or Skip read this, maybe they remember.

> Why does it use '(X'?1P.E) and not X?1P.E?

M precedence. If you do ...X?..., it will evaluate X first, then do the pattern matching. So you would have had to add a paren to prevent that in any case.

--Sam

--
--
http://groups.google.com/group/Hardhats
To unsubscribe, send email to Hardhats+u...@googlegroups.com

---
You received this message because you are subscribed to the Google Groups "Hardhats" group.
To unsubscribe from this group and stop receiving emails from it, send an email to hardhats+u...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/hardhats/177ba2ca-ff64-4613-b761-d0a180b4ef49n%40googlegroups.com.

[Kevin Toppenberg]

On Wednesday, August 13, 2025 at 11:46:19 AM UTC-4 Sam Habiel wrote:

> Why does Fileman automatically add an exclusion for punctuation characters in character position #1?  What if I wanted to be able to store "*value", for example?  Would it mess up the cross-referencing behavior?  (I suspect this is the answer)

I don't know the exact reason, but I looked at the documentation and it's clearly documented (and has probably been so for more than 30 years). See https://www.hardhats.org/fileman/u2/cr_mod.htm. If George or Skip read this, maybe they remember.

Thank you for looking into this.  The link you provided describes restrictions on field NAMES, not field VALUES.  There may also be a similar restriction for field VALUES.  

 

> Why does it use '(X'?1P.E) and not X?1P.E?

M precedence. If you do ...X?..., it will evaluate X first, then do the pattern matching. So you would have had to add a paren to prevent that in any case.

I don't quite follow the logic, but I'm sure you are correct that it has something to do with this.

Thanks

Kevin

[Greg Kreis]

My suspicion is that the DICOMP* routines build code with this code inserted and this makes it compatible with the building scheme.

On 8/13/2025 12:25 PM, Kevin Toppenberg wrote:

> Why does it use '(X'?1P.E) and not X?1P.E?

M precedence. If you do ...X?..., it will evaluate X first, then do the pattern matching. So you would have had to add a paren to prevent that in any case.

I don't quite follow the logic, but I'm sure you are correct that it has something to do with this.

-- 
-------------------------
Greg Kreis, President
Pioneer Data Systems, Inc
678-525-5397 (mobile)
770-509-2583

[David Whitten]

On Friday, August 15, 2025, John McKeon <mckeonmat...@gmail.com> wrote:

Hi Kevin,

• Why does it use '(X'?1P.E) and not X?1P.E  ?

An acceptable value X would match the negation of that KILL expression: '( $L(X)>64!($L(X)<2)!'(X'?1P.E))

Apply DE Morgan's Laws (OR's become AND's and each term gets negated) to get '($L(X)>64),'($L(X)<2),''(X'?P.E)
Which reduces to $L(X)<=64,($L(X)>=2),(X'?P.E)

John

Except that a post-conditional is an expression that requires “&” instead of commas. 

Commas are used in a if-argument, and technically create a nested set of IF commands, which 

functionally implements a logical AND of the arguments. 

The other issue is you want the post-condition to be true to KILL X. 

Which requires the negation of your final form. 

So KILL:’($L(X)<=64)&($L(X)>=2)&(X'?P.E) X 

 would be used with this form of the expression as a post-condition.

Dave Whitten

713-870-3834

--
--
http://groups.google.com/group/Hardhats
To unsubscribe, send email to Hardhats+unsubscribe@googlegroups.com

---
You received this message because you are subscribed to the Google Groups "Hardhats" group.

To unsubscribe from this group and stop receiving emails from it, send an email to hardhats+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/hardhats/6b9dd7f4-1683-46ac-afd4-d5525e9c5f7cn%40googlegroups.com.

[George Timson]

Kevin at first confused me by saying:

I want to focus on that input transform:

INPUT TRANSFORM:  S X=$$UP^XLFSTR($G(X)) K:$L(X)>64!($L(X)<2)!'(X'?1P.E) X

This input transform was automatically generated when I created the text field with size between 2-64 chars.  

But the Data Dictionary he shows contradicts him by saying:

                    Input Transform has been modified in Utility Option

Ignoring that contradiction now, I 'focus' on his main complaint, which is that the 'automatic' input transform prohibits the value of a field starting with a punctuation character.  When I wrote FileMan, I put this check in because people would often mis-type and put a space character, or even a "?", at the beginning of their answer.  Then when they'd go back and look for the answer, they wouldn't find it because it started with a space, which of course is hard to see.

Was this a good check to make automatically?  Well, I wrote the code that generates this over 45 years ago, and this is the first time I've heard the complaint, so I think it has been a good input check.  Yes, I see that the help-prompt might, as automatically created, mention the 'no leading puncuation' rule, but that might confuse more people than it helped, since, really, a "NAME" just does not normally start with punctuation!

By the way, it is the DICATT* routines that create field definitions like this.  The DICOMP* routines only create computed-field code.

-George

[George Timson]

Actually, as I look at this, Kevin's whole problem was his false assertion that the field hadn't been modified.

If you create a new file, the .01 field actually will contain the help message about "starting with punctuation".   And only the .01 field gets this check logic automatically.

--George

[Sam Habiel]

> When I wrote FileMan, I put this check in because people would often mis-type and put a space character, or even a "?", at the beginning of their answer.

Thank you George.

--Sam

--
--
http://groups.google.com/group/Hardhats
To unsubscribe, send email to Hardhats+u...@googlegroups.com

---
You received this message because you are subscribed to the Google Groups "Hardhats" group.

To unsubscribe from this group and stop receiving emails from it, send an email to hardhats+u...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/hardhats/dad1212f-372e-4e67-a120-519c5a92955fn%40googlegroups.com.