Jump to content


  • Content Count

  • Joined

  • Last visited

Community Reputation

0 Neutral

About FMDuck

  • Rank

Profile Information

  • Gender
    Not Telling

Contact Methods

  • Skype

FileMaker Experience

  • Skill Level
  • FM Application

Platform Environment

  • OS Platform
  • OS Version
    Win 8.1, 10

FileMaker Partner

  • Certification
  • Membership
    FileMaker TechNet
    FileMaker Business Alliance

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. @Beverly - I see what you mean about the indent. It seems like FMI could make the left padding match the field's when the labels are placed above. @Josh - I'm so used to seeing the smaller, bold label that I forgot it won't be that way anymore. Still though, there was an issue with the Field Picker not aligning the labels with the fields so they all had to be adjusted up or down. But then I realized the labels are always center aligned and the fields are top aligned (by default) so some consistent padding and alignment will fix that too. @OW (good to see your hairy smiling face!) I'll probably end up with some layout on WD so I'm more comfortable using the padding. I also found that by keeping the vertical padding, it can be easier to set the desired height since when sizing them with the mouse.
  2. Sorry for the two-part question but they seem to go together... I'm starting to rewrite my FMP5.5 to FMP11 UI. I'm graphically challenged so with the intention of making use of the larger displays, I'm looking closely at what some of the industry leaders have put out. So far, every FM Theme sample or product, or example that I've run across for single-line fields, field labels, or buttons use both padding and alignment when it seems that having only padding or alignment on 3 of the 4 sides is necessary and would be more useful. For example: 12pt Left-center aligned text 22pt high x 200 wide field Padding of 2,7,2,7 The left padding of 7 (or whatever) seems useful but since FileMaker doesn't limit the length of a text field, adding padding on the top, right, and bottom seem to potentially limit a user's awareness that there's more in the field. In another example: 12pt center-center aligned number 22pt high x 40 wide field Padding of 2,7,2,7 In this case the left and right padding results in 2 digits being cut off (3 visible vs 5 without padding). In both examples the top and bottom padding seem unnecessary and in some cases can result in fonts being cutoff. Is there a reason for padding all around, or is theme creation easier, or just people's CSS habits? ---------------------------------------- The other question - Creating new field instances still result in one size for the field font and a smaller size bold font for the label. Again, looking around online, I don't see anyone keeping this big field/small bold label result. It seems that years ago this could have made sense to draw attention to where the field is but now, there are too many other things on the screen. Does anyone know if there's a current philosophy behind this or maybe has it just never changed in FMP?
  3. Jeff - I'm not sure this is the right place to post this because your question doesn't really relate to the unique requirements of creating a shrink-wrap solution. I looked at your file and I think it looks good. It does look like a great start. I like how it works. A next step I would consider would be to assign and limit access by user type then maybe consider related notes that can be added to each task (assuming you want to go further in that direction.) Hope it goes well for you.
  4. Hi Doug - Thanks much for the feedback. I saw that too but it was before I realized I had this problem and I already forgot about it. I probably have 50 to 100 occurrences of the evaluate function that these fields each depend on. Looking at the article again - in light of my question - made me think about my custom functions and I found that there's one cf I have that includes a variable that wasn't populated during import and *that* was my problem. I got there indirectly but this gave me a kick in the brain cells and looking in the right direction. Thanks again!
  5. When importing data to matching fields, I have three unstored calculation numeric fields that are displaying '?' and all downstream dependent fields do also. I have a solution that was originally developed in .FP6. I skipped FMP12 and moved it from FMP11 straight to FMP13 with no data problems during migration. It has about 25 tables and this one particular table has over 2000 fields of every type. The solution has recently been migrated from FP7 format to FMP12 with no problems. Now, that data is being moved from one FMP12 file to another via a matching field import. The fields are storable, unstored numeric calculations. I've tried storing them and tried various indexes when stored but no matter what, the fields result in a question mark. This is only happening on three fields. Just as unusual, after the Import script step, I added a Commit, then a Replace script step to a field that is referenced in the calc field. I'm replacing the field with itself. This results in a zero value. If I do this manually or by a script step after the import, it updates the field normally and the field(s) with the '?' display the value they're supposed to. Also, after the import, I can click in-and-out of a referenced field and that will fix the problem. I fear this is a bug in FMP13 and/or it's related to the depth of FMPs calculations as these fields are deep in dependencies. I'm hoping that by now someone would have seen this. Any ideas? Thanks in advance for any help.
  6. In the interface, you'll still use field names but under the hood, FMP matches the field IDs so if a name is changed, the mapping is retained.
  7. Thanks Dan, I think it is RefreshFM that I saw. It looked good and in retrospect it may have been easier for me to get and modify it. At some point, field names will likely need to be changed. I think that's not supposed to be an issue since FMP now uses the Field ID for import field mapping. I guess that change takes care of my problems. It just seems too simple now Thanks again.
  8. I have a shrinkwrap solution with a separate installer/updater file. That file contains the scripts that creates a temporary file of each of the old and the new FMP file, performs an import into the new file then compares the results and continues. When I prepare the installer, I need to have a copy of each of the old and new FMP files so the updater file can map the fields that are used in the temp files. The purpose of the structure is so I don't have to remap the fields or check the field mapping each time I do an update. Someone else has written this for me and I've generally still only used FMP 11. I understand that FMP 13 maintains field mapping by the field ID rather than the field name. Also, this seems very familiar and I'm pretty sure someone has written and sells something like this - I can't remember who though. There's an assumption that all the tables exist and fields will only be added and not deleted to new files over time. The files have an internal BuildID that's used to track revisions. The person who wrote this for me has said I don't need to be concerned with the version of the 'old' file and to simply always provide the first version of the solution. The field mapping will always be correct. I can't think of a specific situation when this won't work, but it doesn't seem to make sense. I feel like I'm just not thinking clearly and missing something but I would think that a specific old version of the file would have to be provided. It seems that I would need a separate script (or some sort of branching) for each 'old' build of the file to assure the mapping is correct. Does anyone have any thoughts as to what could go wrong here? I do a variety of validation after the export but since admin privs are removed from all the files it's very difficult to check everything for a possible field mapping error. Thanks much!
  9. Thanks for the info. I know I'm slow to respond - I guess I missed your reply. I have everything working pretty well for the current software release but will look at your software more closely before working on the next release. I looked through the website and it looks like it could be the solution to some pretty complex licensing problems. I look forward to being able to go through it in depth. Thanks again!
  10. What no_access posted is another part of my security and it's also real easy. Sorry for the cut-and-paste screen shot rather than a file (I have a lot I'd have to clean out of the file to post it) but here's part of a code generator that I use that create the a code for the solution. One set of fields goes into a custom function in the solution and the other goes into my decoder. and a matching one for my decoder. The number which is the base of the code can come from the NIC, a date, license qty, whatever. Set the custom function Availability to Only accounts with full access to keep it hidden. Note that FileMaker has a 164 pair limit in the Case function. License Control Module.pdf LCM Result.pdf LCM cf in the solution.pdf
  11. I have two solutions that I sell. It's kind of one solution that changes drastically from version to version because of the small size of the industry that it supports. One 'solution' has up to about 25 users per installation and the other is single-user stand-alone. I've had them for about 25 years. The first time I developed the smaller runtime solution, I had it pretty well open. I did add the customer's name to the screens with a warning. The piracy to sales ratio was about 75/25 so I got paid for about 1 in 4 copies. The first thing to consider though is that many of the people who will make illegal copies may not purchase it anyway so your loses aren't really that high but of course you really don't have any way to know exactly how many people use illegal copies or how many people would have purchased it so you can only guess. Possibly consider releasing the first version without some key features and let it get out there. Once people start using the software they become used to it and their employees could get very comfortable with it. Then in the next release include the features that were left out and then include the tighter controls so once they install it, they can see the new features but will have to purchase the new version. I mentioned that I have the big and small versions because in the big version I have MANY controls but I don't have a phone home feature because of military restrictions. I use Ray Cologon's CreateUID cf set which is free. It binds to the NICs, timestamp and record ID and works very well for me. I also have a grace period for activation and if the solution is moved, the grace period starts over again. This way not only does the user have the chance to move it to a new computer but if they share it with someone, that person can start using it just like a demo but it will expire. No data can be exported until it's activated. An issue with this is that it assumes that the historical data is of value and the grace period really doesn't work if the person doesn't care about maintaining data. I also use Ray's DataVaultMaker and have a key based on multiple fields so the NIC is only part of it but that's in the big solution. Because FMP captures all the NICs, you're safe no matter if the user turns on wireless or not. You can check to see if any one NIC matches what you've stored and if so, recapture all of them in case one has gone out or they're running from a server and swapping NICs or something else. This isn't fool proof and isn't great for a server but it sounds like it would cover almost every NIC based control. You could also write to the registry on Windows or add a hidden file somewhere but my experience is that I want to keep it simple enough that I can have a non-technical person support installation problems. There really is much more to consider but hopefully this gives you a starting point. I have a honkin' long post here that goes a bit more in depth. HTH
  12. K1200, you're profile says you're still using FMP11 so this applies to 11. I don't know how 12 will react. You don't need to change any settings, i.e. your External Data Sources (EDS). This is something that I've had to deal with on my own with a pseudo-DSM solution. Even if you decide that you want to go so far as to close both files then re-open them, the EDS should be set-it-and-forget-it. I've gotten a bit confused by the thread (but it wouldn't be the first time I've been confused - and it is me) so I'll back up and restate this a bit. K1200, you're correct about where you are entering the two files. You may want to consider using a relative path that assumes the testing file and an absolute path that assumes a live file. I put the relative path first such as: file:myDataFile.fp7 file:C:/RealData/myDataFile.fp7 If you're looking at providing users with a real file and a play file this assures that if any accidents happen, it's more likely to happen in the play file. I'm also guessing here that you have already renamed your development files as Vaughn mentioned, and these two files are both deployed as customer files. LaRetta's right about the way FM says it works and what would make sense but almost always, the data file does not actually close. I've had times when I was actually been able to close and reopen the file but I have no clue what the conditions are. Going to a completely blank unrelated layout doesn't work. You will get an error. The key to the trick is knowing that the references in your UI file will go to an open file before it goes to the list as shown above. If either of the two files is already open, the UI file will use it. So if you open the desired data file first, the UI file will use the one that's open. Depending on if your paths are known, you can run a script FROM the data file that first closes the UI file, the closes the data file. This will assure both files get closed when the user closes your solution. The problem with doing this is that you're now creating an association to the UI and if the UI gets moved, the user will get an error that you can't trap for. If you want to leave the impression that the solution itself never closed, you will need a third, launcher file so it can close the data file then close the UI file. This is counter intuitive and isn't made clear in any of the FM documentation I've found. I went round-and-round trying to get this to work the way I wanted and finally gave up after my forehead was swollen from banging it against the wall.
  13. The only way that I've found to do this is to reverse the process. If you use a launcher file it can open either data file first and then the UI. Once the data file is open the UI will use that file so long as it's in the valid EDS path for the UI file. The launcher file can reference the two desired paths of the data files. Since it's already open it forces the UI to use it. This will keep you from having to move and rename files. If the location of the UI file is known, you can use the laucher file to appear as if the application stays open and have it reopen the UI after the data file, otherwise I think you'ld need a plug-in.
  14. Thanks much. I think I am going to start breaking it apart and see if I can get some idea of any substantial decrease in speed.
  15. Thanks Vaughan, My concern is with the solution slowing down after separation. I don't expect to get it any faster. I'll likely go forward and separate some of my tables that contain metadata into separate files to allow my to update those by simply sending out a new file. I expect I'll also separated my graphics table into it's own file and create another file for user's container fields. Short of some solid testing of the separation model, I think this model will give me the best ability to recover from corruption and speed up updates by avoiding updating any graphics. I guess this is a pseudo-separation. Thanks again
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.