charper

I've got a runtime filemaker app that was built using Filemake Developer 4.0 on a Mac. It was designed to run successfully on both Macs and Windows in general and it does....at least it does for every version of windows its been tested on. My question is: Will this app run ok under Windows XP? Are there any XP/Filemaker/runtime specific issues at all?

The good news is I found out what the problem was. The Send Mail command was failing because the message string (which is coming from a calculated field I build on the fly) was too darn big. Apparently there's a limit to length of this string: 500-600? 512? When the message exceed this limit, the Send Mail command can't open Hotmail. The bad news is that I HAVE to exceed this limit. The string needs to be 3 or 4 times larger than this in some cases. And you can only specify ONE text field for the Send Mail message parameter. So now what? Filemaker seems hell bent on not letting you send useful report information via email. (No, I don't want to do the PDF thing).

I've got a script I run from different layouts that does nothing but execute a Send Mail command. If I run the script from any layout other than one particular layout it works fine - mail system launches (I'm using Hotmail). But if I execute the script from this one particular layout a browser window opens and displays the standard "This Page Cannot be Displayed Message". The crazy thing is that this worked fine before I went in and edited the Send Mail settings which I have since reset to their original values. Any ideas on how to get this craziness to stop? I don't even care anymore about WHY its happening. I just really need the problem to go away.

Hmmm. That's actually a pretty brilliant theory for a "beginner". I wasn't aware that field definition order had any baring on imports at all. That's rather precarious if that's true. At any rate, I'm absolutely positive that I was not in the field defintions dialog on either machine during this test - it was a carefully controlled test. However, I wonder if its possible that the field definitions got resorted automatically somehow as an unintented result of the procedure I described above. Very interesting. I won't get to check Computer B until tomorrow but that'll be the first thing I look at when I get there, you can count on that. Thank you Laretta. As for the email theory, that does sound a little hard to swallow. If email was gonna hose up my database attachment then how could it selectively effect only my import scripts? Doesn't seem likely. But I'll give the zip file thing a shot if nothing else works. Of course if worse comes to worse I can always go into all 30 effected scripts on Computer B and reset the field orders for hundreds of fields (if they are indeed out of order which appears to be the case). Please God, don't make do that.

I've got an import script that seems to be screwing up. Here's the scenario: I've got Filemaker 5.5 installed on two different computers: Computer A and Computer B. I've got a database I've built on Computer A that has a script which imports order records from a text file in a folder on my desktop: Orders.txt. On Computer A, this script works perfectly fine. I've emailed both the database and Orders.txt to a hotmail account as attachments. I've downloaded both the database and Orders.txt from this account into a folder on the desktop of Computer B. When I open this database on Computer B and run the import script, the import fails - the right data gets imported into the WRONG fields. Did something wierd happen to the database when it got emailed and downloaded to Computer B? It looks ok on Computer B - cosmetically. And the data that's already in it appears to be perfectly intact also. Seems to me that this import should work perfectly fine on Computer B. I've checked file sizes and date stamps and have verified that there is no other file called "orders.txt" on Computer B. And I've even opened up the import script on Computer B and made sure that the import command was pointing at Orders.txt on Computer B. The only thing I haven't done yet is step through the import script one step at a time to see where its getting things hosed up on Computer B. I'll be doing that tomorrow (as a house call) on Computer B if I don't come accross the answer before - really wish I didn't have to do that. A cyber beer for whoever can clear this up for me. I'll be losing sleep tonight.

To continue from my previous reply (if I haven't confused you yet) This solution, as I've described it above, makes sense only if we're dealing with just ONE set of 50 toggle fields. Assuming that we are NOT (i.e. you need these 50 fields for multiple records) I have a simular but more advanced solution for that also. Its a little involved and perhaps not much more elegant than just having 50 seperate toggle scripts, but it will give you the desired behavior across multiple records without a bunch of little redundant scripts. Just give the word and I'll either describe it here or email it to you.

I have a solution for you but it may involve reconsidering your overall app design. Instead of having 50 different fields equal to X or O, you create a another file (call it fileXO) that has 50 records with one field (call it fieldXO) in each record equal to X or O. Then, in your master file, create a portal that displays fieldXO from all 50 records in fileXO (one in each portal row). Now make fieldXO activate a script that checks the value of fieldXO and toggles it accordingly. I just tried this myself. It took about 10 minutes and it exhibits the behavior you've described. It may upset your current design but it is rather elegant in that it uses only one 5 line script and 1 field instead of 50. Furthermore this solution can be tailored to accomodate ANY situation where you want multiple buttons activating one script that routes itself according to which button was clicked - something I've seen other developers asking for but usually walking away empty handed. I hope you can make use of this. Please let me know if you have any questions. I'll chekc back here later.

The desired capability: To have portal records resorted by clicking on portal column headers. I've already implemented my own solution. The reason I'm posting this is because I'm confused by all the solutions to this problem I'm seeing out there in Filemaker land. I haven't seen anything as elegant as what I've done and I'm just wondering why some of the solutions I've seen are so complex and bulky. My solution: 1) Create a field called 'portal sort number' in the file that your portal looks into. 2) Define your portal to sort on 'portal sort number'. 3) Attach portal header text for column X to a script that sorts your file on field X then loops through all the records in the file setting 'portal sort number' to status(CurrentRecordNumber). That's it. Click on column X and your portal resorts on field X. I've seen scripts 100 lines long for accomplishing exactly the same thing. Am I missing out on something? What I REALLY wanted to do was just have 'portal sort number' be a calculation field set equal to Status(CurrentRecordNumber). Then even the looping script would be uneccesary. Alas, this doesn't work - not quite clear on why it doesn't work. Better yet, wouldn't it have been nice if they made the special Record Number field available for portal sorting. Then you wouldn't even need the 'portal sort number' field at all.

Thanks for the replies. But since I posted this question earlier today, I've read complaints about: 1) Sounds in FM solutions developed on MACs not playing back in Windows 2) Runtime solutions bound on a PC not running correctly (or at all) on Macs. 3) Movies in runtime solutions bound on a Mac not playing back in Windows. Is there nothing to these complaints? User error? I'm also hearing that, for reliable cross platform compatibility, you need to do two seperate bindings of your solution - one on a PC and one on a MAC - then incorporate both builds into your installation software which will choose (or allow the end user to choose) the approriate version. Just to make sure my question is clear: I'm building a multimedia heavy solution. If I build it, bind it with Developer, and burn it to a CD all from within Windows, will it run ok on when installed by an end user on a MAC? Same question for going from MAC to PC.

I need to decide whether the FM application I'm going to build should be built on a PC or a Mac - I have the option of both. I also need to decide whether to use Developer 4.0 or upgrade to Developer 5.5. The application will be multimedia heavy i.e. lots of full screen graphics, sounds, voice recordings, and probably some movies in various formats. My concern is mostly with cross platform capatibility. 1) Will a multimedia heavy FM application built on a PC using FM Developer 4.0 run ok on a Mac. 2) Will a multimedia heavy FM application built on a Mac using FM Developer 4.0 run ok on a PC. 3) Will a multimedia heavy FM application built on a PC using FM Developer 5.5 run ok on a Mac. 4) Will a multimedia heavy FM application built on a Mac using FM Developer 5.5 run ok on a PC. My instinct tells me that these issues are ripe with Murphy's Law. Would I be right? I'm strongly inclined to just run some tests of my own to see how well these different combinations work with the various peices of multimedia, but I'd rather not have to purchase the FM 5.5 Developer upgrade just to discover that there's some crossplatform issues with it regarding multimedia. Other info: This application will probably never need to run on a network but we may want to turn it into an internet app at some point. Last year when I was researching FM internet database publishing I became aware of some issues with FM 5.0 that were somewhat dissheartening e.g. Wouldn't work well with Lasso (if at all). There were clearly some advantages to sticking with 4.0, 4.1, etc. when it came to internet publishing. Would really appreciate some advice in these areas. Once this platform issue and FM Developer version issue are resolved I can actually begin the development proper.

In a nutshell, my basic question is: Can movies and sounds be activated in a filemaker app by a script? As far as I can tell, both filemaker 4.1 and 5.0 (the two versions I currently have) force the user to click a play button on inserted movies and double click on container fields to hear sounds, music, etc. I ask beacause I have an application I want to build that will require Filemaker to behave sort of like an electronic story book where videos and sounds are activated automatically simply as a result of the user "turning a page" i.e. clicking a button or link. I'll be building this with either Developer 4.0 or 5.5 and deploying it as a runtime, duty free app, but I'm not sure yet if I'm going to build it on a Mac or in Windows. What issues will I encounter here? Ideally I'd like to be able to build this in Developer 4.0 on a Mac. Can I get the desired behavior this way? AND will there be any crossplatform issues with multimedia playback when the final app is run under windows?

1) Other Remote Access Solutions: What other remote access solutions are available for Filemaker besides Web Companion, FM Server, and Lasso (For FM 4.1 and 5.x)? How do these other solutions compare in terms of cost, number of simultaneous users, security, and fidelity? 2) Publishing Reports: I’ve experimenting with Instant Web Publishing in 4.1 and 5.5. The fidelity of 5.5’s web pages are impressive except for the fact that they show only the BODY part of my filemaker layouts. Where’s the headers, footers, subsummaries, etc.? Does this mean that I can’t use instant web publishing to publish reports? I’ve got reports that have no body at all because they rely completely on subsummary fields. Can I get around this limitation of instant web publishing by using CUSTOM web publishing? 3) Record Level Security I’ve read that Custom Web Publishing allows you to control what records a user sees based on the contents of certain fields. This means you have “Record Level Security” with Custom Web Publishing i.e. certain users can see only certain records. Is this correct? And this level of security is not available with Instant Web Publishing? Is this correct also? What I’d really like to know is, does FM Server (3.0 – 5.5) provide record level security? 4) Custom Web Publishing What’s the difference between Custom Web Publishing with 4.1 and Custom Web Publishing with 5.5? 5) Running Scripts with Web Companion I notice that Instant Web Publishing with 5.5, although it shows me exact replicas of my filemaker data entry layouts, will not respond to layout buttons that are attached to scripts. Is there a way around this? Do I have to go to Custom Web Publishing in order to have remote scripting capabilities? What about 4.1? Same deal?

That works!!! Thank you very much!! Awesome.

I'm sorry, I guess I'm not being clear. I'm well aware of these availability of these statistical summary functions. In fact I use them very heavily in the project in question. Let me start from scratch: I have a "Sum Total Of" summary field in a subsummary part of my report that breaks on field X. When the report is generated in preview mode, I see the summary field displayed in each break and with a different value in each break just as expected. What I NEED now is the Average, Mininum, and Maximum of the values diaplyed in this one summary field, and then I'd like to display these stats in the Grand Summary (or somewhere at the end of the report). My first inclination would be to try to define a NEW summary field that operates on my CURRENT summary field described above. Alas, when you go to the summary field definition dialog you'll see that the summary fields you have already defined are not selectable. Drats!! In short, I need to do summary calculations on summary fields. THAT'S the problem. Sorry for the confusion. Any ideas on how to do this?

Got a problem. I need to be able to perform statistical calculations (Min, Max, and Average) on data that appears in summary fields. This doesn’t appear to be possible in FM. It appears I’ll have to write a script that does these computations from scratch by examining the record data that supports the summary fields - yuck, and I do mean YUCK. I can give more detailed information here if need be, but I’d like to get your general comments on this first.