Highlight List View Rows

You'd think highlighting the current record row within a FileMaker list view would be a simple thing. Turns out, there have been a number of attempts at making this easy - it just hasn't been the case. The older method found in Highlight Record Row in list view used a script-trigging plug-in and there was another method that used a hyper-extended web viewer to force row background color.

With FileMaker 10, the easiest way, to-date, is here. In the associated file, it's just a straight simple Script Trigger. All you really need to do is set a global variable and this can be done with a layout script tied to OnRecordLoad.

However, I take an extra bit of effort to use conditional formatting to make the effect happen. My reasoning is described in the file.

If you haven't added this feature into your own solutions then you need to watch this video. It's just way to simple to add this feature in!

AttachmentSize
HighlightListRows.zip226.48 KB

Comments

Very nice simple technique, but I don't like the window flash when moving from record to record.

I modified the script to NOT refresh but to set the value of $$current.record into a global field. This seems to work well without any screen redraw. I think a single global is a price woth paying to eliminate the window flash...

PJ

I've not tried that in list view. I knew it worked with portals, but forcing the whole window to redraw on Windows sucks!

-- Matt Petrowsky - ISO FileMaker Magazine Editor

First I would like to say, I always learn something new every time I watch one of your videos. I also use this technique. I do not use the first condition formatting however, I set the global variable (I have also started to use a global field. This prevents flashing of the screen on computers using windows (macs no problems) ) in the script used by the script trigger.

Todd Dignan

Todd Dignan
Dignan Consulting

Yes, It works great with few records without related or cascading unstored calcs, but try it with one hundred lines with those king of fileds and you'll kill yourself.The $$global variable is the worst performer because it needs the refresh, and thet refresh takes a long time. The Global fields, which doesn't need the refresh is faster, but still 10 times slower than the webwiever method. So I urge anyone with real lisst to stay the webviewer method.

And of course this message to FM Inc : all those tricks are slow and more or less cumbersome, so you NEEED to have a built-in, clean way to do this !

What is the webviewer method?

Todd Dignan
Dignan Consulting

The link to the older article has the older method and the one using the web viewer.

-- Matt Petrowsky - ISO FileMaker Magazine Editor

ANYTHING unstored within a list view will kill FileMaker's speed. Each time something new comes on screen then FMP want's to recalc all unstored objects. This is why FMP (over the Internet) is essentially worthless if you want to use the "tricks" you have to use to make a good interface. FMI could stand to overhaul it's whole screen redraw routines. The problem, however, is that the standard line is something like "Use Citrix or Terminal services"..... Bah, just fix your software (at least if you want people to use it). :P

-- Matt Petrowsky - ISO FileMaker Magazine Editor

After viewing the older method, though it is unique and I like how you used the web viewer to trigger zippScripts......... I like the newer method better because it is native to FMP 10. No third party plugins needed. I really can not see where there would be any speed advantages using the web viewer. Both scripts have a refresh window step in them.
OK, I just did some testing on both windows and mac. I have a global field named g_highlight. I have a script trigger that runs on record load. The script is simple, Set Field( GLB_Globals::g_highlight, Get ( RecordID ). My Conditional Format calc on the field is GLB_Globals::g_highlight= Get ( RecordID ). This works fast. I tested it with displaying 60 records from a MYSQL shadow table

Todd Dignan
Dignan Consulting

Hi, I'm trying this with FM11ADV v2 on Mac OS 10.6.5 and getting a strange outcome.

It seems the highlight is one move behind - when I move records the first time, the highlight does not move, but with the second move, it updates, only to the previously selected record.

When I resize the window slightly, it updates correctly.
It also works correctly when I use Script Debugger.
Just not under normal circumstances.

I tried it in your example file, and also in another file - same result.
Watching the data viewer, it's the variable that is one behind. The @@ in the header is correct, but not the variable.

It seems to be evaluating the conditional formatting after doing the refresh I guess. Very odd.

It does, however, work with using the set variable step in the script (rather than the conditional formatting set variable) and also using a global field as apjcs mentions above.

Can anyone replicate this behaviour, or do I just have one of those "hmmm, I've never seen one quite like THAT before!" problems?

I get the same weirdness in the sample file as well as the solution I was trying to use the technique in. If I randomly click around between the records there is no predictable place the highlight show up. This technique will make a client happy so I'd love to get a good method.

Jeff