Shana Posted September 23, 2003 Posted September 23, 2003 I am wondering if there is a way to implement an automatic tab in which the user can type information into consecutive fields (which have character limitations of 2 in each field) so that you user does not have to be interuptted by hitting tab. For example, If there is a phone number entry set up as three seperate fields of 3, 3, and 4 characters each, can the user type 10 numbers in a row without having to hit tab between area code, first three digits, and last four digits. These three fields cannot be combined into one field. (it is not a phone number for for example purposes it works the same way). Thanks
Lee Smith Posted September 23, 2003 Posted September 23, 2003 Hi Shana, What you want to do is not native to FileMaker. If I understand what you want to do, it appears you would need to execute a script based on the length of the field. There are a couple of Text plugins available, maybe one of those will do this for you. David McKee has a free on available here: http://www.geocities.com/slipdaddyneo/plPLUGs.html http://www.troi.com/software/index.html http://wmotion.com/products_plugs.html HTH Lee
Lee Smith Posted September 23, 2003 Posted September 23, 2003 I should add, that only the first site is David's. The other two are well known plugin sites, but there stuff isn't free. Lee
Shana Posted September 23, 2003 Author Posted September 23, 2003 I was thinking this could be done with a looping script but I wasn't sure how to go about it. Is that not possible?
Fenton Posted September 23, 2003 Posted September 23, 2003 This would be simple as pie with a looping script. Set Field [ First, Left(Input, 2) ] Set Field [ Second, Middle(Input, 3, 2) ] Set Field [ Third, Middle(Input, 5, 2) ] etc. It would be even simpler to just create the above as calculations. But that would not let them be enterable afterwards, without re-entering the whole Input. [optional, not for beginners, but hopefully someone more knowlegeable than me] What would not be so simple is to Lookup the above calculations into enterable fields, for 2 reasons. 1. It's trickier 2. In trying to do so I've run across some unexpected behavior. It has to do with the lookup trick, using a ModTime field and a Trigger based on a Serial auto-enter field. This is a known trick. I don't believe the "bug" is well known, however. It worked fine with the field First above. However, when I extended the technique to the Second field, it no longer worked the first time. It still worked if you actually modified the record, so in many cases it's still usuable. But it no longer worked if you did not (which it normally does). Not only that, but once it broke, it could not be fixed. Deleting both the 2nd fields (calc and lookup), leaving the file exactly as it was, did not fix it. Now that is curious. It may be like the ModTracker solution, in that field creation order was important. But I could not fix by deleting and recreating the fields, even the First fields. Weird. CharLookup.zip
Lee Smith Posted September 23, 2003 Posted September 23, 2003 Hi Shana, Maybe this file will help. Script Execution on Exiting Field by: Al Fleming at URL: http://www.fmfiles.com/tnt8.html BTW, you might also do a search for Loop at the site and see if it turns anything up that is useful. HTH Lee
Shana Posted September 23, 2003 Author Posted September 23, 2003 Ok i basically got one going in which I have a looping script that goes to the next field after there is a length of 2 characters enetered in the current field. There is a pause of 1 second in the loop. Is there anyway to do this without the pause because by having the pause it comeltely voids what i want to do which is to speed up the process of entering data. 2nd, I put the script on teh first field as a button that starts. This is fine however if the data in the first field needs to be edited, everytime i click on that field and there is data in it, it automatically goes to the next field. 3rd, If the user is tabbing from previous fields, how can I get the script to start when entering the first field of the script because the script only starts when clicked on. SOrry if this is too complicated. Thanks for the help!
spragueg Posted September 23, 2003 Posted September 23, 2003 Why not just give them a single field to enter into. Then you can have a submit buttom that grabs the string entered into the field, breaks it into 2 character chunks, and sets each chunk into the correct field?
Shana Posted September 23, 2003 Author Posted September 23, 2003 I would love for them to have them enter just one string. How can I do this. Right now it's set up llike this XX:XX:XX:XX which represents a timecode.
Lee Smith Posted September 23, 2003 Posted September 23, 2003 Why not do something along the lines of this sample of mine. Lee PhoneNumberEntry.fp5.zip
BobWeaver Posted September 23, 2003 Posted September 23, 2003 Adding to what Lee posted in his sample file, this calculation field method is often set up with the fields arranged with the calculated formatted fields placed directly over top of the entry field, with the calc fields formatted to not allow entry. When the user clicks on, or tabs to the entry field, the original unformatted data field is brought forward for entry or editing.
djgogi Posted September 23, 2003 Posted September 23, 2003 The "trigger" must be defined as unstored to make it work (and in fact it woks ) but you have only conditionaly turned off indexing for this field. Dj CharLookup 1.fp5.zip
Lee Smith Posted September 23, 2003 Posted September 23, 2003 There are three layouts, one has them stacked. I don't believe the calculation can be stored, it references a global field. I could be wrong though. Lee
Fenton Posted September 24, 2003 Posted September 24, 2003 I cannot get it to Lookup the fields upon first entry, Unstored or not. I know that it can look them up upon later modification; and quite possibly it just cannot look up the calculations the first time (it does fly in the face of the order of operations). However, when you first build such a file it CAN look up the calculation upon entry. Several people (John Mark Osborne, Ilyse Kazar) have used this trick to "format" the entry field. But what I found was that you will break this trick permanently in a file by adding a 2nd calculation to the mix, even if it is setting into another field. Maybe it's just my setup, FileMaker 6, Mac OS 9.2 and OS 10.2.6. Are you getting those lookups to occur on 1st entry on Windows?
Ugo DI LUCA Posted September 24, 2003 Posted September 24, 2003 Fenton, Create a single script New Record Exit Script Go to field (Input) Et voil CharLookup.fp5.zip
Paolo Posted September 24, 2003 Posted September 24, 2003 Automatic tab can be achieved with a looping script. Off course there are some restrictions. See attachment for an example. AutoTab.zip
Lee Smith Posted September 24, 2003 Posted September 24, 2003 Hi Fenton, I had a hard time figuring what you were saying. I assume you were saying that the demo works now (or maybe it didn't on your computer), but would break in the future because of the double calculations?? I haven't heard this one before, can you explain a little more in detail why? or under what conditions this can be expected. Surely you aren't saying the calculation will wear out over time? Lee
Ugo DI LUCA Posted September 24, 2003 Posted September 24, 2003 Lee, Fenton was worried that a lookup would not take place if there were 2 calcs referencing the same field. Wether or not it is referencing the same field, wether or not you're using this lookup from a trigger on ModTime, and wether or not the data is entered directly in the file or through a portal, has no importance here. If you create a new record using the shortcut or the Menu option, you'd directly end in the Input field. Entering some data in it straight away would lock the refreshing "process", thereby leading to no lookup. If, before entering data in the Input field, you exit the field (with or without a script step) and then come back to it, it would work. The problem stands outside these considerations, and is more likely relevant, in my opinion to the "software" refreshing procedure. What you should be aware of is that this behaviour also occurs when entering data from a related file. Taking as an example an Invoice Procedure involving an Invoice.fp5, a Customer.fp5 and a LineItem.fp5. You would probably define the Customer_ID in the Line Item to be a lookup from LineItem.fp5:Inv_ID::Invoice.fp5:Inv_ID, and may be have other lookup to the Customer file. If you script the creation of a new invoice with a single Script "Create new record", and logically chosed to lead the user into the customer field, you will notice that no lookup would take place in the Line Item when you will have entered data in the portal. If you insert a "Exit script", it will work. Lookups are ultra-dependant on refresh steps to work....
Fenton Posted September 24, 2003 Posted September 24, 2003 Thanks Ugo. You're right. It had nothing to do with the "2nd field." It was a simple case of not exiting the record after record creation, and going directly to the Input field. Since the lookup depended on the SerialID, which was not committed yet, it failed. This would seldom happen in a real world situation, but because I created it in a dead simple example file (to show someone else how to do it), I created the conditions for the error. Much ado about not much. So, in answer to the original poster, who has probably given up on us, the triggered lookup method works for multiple calculation fields. No need for a script. But you must exit the record before entering that "one text entry" field.
-Queue- Posted September 24, 2003 Posted September 24, 2003 This is somewhat similar to the issue we faced with the checkbox sort technique. The record must be re-entered for the re-refresh to occur and the data to settle correctly.
Ugo DI LUCA Posted September 24, 2003 Posted September 24, 2003 Hi Fenton, Glad I could be useful here. I faced this instance a few times in the past, reported this "apparent bug" in a few threads. It was only that "stupid" thing. I'm quite sure Goran, who drived me in this direction at that time, would have pointed you to this if he had imagine that you were processing your entries without exiting the field. And as you did, in order to solve what I considered a "odd" issue, I had made many changes, calcs, triggers, focusing on the "Mathematical" part of it rather than on the "logical". Queue, Yes, the checkbox trick was even tricker....
Jim McKee Posted October 3, 2003 Posted October 3, 2003 Hi Lee ... I really liked your demo of telephone formatting. However, I have one question. Your "Strip Entry" field, uses the calculation: Substitute(Substitute( (TextToNum(Entry)),".",""), "-","") Why is it that when I enter a phone number with "." separators and a zero as the last character, like: 954.777.2210 I get an "INVALID NUMBER" result? The "Strip Entry" field correctly removes the "." characters, but it also drops the last character of the phone number. This doesn't happen if the phone number ends in a character other than zero, or is entered with dashes, as in: 954-777-2210 In that case, the phone number is correctly formatted as (954) 777-2210. Weird, huh? Thanks
Lee Smith Posted October 3, 2003 Posted October 3, 2003 It's because of theTexttoNumber in the Strip Entry calculation. If you can modify it Substitute(Substitute( (TextToNum(Entry)),".",""), "-","") to Substitute(Substitute( Entry,".",""), "-","") But then if the user uses a mixture of ( and . such as (511) 666.6666 it will be invalid. Lee
Jim McKee Posted October 4, 2003 Posted October 4, 2003 Lee ... Thanks. This calc covers just about every non-numeric character I could think of that a user might enter: Substitute(Substitute(Substitute(Substitute(Substitute(Substitute(Substitute(Substitute(((Entry)),".",""), "-",""), "(", ""), ")", ""), " ", ""), "/", ""), ",", ""), "_", "") But, you know ... there are lots of other possibilities for user error
Ugo DI LUCA Posted October 4, 2003 Posted October 4, 2003 Hi all, Just wondering if I'm not making it too complicated, but it seems to work no matter how many separators you put inside. Case( Lenght(Substitute(Left((Entry & "99999") *10 ^ 15,15),"99999",""))=7, "(" & g_Local Area Code & ") "& Left(Substitute(Left((Entry & "99999") *10 ^ 15,15),"99999",""), 3) & "-" & Right(Substitute(Left((Entry & "99999") *10 ^ 15,15),"99999",""), 4),Lenght(Substitute(Left((Entry & "99999") *10 ^ 15,15),"99999",""))=10, "(" & Left(Substitute(Left((Entry & "99999") *10 ^ 15,15),"99999",""),3) & ")" & " " & Middle(Substitute(Left((Entry & "99999") *10 ^ 15,15),"99999",""),4,3) & "-" & Right(Substitute(Left((Entry & "99999") *10 ^ 15,15),"99999",""),4), "INVALID NUMBER") If there's one , here's the logic of this calc : Entry *10 ^ 15 will "trim" any dots inside the calc and won't remove the ending 0. --
Recommended Posts
This topic is 7724 days old. Please don't post here. Open a new topic instead.
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now