KaosMaker

Hi folks, and thanks in advance! We're having trouble in 14 with our layouts, which mainly boils down to two issues: 1: Our dropdown/popup menus are way too small. They are always nearly half the size of the field font, which is not something we can easily remedy simply by doubling our field font size. Is there any way to change that? 2: Scrolling up and down glitches the layout terribly. Using the scroll bar buttons doesn't, actually, but clicking directly on the bar, or dragging on the bar, will almost invariably glitch the layout, creating lines and jumbling objects until we scroll back off and scroll back on with the buttons. Any advice? We're all using Win8.1 (sigh) and FMPA 14. Thanks again, K

Simple problem here: I have two different Filemaker servers. On one file of Server A, I am trying to run a script via PHP, on a layout with all the fields that are at all referenced. At one point, I am trying to set a field with the contents of another, related field, in a file on Server B. Both files have PHP permissions enabled, with the same username and password (verified and tested), but I can't seem to access the field from Server B, while running php on Server A. The relationship and script works fine on the client. Is there some sort of networking permission I need to set to allow Server A and Server B to talk to each other with php? They talk together just fine in Filemaker. They are also on the same network, for that matter (and yes, there are reasons for having two separate servers hosting our different solution files). Thanks in advance!

If you need a workaround immediately, a less than desirable but functional solution is to trigger the script via On Object Enter script trigger, on a field in your portal. So the focus enters your portal row FIRST, then triggers the script, instead of the other way around which appears to currently be the case. Ideally this would be done on a calculated field or somesuch so that your users can't edit it, but can still enter it (to trigger the script).

My suggestion would be to download an English Word List (there are many online, search to your own content and find one you like) that lists its words in a simple list, with no definitions or other values on each line. Then import those words into a new table (i.e. Wordlist) on your database, and create a relationship of YourTable::GlobalTag to Wordlist::Word. For each word, if IsValid(Wordlist::Word), then you have a match! The problem with this approach is that you'd still have to loop through all 20,000 words in your document and set them to a global, then check the relationship. Totally automated, and much faster than the web, but still not exactly speedy. If this is ok with you, though, give it a try. Edit: Alternatively, upon rereading your post, it seems you might be converting your PDFs into a list of words already. If that is the case, then simply make a relationship between YourTable::File_Converted_To_Text and Wordlist::Word, then apply List(Wordlist::Word) to get a list of all the valid tag words. That should be much faster!

Yes, basically what seems to be happening in a popover is that whatever button you have in a portal triggers BEFORE entering the portal row. The only workaround we've discovered is to use an On Object Enter script trigger on our portal row. For example, you click in a field in our portal, which enters the related record, and THEN triggers the desired script from the context of that portal row. This is not ideal for every circumstance, but it works well enough for ours. Seeing as this is likely just a prioritization bug, I think it will probably be fixed in 13v2 or whatever. [Edited for grammar]

If I'm interpreting this right, Rick has the right idea. The question, then, becomes: how does one "perform a search" (not a real find) within a found set, and go to that record? One quick and dirty way: 1) If you are always going to be searching in one field, place a global in the header, and a button with it (if you need to search different fields, make a second global with a drop down list of your fields, so you can select which field you want to "search" in). 2) Enter your criteria into the global, then press the button. 3) Have the button perform a looping script that loops through your found set and stops when it finds a Patterncount match of your criteria in the specified field. Is that what you want? The downside is that if you have multiple matches, you'll stop on the first one, but there are ways around that, if you like.

In that field definition, you are calling a Value List. Did you actually create a Value List called zz_Groups in File->Manage->Value Lists? If you did, be sure to put it in quotes ("zz_Groups"), since otherwise you are not passing the name of the Value List, but instead the contents of zz_Groups, which is not what it is looking for. ValueListItems requires the *name* of an already created Value List, created through the menu I mentioned above. The easiest way to do this is to: 1) Create a global field in Contacts, say, gGroup, and make a relationship between Contacts::gGroup and Contacts2::zz_Groups (or whatever you want to name your second table occurrence). 2) Create a Value List based on Contacts2::NAME (or whatever you've called it). We'll call it ContactsInGroup 3) Place Contacts::gGroup on your layout, with your already existing Value List (the one you used to make your checklist) populating a drop down menu. 4) Lastly, place whatever field you want to drop your NAME field into (I'm not sure what you're using it for) on your layout, with the ContactsInGroup value list populating a drop down menu. Now, to view any complete list of contacts in a group, simply use the gGroup field to select which group you want to see, and the value list in the second field will update accordingly! (oops, LaRetta responded before me, but now you get the same answer two different ways!) edit: man, I am really slow...hehe

The contents of the field are, in fact, your checked items. Let's say you have friend, professional, and personal checked off. The actual contents of your field would be: Friend Professional Personal All separated by carriage returns. If you want to check for specific values, you can use a Patterncount for each value. Patterncount(Contacts::zz_Groups; "friend") will return a 1 if they checked off friend, and a 0 if not. You'll have to do this for each value you want to check for.

I'm not sure why it would reset your check boxes. Your "tags" are in a value list, right? Say, a value list of "Agent, Actor, Janitor"? If you simply add a value to that value list, you should just have a longer list, like "Agent, Actor, Janitor, Elephant Repair Man". You might have to expand your checkbox field on the layout to accommodate the new value, but it shouldn't reset any of your actual data. What you might be thinking of, however, is that if you *change* a value in your existing list, such as "Actress" to "Actor", it will indeed appear to reset your checkboxes. Technically, that value will still be in the field, you just won't see it. As an example, let's say I have only two values, Agent and Actress. I decide to change the value list to Agent and Actor. If I have a record that previously had Agent and Actress checked off, the field itself (if you opened it as an edit box) would still contain Agent and Actress, but the checkboxes would have Agent checked, and Actor unchecked. If you instead merely added a third option, without changing the spelling of the previous two, the checked values in your records should not change.

Don't worry, you explained it just fine! In Find mode, what you want to do is create two Requests (Control-N, or the menu Requests -> Add New Request): 1) Find Agents AND West Coast 2) Find Actors AND West Coast Then Perform the Find. This can also be scripted (press New... in the Perform Find script step) That should do it! New Requests in a Find are treated like OR statements, or essentially two different queries combined into one. Note that you can also choose to "omit" a find request, in case you, say, wanted to find all Agents on the West Coast that were NOT Actors. Good luck, and welcome to Filemaker!

It seems like what you want is an Events table, related to your contact by a primary key. They can be viewed by portal, and even searched via portal (portal searches by definition take longer, but if you don't have truly stupendous amounts of data, it should be acceptable). This way, you can create a new Events record for each time you contact them. For example, from what you described above, to start with you'd need five fields in your Events table: Contact Key (the primary key of your Contact table, or whatever it's called), Contact Type (as you described above), Date, Time, Notes. You can create a portal that allows you to create new records, OR you can create a new related record via script. As for the search example you provided, you could perform a search in the portal Date field that omits records where Date > [2 months ago] The way portal searches work, if you have a record with three Events in it, and even one of them has a Date > [2 months ago], the entire Contacts record will be omitted from the search result. Don't try to search the other way (Date < [2 months ago]), because it will return any and all Contact records with an old Event record in the portal. I hope that makes sense, please don't hesitate to ask any more questions! Good luck!

Do you have any problems accessing the WD home page, that lists the servers? Or is it just accessing the databases themselves? Then again, perhaps this is an "IE on Mac OS" issue. I've never tried it on a mac. Have you tried it from a Windows machine?

It works for me, though with some notable glitches (mostly dropdown or popup menu interfaces, or more esoteric stuff like WD in a frame on a different domain causing refresh errors). I've never had it hang the browser completely, though with my frame adventures I'd sometimes have it fail to properly load.

You, sir, are a genius. I had seen that iwp_home.html file before, on my frustrated searches of the entire FileMaker Server directory, but frankly passed it off as some sort of legacy relic from IWP. This is just what we needed, thank you! Now we can actually move forward with the transition! As a side note, at least in Chrome, it does tend to flash the old page at me briefly, including a strange, bright red "Communications Error" message at the top, but only for a moment, before redirecting correctly. I am ok with this, since users will only see it on the way out, and therefore probably won't be scared off. Thank you again!

HazMatt, that's pretty much the only way I've found to do it, as well. In my post above, I do describe a way you can dynamically access the current Record Number for a given parameter, but it uses CWP. It's a pretty simple PHP page, but still, it may not meet your needs. As for dynamic values, there is a way, but it also uses CWP. Have the URL pass a parameter to a PHP page, which in turn uses CWP to add a record to a Parameters table, setting the Parameter field (or whatever you want to call it if Parameters::Parameter is too tacky) to the parameter you passed in. Have it return the record number to the PHP page, and then access THAT record number via the WebDirect URL. Example: www.website.com/page.php?x=314159265359 will create a new record in the Parameters table, setting the data field to 314159265259, and returning record number 1123 (since it is the 1123rd record created since the last purge). Then your PHP page directs you to www.website.com/fmi/webd#Parameters&lay=Load&viewstyle=form&record=1123&mode=browse Of course, then your OnRecordLoad script fires and proceeds however you desire. Just a reminder that your OnRecordLoad script should exempt record number 1, since it ALWAYS loads that first. It seems that's what you're doing in your example, but I just wanted to remind others who might not realize. Thanks for digging further into this, and good luck with the adventure that is WebDirect!