Ten Demos for FileMaker 10 - X4X!

[CobaltSky]

[color:blue]X4X X4X X4X X4X X4X X4X X4X X4X X4X X4X X4X X4X X4X X4X X4X X4X

Marking the release of the FileMaker Pro 10 Bible, NightWing Enterprises is pleased to announce **Ten for 10!**

Available immediately, are ten new demonstration files which showcase a selection of the new features of FileMaker Pro 10. The X4X downloads can be accessed online at:

NightWing Enterprises - FileMaker 10 Demos

These are free downloads, provided as a courtesy to readers of the FileMaker Pro 10 Bible , as well as to fellow developers and prospective clients. Full access is provided to all ten files so you can pull them apart to view the code.

The ten sample and demo files include a mix of new tricks and some new ways to perform old tricks, all built from the ground up using the latest releases of FileMaker Pro and FileMaker Pro Advanced. These demos showcase some of our favourites among the many new features in FileMaker 10.

The X4X release enriches the descriptions of the new features in the FileMaker Pro 10 Bible, which can be found online at the following link:

Amazon.com - FileMaker Pro 10 Bible

[color:blue]X4X X4X X4X X4X X4X X4X X4X X4X X4X X4X X4X X4X X4X X4X X4X X4X

[Raybaudi]

Hi

very good stuff.

The Auto-Bullet example needs a minor fix...

1) Clear the field content

2) Press the BackSpace once

You'll see a zero into the field with the cursor behind. ( while you would aspect to see nothing )

Another BackSpace key transforms the zero into a bullet and put 0 into repeatition 2

[CobaltSky]

The Auto-Bullet example needs a minor fix...

Thanks for catching that, Daniele.

I had omitted a null trap. Oops. I've corrected it, and an updated version (1.0v2) is posted to the demos page now.

Let me know if you spot anything else that needs attention! :P

[Steven H. Blackwell]

Congratulations, Ray, on these demos and on your new book. Thank you for your numerous contributions to the FileMaker community.

Steven

[genevieve charbon]

Thanks Ray,

Amazing work as always.

BUT, the Highligth row is slow ! It's not the fastest way. The webwiever trick is MUCH faster.

The reason is that your's requires a refresh window. Try it with hindreds records in list view with some of them comming from related fileds and unstored cals, and you'll the slowness.

ulearnit uses a global field and in my experiences doesn't require refresh windows step.

http://www.ulearnit.com.au/blog/?p=55#comments

However webwiever still is way faster.

P.S Record highlight is mostly usefull when you've a huge number of records, so the slowness is a big issue.

So FM Inc, you still need to have a built-in way to do this !

Edited May 31, 2009 by Guest

[CobaltSky]

Hello genevieve,

Thanks for your comments.

Let me first say that I agree with your final remark (though it was addressed to FMI...) - that we still need a native way to accomplish custom record highlighting in list view. I hope you've already requested it at the FileMaker Feature Suggestions page.

But, that aside, I must say my experience and perspective differs from yours. Although I have been credited with originating the WV refresh technique, I don't really like it and have in not fact ever used it in a deployed solution. One of the reasons I don't like it is I have not found it to be particularly fast.

On the other hand, the method shown in the X4X active highlight demo tested fasted than four other methods (including the global field method and the WV method) here prior to publication of the demo. The test included plenty of related data. If you're seeing a slow-down especially when related fields are involved, I suggest that first you confirm that the "Flush cached join results" option is not enabled for the Refresh Window[ ] script step.

Failing that, I would suspect a non-optimal design involving either cascading dependencies and/or graph redundancy, either of which can slow a solution down, including screen draws.

While my own observations to date have put v3 highlight approach ahead of the WV highlight technique for speed as well as convenience and simplicity, it's interesting to note that you are seeing a different result on your hardware and with your own solution. I guess that is a good pointer to anyone thinking of implementing any such techniques - to check how it works "in situ" before you deploy. :smirk:

[genevieve charbon]

Hi Ray,

Sure there's no flush cache data, it's just you refresh script pasted as is.

With your method using $$variable it needs a refresh to work, and that's slow in my design. Casading related calculation and related fields.

I think you're right to think yours is faster IF there was just plain indexed data (an maybe the uLearnit method with global field is still faster - one step less but also less reliable as I heard off - not exeperienced).

The webviewer speed is constant regardless the number of records shown (or it seems so). Yours and ulearnit's is slower than the number of records grow (and I mean with related and calcs).

But with few or plain fileds yours could be fatster than webviewer.

Also I use it in a networked FMS 10 cleint server situation on Mac Os X Leopard. So not standalone solution.

Of course your method is much simpler to implement thanthe webviewer one.

Failing that, I would suspect a non-optimal design involving either cascading dependencies and/or graph redundancy, either of which can slow a solution down, including screen draws.

Maybe my design is not effecient, but webviewer with it is faster. I'd really like to be it to be more effecient.

Basiacly there's fields that are displayed that involves calculations

F1 : Related1::A*Related2:

F2 : F1 * Related3::C

F3 : F1*1,196

plus just some plain related fileds.

Let me ask you how to write the above effeciently ?

Would

F1 : Related1::A*Related2:

F2 : Related1::A*Related2: * Related3::C

F3 : Related1::A*Related2: *1,196

be faster ?

What do you mean by "graph redundancy" ?

In my experience, as soon s as you use related data Filemaker is slow, and that bothers me a lot !

Thanks

[CobaltSky]

Hi Genevieve,
A few comments and responses to the things you raised...
 

 

...I think you're right to think yours is faster IF there was just plain indexed data (an maybe the uLearnit method with global field is still faster - one step less but also less reliable as I heard off - not exeperienced).

Assuming the method in question is one that involves triggering a script that sets a value into a global field in the current table, it isn't one step less (both it and the X4X method use a trigger to call a one-step script), and in my own tests it was slower in every case, not faster.

Meanwhile I believe that "less reliable" would be a reference to the fact that highlighting methods that depend on a value in a global field (or any other field) are apt to produce undesirable results when there is more than one window displayed (*all* windows that show the same layout on the current workstation show the highlight in the same record, even if different records are active in each window).

 

 

The webviewer speed is constant regardless the number of records shown (or it seems so). Yours and ulearnit's is slower than the number of records grow (and I mean with related and calcs).
But with few or plain fileds yours could be fatster than webviewer.

As I noted above, that has not been my experience. The X4X ActiveHighlight demo was tested extensively with over 20k records including related records (where the related table also had over 20k records and fields from the related table were included on the list layout) and showed no perceptible slowdown on any of the test systems I ran it on. It remained fast (actually, very fast), including when running over the network from Server v10 with multiple users connected. In all those tests the X4X technique outperformed row highlighting techniques based on WV, global field or plug-in methods. I am *not* however questioning your results, just letting you know that they are not the same as my own.

What my tests did not include, however were: 1) unstored calculations with cascading dependencies, or 2) complex relationships graphs with significant duplication of content and/or a large number of cached joins. Both these can impact performance, including display and refresh response times.

In particular, and as a general principle, list layouts and unstored calculations are not a good mix, especially if the unstored calculations themselves reference other unstored calculations which in turn reference still other unstored calculations etc. That's because in order to display each row, FIleMaker must unravel the whole chain of dependencies, sourcing the raw values and computing each result it turn before it can commence evaluation of the next. That can be a problem at any time, but on a list layout where to simply draw the display the process must be repeated multiple times it is especially undesirable.

It is preferably to avoid over-use of unstored calculations and in particular, unstored calculations that have cascading dependencies (on other unstored calcs, on related data, or both). The desirability of avoiding these combinations becomes still more important when long list layouts with large record counts are involved. And that is generally true as a solution and interface design principle, regardless of the use of ActiveHighlight or related techniques.

A more viable interface model would be one where only essential stored data fields are included on the list layout, with other derived values (including those generated via unstored calcs) either being:

a] revealed on a record-by-record basis when the user rolls the mouse over a given record,
b] shown on demand in a pop-up window or on a detail layout accessible with one click from the list,
c] shown only for the active record - eg in the header or footer, or
d] calculated as a snapshot at a point in time prior to the display of the layout and stored.

One might say that while FileMaker does give you the rope to hang yourself with, it doesn't force you to put it around your neck. 

 

 

Basiacly there's fields that are displayed that involves calculations


F1 = Related1::A*Related2:
F2 = F1 * Related3::C
F3 = F1*1,196

plus just some plain related fileds.

Let me ask you how to write the above effeciently ?

Would

F1 = Related1::A*Related2:
F2 = Related1::A*Related2: * Related3::C
F3 = Related1::A*Related2: *1,196

be faster ?

Yes, you could expect the latter to marginally faster, though the actual impact would depend on a number of factors from graph design (including the nature and complexity of the relationships to Related1, Related2 and Related3) to processor configuration, to LAN speeds and more. Faster still, though, would be a single calc that returned the three results combined as an array, with the formula specified as:
 

Let([
f1 = Related1::A * Related2:;
f2 = f1 * Related3::C;
f3 = f1 * 1196];
f1 & " " & f2 & " " & f3
)

But this would still be a compromise from the POV of interface design, since you're burdening the processor heavily to render a whole list of these every time the screen is drawn, scrolled or otherwise subject to user interaction. FileMaker is one of the few database environments that even allows you to do this - hence my remark about rope above.
 

 

What do you mean by "graph redundancy" ?

In my experience, as soon s as you use related data Filemaker is slow, and that bothers me a lot !

That's not my experience at all, Genevieve. And as I mentioned, with over 20,000 related records, a Server-deployed copy of the ActiveHighlight_v3 demo here did not show a perceptible performance slow-down. It depends greatly on *how* the file is built, including how the graph is designed.

As for "Graph redundancy", that's a pretty big topic in itself, but I was referring to approaches that require the repetition of a lot of graph elements, that result in a high ratio of TOs to base tables (eg anything approaching or exceeding 10:1 is getting right up there!) and a correspondingly high total number of cached joins, all of which Filemaker has to track and manage for almost every action.

Not really a topic one can do justice to in a forum thread - but I believe there may be a white paper on it floating around somewhere. :wink2:

[Rich S]

Well done, Ray! I look forward to purchasing the Bible 10/E next payday and donating my 9th Ed. to the local library (as I do for all superseded tech books.)