My version 7 Observations ... the next day.

[jscooper]

Well, now that I've had a night to sleep on it, here are my thoughts:

I have to say I LOVE being able to pass parameters to scripts ... that'll save freakish amounts of time. Also, having more control over windows is great ... as are many of the new functions, though the usefulness of some I'm sure will not occur to me for some time. Now, on to the whining ... (will we NEVER be satisfied?? .. hehe .. no).

- Portals. Still only work vertically (a horizontal or grid portal woule eliminate a lot of workarounds). Also, why has it not occured to anyone at FileMaker that just because you click somewhere else on a layout does NOT mean you want to scroll to the top of the portal! Leave the portal scroll position where it is! People like to scroll, not click buttons that LOOK like scrollbars just so they can continue to see what they want.

- I would really like to be able to dynamically specify target fields (including repetition #s), files and scripts. In my experience, the less hard-coding you have to do, the more time you save down the road. And say what you want about repeating fields, but if they just add a way to quickly (i.e. without workarounds for a bunch o' scripting) specify a field/repetition as the target field for Set Field[], it would be like having a global array .. without having to mess around with other tables., copying IDs all over the place, extra script steps, etc.

- Local variables. Again, do-able with workarounds and scripting, but being able to declare a variable name/global field that's trashed once the script exits, and that exists only in the context of the script, (though the aforementioned parameter passing will help significanty with recursion -- uh, I think. As I'm writing this, and not having tried it, I'm assuming that if a script calls itself with a different parameter that the original parameter is retained when the called script exits and control returns to the initial script. I hope I'm right.

Though, having locals in calculations is great!

- Trigger scripts on events such as entering/exiting a field, switching layouts, changing records, etc.

I know a lot of things it doesn't do can be done with plugins, but when your distributing an app, it'd be nice to not have to deal with plugins, building an installer/registration routine, etc.

- Finally, a question if anyone knows: I've only used this in single user so far, is is now possible to define fields, layout order and permissions without kicking everyone out of the database? 'Cause THAT would be awesome.

OVERALL -- I'm very impressed. The shortcomings -- or what I personally perceive a shortcomings -- are more of an "oh well" than anything else ... gotta have something to look forward to.

Jeff

[Steven H. Blackwell]

"- Finally, a question if anyone knows: I've only used this in single user so far, is is now possible to define fields, layout order and permissions without kicking everyone out of the database? 'Cause THAT would be awesome."

Yes it is.

"Also, why has it not occured to anyone at FileMaker that just because you click somewhere else on a layout does NOT mean you want to scroll to the top of the portal! Leave the portal scroll position where it is! People like to scroll, not click buttons that LOOK like scrollbars just so they can continue to see what they want."

In Layout mode turn off field frames.

Steven

[Ken Newell]

You can make portals horizontial or even a grid. If I understand your portal observation correctly I can point you to a file that shows that. At the road show in LA the demo app they were using showed that. You can download it from the FMI website. It is called business tracker or something to that extent. With portals you can define not only how many rows are to be displayed but also what row they start on. Still tinkering to understand how to put it all together.

[Ocean West]

True but a horizontal portal would be much faster to produce desired results

I have an example of a calendar that I uploaded yesterday. I had to create 42 separate portals each one showing a different initial row. This took time. I my mind a horizontal portal would have solved this

with only 6 portals on the layout. 1st portal would have shown records 1-7 send would be 8-14 etc.

Yes the initial portal row is the the greatest improvement since portals were introduced! 10 years ago.

[jscooper]

"Yes it is."

-- Woohoo!

"In Layout mode turn off field frames."

-- WOOHOO!!!

[LeCates]

Hi jscooper,

Per your question:

- Local variables. Again, do-able with workarounds and scripting, but being able to declare a variable name/global field that's trashed once the script exits, and that exists only in the context of the script, (though the aforementioned parameter passing will help significanty with recursion -- uh, I think. As I'm writing this, and not having tried it, I'm assuming that if a script calls itself with a different parameter that the original parameter is retained when the called script exits and control returns to the initial script. I hope I'm right.

Yup, Script Parameters are 'local' to the script instance. You can recursively call the same script and the stack will return you the right parameter as you back out of sub-scripts.

Good luck,

Andrew

[Mariano Peterson]

10 years later and we're still stuck with the world's wonkiest data grid (portals). Sigh...

(Although... the script parameters are absolutely wonderful, a very VERY welcome improvement).

[Fenton]

I agree with jscooper. It is great to be able to pass parameters to scripts.

[begin rant; I just have to get this off my chest]

What is not so great however is what I feel is the loss of a feature, by being forced to use the Relationship diagram view for all viewing and editing of relationships. In a file with a lot of relationships, it's just a pain, compared to the rather basic but fast and useful relationships dialog we had before.

In FileMaker one often wants to just pop open the Relationship dialog, check something, or redirect a target. This new drawing view is just not suitable for that. I'm sure it's great for beginners, or small files, but if they don't even fit in the window anymore, something is wrong.

Not only is the drawing view bloated, taking up much more room to show the same information, but it is not entirely stable. When trying to drag the darn boxes over to the side, the chart promptly refreshed itself out of existence, disappearing entirely, leaving me back to my layout. At least it didn't crash, sigh.

True, I don't have the fastest machine on earth, eMac 700, OS 10.3.2. But please give us back our simple list view also. Software design should be about presenting usable options, not forcing everyone to do it only one way. Most of us see the relational design in our heads; we just want tools to quickly implement what we see, not get in our way. Sometimes I might want to look at a chart, but I will need a much bigger monitor to see everything in that case.

The argument that "You won't need as many relationships" is probably true. But that's really an excuse not a reason. Should we limit ourselves then to only simple files? Or plan everything (and I mean everything) out on paper first, like "real" database wonks? I'll be buying 7 now, but I'll be waiting hopefully for 7.1.

I know I'll now be considered a "whiner." But this is just my opinion on this particular feature. The rest of it looks great, and I'm sure I'll find more and more to like. I just don't see why we can't have both options.

[bruceR]

Yeah, I tried to bring that up in another forum, it wasn't well received, don't I understand the new relationships, etc. We are going to need additional tools. Note that you can use design functions to define your own relationship lister as just another table, and browse it to your heart's content. However, the relationinfo function is buggy, though I don't know if that is the case in the final version.