metroart

I tried TheTominator's workaround for Win XP: dialog = new FileDialog((Frame)null, title); Sorry, but it doesn't work for me. I'm using FM 10 Advanced on Win XP SP3 and as far as I can tell, even with the workaround, ALL of the modal dialog functions like SelectFile or FormattedDialogWithDynamicButtons just crash FM if the user clicks on the FM app anywhere outside the modal dialogs. The program just freezes. Scriptmaster seems like a pretty cool idea, and apparently work fines on a Mac, but these guys don't seem to be doing much testing on Windows machines. Too bad.

Anyone have SM code to modify SelectFile so that a parameter can be be passed with a folder path, so that the file dialog opens that folder rather than whatever the previous path was?

I've put a Windows Filemaker 7 database on our Linux server, so the database can be accessed remotely via VPN. The database will open, but only as a read-only file, no matter what the account or password. Is there some way I can get the file to be writeable on the server, or do I have to move it to a Windows client? -- in which case I can't access the file remotely via VPN. Any suggestions? Bob

Juat one thing about the script for fp7: the Get function CurrentPage is now PageNumber.

Yes, it's all stand-alone stuff, so I bought the upgrade to 7. And yes, it's a b**ch. To get it to work, you have to study the layouts, scripts and relationship graphs for the sample template that matches your app the closest -- you're on your own -- none of these are commented -- then read all the gory details in the onscreen Help file (the printed users guide is just an overview). And even then, all sorts of stuff still doesn't work like I thought it would/should -- e.g. one of my portals doesn't show any data from the related records and the portal that does show data won't summarize the fields, even after I construct summary fields exactly as described in the Help file for "Summarizing data in portals". BUMMER...

>>Art, it seems like it's going to be more trouble for you to try to maintain this all in one file than to do the eventual migration to 7. J: I can't maintain this all in *one* fp5 file. I *could* maintain it all in 3 related fp5 files. But if I want to migrate to fp7 (and I do), then it's evidently easier to start over from scratch in fp7 (whether one wants one big file or many smaller ones) than try to convert multiple related fp5 files to multiple fp7 files. THAT is what is more trouble -- at least from what I can tell from the conversion pdf on Filemaker's website -- and from the review of fp7 in the latest issue of PC Magazine.

What's wrong with multiple files? For one thing, it's a lot easier to lose or misplace 1 file from a set of many - or get them confused with similar files in other sets or backups. The people who are using this database are volunteers in a non-profit org. They're not like paid employees -- the're poorly trained and often careless. The database (and especially how to restore backups) needs to be kept as simple as possible. An even more important reason for not using multiple files with FP6 is that it will only make it harder to migrate to 7. From what I've seen about the conversion process, if you use multiple files in FP6, you can forget about trying to port everything over to 7 -- it'll be easier to just start over from scratch and import all the data at a later point.

Yes, that makes sense. I guess I've exhausted the limits of working with a flat database and have to move up to relational Filemaker 7 (to keep it all in 1 file, instead of 6's multiple files). Thanks for the advice.

Why separate fields? Each program people register for needs separate fields for things like price, member discount, whether they're staffing, if they're paying with cash/credit/check or using work/study credits, whether they're attending Sat. or Sun. or both days, etc. During the year, a person in the database might take 1, 2 or more of these programs. All this info needs to be tracked in a single database.

I'm using Filemaker 6 to develop an automated registration system for a non-profit org. They need to register people 6 months in advance for 30 different programs simultaneously, so they need 30 different sets of forms, each with about 20 automated scripts linked to various buttons on the forms. Developing a master template has not been a problem. But cloning the template is another matter. To make a copy of the master template, complete with a new set of fields/layouts/scripts is a real pain