Jump to content
The ORIGINAL FileMaker Community - Forum - Online Business Apps & Software Forum
KendallBond

Email container field contents

Recommended Posts

KendallBond

I am trying to figure out how to take the results from a search and email them. I want to send the contents of a container field to the contact.

 

So if I could search by a status code within my system and it comes up with 30 files. I would then create an email for each file, including certain fields and most important the contents of the container fields.

Share this post


Link to post
Share on other sites
AHunter3

Set Variable [$PathtoAttachment, Get(DocumentsPath) &"/" & "MyDesiredAttachmentName.jpg"]

 

Export field contents [YourTable::ContainerField, $PathToAttachment], no dialog

 

Send Mail [To=YourTable::emailaddress, Subject="hello", Body="YourTable::emailbody, Attachment=$PathToAttachment] no dialog

Share this post


Link to post
Share on other sites
KendallBond

can you describe in more detail?

Share this post


Link to post
Share on other sites
AHunter3

Can you explain in more detail what part you don't get?

 

Sorry, I'm not being snide on purpose, I really don't know how to elaborate. I didn't really leave anything out. You list your skill as "Intermediate". I assume you've used the Send Mail script step before?

Share this post


Link to post
Share on other sites
Jack Rodgers

Filemaker will not (8.5) export a container field.

 

CNS has a plugin (and perhaps others but I have tested this one) that will send an email with a container field showing as a graphic. And they have a technique of capturing a layout, actually a Preview, so you can email a Filemaker invoice or other layout. Of course you will need to design and test the layout for useability.

 

http://www.cnsplug-ins.com/products.htm?product=SMTPit%20Pro

 

This may be a bit much since you are just learning about databases but their help files are quite easy to understand.

Share this post


Link to post
Share on other sites
Jack Rodgers
Set Variable [$PathtoAttachment, Get(DocumentsPath) &"/" & "MyDesiredAttachmentName.jpg"]

 

Export field contents [YourTable::ContainerField, $PathToAttachment], no dialog

 

Send Mail [To=YourTable::emailaddress, Subject="hello", Body="YourTable::emailbody, Attachment=$PathToAttachment] no dialog

 

Filemaker, in a short test, will only export the container field to another Filemaker file. If the client has Filemaker, this may be OK. If not...

 

During the Export setup there is a checkbox for attaching the export file to an email so it is possible to bypass Send Mail. Of course this loses the ability to target an email address within Filemaker.

Share this post


Link to post
Share on other sites
Jack Rodgers

 

I tried the Export Field command in a button (8.5) and ONCE AGAIN filemaker refused to export the contents of a container.

 

I also tried it in a script with the same results.

 

Then I did what every good developer should do, I debugged my stuff. Turns out the pdf file in the field I tested was not there but I had used a pointer instead.

 

When I inserted a jpeg, the export worked. When I inserted a new pdf it worked. It would not work with a pointer except to export it to a Filemaker file.

 

Odd that Filemaker would return the error message "Container Fields Can't Be Exported" when there is no data in the field. The wording is misleading. I would think the proper error would be "Empty Container Field ...blah blah" or "Container contains a datapath not a file". Note that Send Mail will create an email message even when the fields are empty.

 

Also interesting is that when I exported the field to a Filemaker file, the pdf was actually inserted into the file rather than using the pointer. This might be an interesting technique if you need to actually export the pdf from Filemaker when the container just contains a pointer.

Share this post


Link to post
Share on other sites
AHunter3

Sorry, sorry, I should have mentioned that. If what is actually stored in the container field is a reference, you want to send the email with the attachment's file path being abstracted from GetAsText(ContainerField). No reason to export it, it's already in existence outside of FileMaker!

 

It's useful to know whether the reference is stored as a consequence of "Insert Picture (store reference only)" or "Insert File (store reference only)" or for that matter Insert QuickTime (store reference only)". Each returns a slightly different kind of string, but each has a path that you can utilize; in the case of Picture or QuickTime you need to modify the string slightly to obtain a file reference (which is what you want when you specify the attachment).

 

You can, in fact, use GetAsText(Containerfield) to assess in the first place whether the item in the container field is really in it or if only a reference is stored there: it's going to return a huge, nonsensical-to-humans string if an actual file or picture is stored in the field, and you can use Length(GetAsText(Containerfield)) to get a sense of that. There's probably a precise formula for the max string that a file reference would consist of, but off the top of my head, figuring 255 chars for file path plus the overhead of FileMaker's additional/redundant way of expressing it, I'd say anything >300 characters is probably not stored as a ref.

Share this post


Link to post
Share on other sites
Jack Rodgers

No problem. I learned something in my test that I didn't know, for whatever it is worth.

 

It is interesting that Filemaker will not insert as an attachment a referenced file but will insert that file in a copy to a Filemaker file.

 

Doesn't it all get so confusing? And this may change, no proof, with each version. If so, and only if so, then your scripts will start working incorrectly after an upgrade...

 

One of my favorite all time db update screwups was when one of the dbs decided to change the action of a function but not the name.

 

They announced, "We are changing the function 'Do it This Way' so it now subtracts instead of adds. We are not changing the name of the function;"

 

Of course I jest in the above paragraph, it wasn't quite that extreme, but when that info was posted I replied in ALL CAPS.

 

Filemaker did something like that in the first version of 6 when the algorithm for dating two digit years was adjusted by 100 years. Blew a lot of lock vertical solutions right out of the water. Of course they should not have upgraded, but... And Filemaker should NEVER have allowed two digit years.

Share this post


Link to post
Share on other sites
AHunter3

FileMaker didn't really allow "two-digit years" in the storage sense. It was strictly a convention on how to handle data input typed in (or imported in) as 2-digit dates. But yeah, one day FileMaker Inc decides that 1/17/29 will be comprehended as January 17th of 2029, whereas in the previous version it would've been January 17th of 1929. Well, they had to flip it at some point, right? Either that or refuse to let folks type in "1/17/29" when doing data entry, and/or refuse to allow import of dates stored in that fashion.

 

Dates in FileMaker are stored in computer-language as serials beginning with January 1 of the year 1 A.D. being 1 and ending with 1460970, which corresponds to December 31, 4000. So there's an incipient Y4K problem (or Y4K+1 problem to be more accurate) but dates are not and have not ever been stored as two-digit (100-year maximum span) dates.

Share this post


Link to post
Share on other sites
comment
GetAsText(Containerfield) ... it's going to return a huge, nonsensical-to-humans string if an actual file or picture is stored in the field

 

I don't know where you're getting that stuff from. If a file is embedded in a container field, GetAsText ( Containerfield ) returns the embedded file's original name. Length ( GetAsText ( Containerfield ) ) returns the number of characters in same. Length ( Containerfield ) returns the size of the embedded file in bytes.

Share this post


Link to post
Share on other sites
Jack Rodgers
FileMaker didn't really allow "two-digit years" in the storage sense. It was strictly a convention on how to handle data input typed in (or imported in) as 2-digit dates. But yeah, one day FileMaker Inc decides that 1/17/29 will be comprehended as January 17th of 2029, whereas in the previous version it would've been January 17th of 1929. Well, they had to flip it at some point, right? Either that or refuse to let folks type in "1/17/29" when doing data entry, and/or refuse to allow import of dates stored in that fashion.

 

Dates in FileMaker are stored in computer-language as serials beginning with January 1 of the year 1 A.D. being 1 and ending with 1460970, which corresponds to December 31, 4000. So there's an incipient Y4K problem (or Y4K+1 problem to be more accurate) but dates are not and have not ever been stored as two-digit (100-year maximum span) dates.

 

 

A simple reading of Filemaker's file with Word or a disk editor will show you the dates being saved to disk as 11/11/11 or 11/11/1111. At least in earlier versions.

 

The 'Filemaker Date Problem' began with the original design and is still carried into the latest versions.

Share this post


Link to post
Share on other sites
AHunter3
I don't know where you're getting that stuff from. If a file is embedded in a container field, GetAsText ( Containerfield ) returns the embedded file's original name. Length ( GetAsText ( Containerfield ) ) returns the number of characters in same. Length ( Containerfield ) returns the size of the embedded file in bytes.

 

Perhaps I'm thinking of what happens when you store a PICTURE (not as reference) in a container field?

Share this post


Link to post
Share on other sites
Jack Rodgers

 

An urban legend?

 

The method described is how a computer handles dates.

 

If you open your filemaker file, best create a new one and create a few date records, you will find the date stored on disk as you entered it, not as described above.

 

I was just reading the Filemaker help file on dates and converting them and found myself laughing at the silliness of it all just because the Filemaker programmers originally did not select a good choice for handling dates and has carried that nasty little idea forward into today. It was the first time I found myself actually LAUGHING at a database help file.

 

"Conversion of dates with two-digit years" is probably the funniest and saddest help page in the history of databases...

Share this post


Link to post
Share on other sites
AHunter3

Sorry, but you're quite simply wrong.

 

What the heck would a computer do with a silly string like "4/30/07"? Even if it were only storing two-digit dates it would not store it like that; it would store it as 070430 or something. The computers that had problems with the Y2K bug were doing that kind of thing.

 

But FileMaker does not do that. Never did.

 

If you open FileMaker 2.1 and define two fields, a date field named DateField and a calculation field of result type number defined as Year(DateField), and type in "4/3/35" in the date field, the calc field will display "1935".

 

Type in "4/3/1935" and it again displays "1935"

 

Create two more fields, a number field "Years to Subtract" and a calc field, result type "date", = DateField - Years to Subtract * 365.24, call it ResultDate.

 

ResultDate displays 04/03/35, or 4/3/35, or 4/3/1935 or for that matter April 3, 1935 depending on how you format it on the layout. Enter 40 in the Years to Subtract and it changes to 04/01/1895. Change the original DateField to "5/1/1307". ResultDate is "04/30/1267"

 

It is obviously very 20th century in its default assumptions about what to do with 2-digit dates that YOU hand to IT, but the dates are stored as real dates. Were that not the case, it could not do the math.

Share this post


Link to post
Share on other sites
Jack Rodgers

I am withdrawing from this date thread smiley_cool

 

The logic just presented is so flawed I don't have the time to correct it smiley-tongue-out

Share this post


Link to post
Share on other sites
comment
Perhaps I'm thinking of what happens when you store a PICTURE (not as reference) in a container field?

 

I don't know what you're thinking of. I only know what happens in fact. What I said holds true for an embedded picture too. If you think otherwise, post a file showing "a huge, nonsensical-to-humans string" as a result of GetAsText(Containerfield).

Share this post


Link to post
Share on other sites
comment

I agree that the arguments offered against your theory were weak, so I have decided to test for myself your claim that:

 

A simple reading of Filemaker's file with Word or a disk editor will show you the dates being saved to disk as 11/11/11 or 11/11/1111. At least in earlier versions.

 

I have made a new file with with only one field defined as type Date. I have entered several dates, carefully inputting only 2 digits for the year. These were, of course, converted on-the-fly into full dates - some in this century, some in the previous one.

 

Then I opened the file in a text editor, and there were all my dates, stored as full, 4-digit year, dates - and only as full dates. This was true for both version 4 and version 6 of Filemaker (I don't think you can read the data from an .fp7 file in a text editor, and in any case your claim was regarding earlier versions).

Share this post


Link to post
Share on other sites
Jack Rodgers
I agree that the arguments offered against your theory were weak, so I have decided to test for myself your claim that:

 

 

 

I have made a new file with with only one field defined as type Date. I have entered several dates, carefully inputting only 2 digits for the year. These were, of course, converted on-the-fly into full dates - some in this century, some in the previous one.

 

Then I opened the file in a text editor, and there were all my dates, stored as full, 4-digit year, dates - and only as full dates. This was true for both version 4 and version 6 of Filemaker (I don't think you can read the data from an .fp7 file in a text editor, and in any case your claim was regarding earlier versions).

 

My results differed from yours and were done several years ago which is why I have posted as I have. I would not have made my comments without opening the file with Word and viewing the text.

 

Note that the dates are stored as xx/xx/??xx as I have stated and not as others have said as numbers. Thank you for verifying that part.

 

Did you use the default values for a new date field or adjust it for 4 digit years? I would think that Filemaker would store it as xx/xx/xx if you enter it that way since it will display it that way.

 

If I recall correctly, both 4 and 6 would retain the exact entry but perform their conversions for arithmetic. Display and entry xx/xx/xx but for math they would have to convert to xx/xx/xxxx and then to the number used reverting to xx/xx/??xx when saved to disk or displayed.

 

This confusion should no longer exist in newer versions and only does so because Filemaker wants to sell update boxes.

 

Maybe the answer is for Filemaker to add 'Real Date Field', 'Real Number Field' and 'Real Decimal Field' etc. while retaining the old messy fields that have in some cases wrecked havoc with locked solutions when upgraded.

 

I have no arguments with anyone who likes the text fields disguised as number and date fields. But adding a 'real' date field and number field that won't accept 64K of text would be a nice start.

 

But hey, it only took Filemaker 15-20 years to add $$variables available in most other databases for over 20-30 years...

Share this post


Link to post
Share on other sites
comment
Did you use the default values for a new date field or adjust it for 4 digit years?

 

I am not aware of any option to "adjust" a date field for 4 digit years (unless you meant validation - but then I couldn't have done what I did). In any case, I did exactly what I wrote I did and nothing else.

 

 

My results differed from yours and were done several years ago

 

That is my point. Surely, versions 4 and 6 are the same now as they were several years ago. So unless you can provide a way to repeat your experiment and reproduce the same results, I have no choice but to dismiss your factual findings - along with all the theories and conjectures built upon them.

Share this post


Link to post
Share on other sites
Jack Rodgers

It isn't important to me whether or not you dismiss my statement although it seems very important to you but when I get a chance I will test 4 and 6 again.

 

There is one possibility in that I use Macintosh. Do you use Windows? There may be a difference in how Filemaker works on the two platforms. One reason to not be so certain of one's position.

Share this post


Link to post
Share on other sites
comment

My profile says which platform I use. Had I used another, I would have said so.

 

Please refrain from personal remarks. I said I have to dismiss the facts you have claimed to find, because the findings are not reproducible. That's one of the main principles of the scientific method. It has nothing to do with you. This is (still) a public resource of knowledge about Filemaker, and it should be kept accurate regarding the facts.

 

Again, if you can provide instructions for me to reproduce your results, I'll be happy to accept them. Note that "happy" is a figure of speech - I have no emotional investment here one way or another. If you think otherwise, I'm afraid you may be flattering yourself a bit too much.

Share this post


Link to post
Share on other sites
AHunter3

Another thing to keep in mind is that when you open an old FileMaker file in a text editor or word processor, yes you see data, but no you aren't obtaining direct access to the data as rows & columns. You'll also see fragments of boilerplate text (the kind of stuff that shows up when you go into Layout Mode with sample data showing) and paths to external files that have been referenced, and value list items.

 

Most of what you see, in fact, is going to be binary code represented as text characters, with clear text interspersed (this is from a FileMaker 4 file):

 

So I am sticking to my original thesis: that FileMaker stores, and has always stored, dates just as they say that they do, as serial number beginning with Jan 1, 1 A.D. with each subsequent day incrementing that by 1. What you see when you peel open an FmPro db with a text editor or word processor may show you conventional human-style dates, but that may just be a fragmentary recording of data as entered and does not represent the data as actually stored.

Share this post


Link to post
Share on other sites
Jack Rodgers
<..snip..>I said I have to dismiss the facts you have claimed to find, because the findings are not reproducible. That's one of the main principles of the scientific method.

Again, if you can provide instructions for me to reproduce your results, I'll be happy to accept them. Note that "happy" is a figure of speech - I have no emotional investment here one way or another. If you think otherwise, I'm afraid you may be flattering yourself a bit too much.

 

Perhaps you flatter yourself bit too much by thinking you have conducted a test via scientific methods? smiley-wink

 

You have only PARTLY conducted a test and then wrapped it in assumptions and remarks, far from being scientific.

 

I don't recall stating a version of Filemaker that I was referring too although my posts were made within a set forum which might have led to a false conclusion of the version.

 

You only tested two versions on your own hard drive (assumption) and only from either your files or froma new file you created. Hardly sufficient to test all possibilities.

 

First each numbered version of Filemaker usually has 3-4 revs, v1, v2, etc.

This would produce some 36 versions to test.

 

Next my tests were conducted on an older version of Filemaker before the problem was fixed and on the OS that the version shipped with.

 

So let's limit the testing to version 4 and earlier and on the OS and currenthardware that first shipped that and various updates on that equipment. That would be what 20 or so Filemaker version numbers and upgrades and maybe ten computers and 40 OS version upgrades. You would also have to check to see if I the specific model of Mac I used.

 

Next how does Filemaker response to the OS it is on. How much of the OS is doing the actual work and not Filemaker. So, if the OS changes maybe this problem changes also. Attention to this would be part of the scientific process. Did or does OS 9, 8, 7 , 6, 5, etc produce a different result than OS X 10.4?

 

Next, importing dates or setting the fields via scripting or calculated fields. How do these older versions (pre-six or 5) store those dates. These may be a source of what I found.

 

Next, how does the hardware used affect results? Remember when Intel and Microsoft had that embarrassing number problem a few years ago? Would conducting a test on a Powerbook with a 6800 processor (etc) and the proper OS and Filemaker version(s) produce different result. I have used about 20 different Macs beginning with a MacPlus until my Intel MacBook Pro and maybe 20 different versions and upgrades of Filemaker beginning with the very first one way back when. So, there is no way for me to be exact concerning the exact conditions where I encountered the stored on disk problem I described.

 

So, I would not want to borrow your phrase and say, "I must dismiss your conclusions as being incomplete and unscientific."

 

There is a thread ongoing to deals with eliminating duplicates. I have enjoyed a back and forth 'improve the code' discussion with a moderator there because there has been no personalization and no dominance struggle, just an attempt to find the ultimate truth. Quite enjoyable actually.

 

THE GOOD THINK IS THAT FILEMAKER HAS RESOLVED THE STORAGE PROBLEM and that regardless of how I enter the date manually in 8.5 it resolves to a four digit year in a newly created field.

 

HOWEVER: folks still using ancient versions of Filemaker are left with that problem. If their solution is locked they may have a serious problem if updating and so should only update and test thoroughly a copy. Perhaps not update at all since I have found my updated files that began in file breaking apart a little at a time due to changes which need script editing to select the window, etc. and even in the fields themself. Filemakers attempt to insert upgrade changes in calculations may work incorrectly.

Share this post


Link to post
Share on other sites
AHunter3
THE GOOD THINK IS THAT FILEMAKER HAS RESOLVED THE STORAGE PROBLEM and that regardless of how I enter the date manually in 8.5 it resolves to a four digit year in a newly created field

 

The good think is that this was true of Nashoba FileMaker 1.0 eons and eons ago as well. (Two-digit dates being an accepted shorthand for "20th Century", but assessed for validity and sort order as 20th century dates, not dates from )

 

And no it's not a "text field pretending to be a date field". See screen shot. Also, while it accepts data entry "2/30/2007", it resolves that to "March 2, 2007" when I click out of the field. And "2/30/2000" becomes "March 1, 2000".

 

It's ancient, it's a 1.0 release with severe limitations and bugs that include date handling, but I would consider it to be a "real date field", unlike the mainframe / pascal business systems that had the Y2K problem when the century was approaching.

Share this post


Link to post
Share on other sites
Jack Rodgers

Wow. What are you running Filemaker 0 on?

 

OK first question. If you enter 2/1/07 in today's application Filemaker will change that to 2/1/2007 immediate upon exiting the date field. This did not occur in several earlier generations of Filemaker. The date would be stored on disk as 2/1/07, which is what I repeatedly have said. However, Filemaker would glady reference this as 2/1/2007 using that crazy algorithm I have pointed to in the help file.

 

Create a new file with Filemaker Zero and enter a few dates in two diigit and four digit format. Quite. Open that file with a disk editor or word processor and see if you can locate those dates and report back.

 

First Question: what does a dialog picture prove about what is saved to disk? Note that it shows a 2 digit year. The proof would be a disk editor or word processor to open the file and peek.

 

If it isn't a text field pretending to be a date field, then why can you type 32,000 characters of text into it and I think in some versions have that saved to disk although newer version will not.

 

If it were a true date field you could only enter 1234567890 and your date delimiter, "." or "/". This would be true of those older 2 digit programs that whose entry fields were delimited to that string.

 

The real root topic is the data entry field which in Filemaker's case is a text field mimic so I call it a text field.

 

The program date mathematics is written in computer codes we would not understand so that can be set aside, as would be the language for Filemaker application.

 

The irony of it all is that personal computer applications store the entries in alpha-numerics for most all fields. I've seen some where the viewable results are non-alpha-numerics but that is different.

 

Underneath the alpha numbers and letters are of course the binaries which is far beyond this discussion.

 

On the surface our applications, whether Filemaker, Word or a disk editor convert those binaries into alphas and numerics in our chosen language.

Share this post


Link to post
Share on other sites
AHunter3
Wow. What are you running Filemaker 0 on?

 

vMac, emulating a Mac Plus, running System 6.0.8

 

OK first question. If you enter 2/1/07 in today's application Filemaker will change that to 2/1/2007 immediate upon exiting the date field. This did not occur in several earlier generations of Filemaker. The date would be stored on disk as 2/1/07, which is what I repeatedly have said.

 

You are correct, sir.

 

However, Filemaker would glady reference this as 2/1/2007 using that crazy algorithm I have pointed to in the help file.

 

Not as 2007 but rather as 1907. At least in the old versions. If you wanted 2007 you'd have to explicitly enter it. Likewise for 1807. In the in-between versions I think there was a transition period during which two-digit dates of a low enough value would be treated by default as 21st century dates during data entry (2/1/07 --> 2/1/2007) but still as 20th century dates during import (2/1/07 --> 2/1/1907). Note that in all cases this is not referring to storage, or how stored dates are treated, but as consequences of how the data was submitted to FileMaker Pro in the first place.

 

 

Create a new file with Filemaker Zero and enter a few dates in two diigit and four digit format. Quite. Open that file with a disk editor or word processor and see if you can locate those dates and report back.

 

gibberish, interspersed within which are the dates exactly as entered.

 

 

 

If it isn't a text field pretending to be a date field, then why can you type 32,000 characters of text into it

 

You can't. You can't enter "my pet kitty cat". You can't enter "hello world". Very early versions of FileMaker were buggy about letting you enter nonexistent dates (2/33/1655) but by the FileMaker Pro 2.1 era you can't do that. It will let you enter two-digit dates, and when you do it considers you to have meant a 20th century year ending on those two digits.

 

If it were a true date field you could only enter 1234567890 and your date delimiter, "." or "/".

 

That is indeed all that you are allowed to enter. Well, you have other delimiters you can use as well — FileMaker 2 will let you use dashes (2-14-1935) or backslashes (11\30\84), etc. Point is, you aren't getting anything into that field except characters FileMaker considers to be a date. It's not a text field. Perhaps you are misremembering and it was a FileMaker NUMBER field that you had in mind? FileMaker has traditionally allowed you to type all kinds of garbage into a number field, and then it ignores anything except the GetAsNumber() or the Boolean() of what's been put there. But not date fields. Date fields are date fields.

 

Underneath the alpha numbers and letters are of course the binaries which is far beyond this discussion.

 

Yeah, I don't know either. Maybe it's storing the dates in binary as serials (as Claris and then later Fm Inc always claimed), and simply also storing "how it was entered" in order to be faithful to the available formatting command "leave date formatted as entered". (mm?) But I don't know that for sure.

Share this post


Link to post
Share on other sites
Jack Rodgers
And no it's not a "text field pretending to be a date field". See screen shot. Also, while it accepts data entry "2/30/2007", it resolves that to "March 2, 2007" when I click out of the field. And "2/30/2000" becomes "March 1, 2000".

 

I think that March thing is a product of formatting applied to the date field object on a layout and not to the way the date is saved to disk. The formatting applied would simply be a visual affect for the benefit of the viewer and have no affect on how it is stored on disk.

 

Next, Filemaker has the only date field object that I have encountered that would allow entering 32-64 thousand bytes of data into it before stopping the user with a dialog after they wish to exit the field. Hence, my calling it a text field. Practically speaking refusing to save the text and insisting upon a proper date works, but how frustrating that is for a user who had typed the data expecting it to be saved in a memo field... smiley-surprised

 

My favorite date and number fields were in FoxBase, too bad the scripting was such a nightmare.

 

Imagine if you will 8 one character fields that auto tabbed after you enter the digit. Thus you type 01082007 and the cursor tabs to the next field with each character entered.

 

Oh my, I just created four one character fields to see if Filemaker would autotab, of course not. But it did accept as many characters as I want to type into that field and then gave me the dialog to over ride the developer's setting...etc.

 

Needless to say I am sitting here laughing at the silliness of this whole data entry situation offered up by Filemaker. Love most of the program but I find the field definitions almost idiotic. Why would I want to define a field for one character and then allow the user to enter 64,000? I think it is just an indication of patchwork programming and design gone awry. Of course they have to retain legacy information to keep selling upgrade boxes to legacy solutions and I have no problem with that...but how about a nice number or text field that I can truly set for one character and it will only accept one character without further ado.

Share this post


Link to post
Share on other sites



×
×
  • Create New...

Important Information

Terms of Use