Highlight active row in list view

[Brudderman]

Is it possible to highlight the active row in list view using conditional formatting?

Thanks!

James

www.james-mc.com

[mr_vodka]

You would still need to use a technique such as this.

Ray's Highlight in List View Demo

[Brudderman]

You would still need to use a technique such as this.

Ray's Highlight in List View Demo

Thanks! I was hoping now to be able to do it natively but guess not yet. :

[Ocean West]

Thanks! I was hoping now to be able to do it natively but guess not yet. :

Actually the the technique is the same you can substitute out the stacked graphic and a container filed

for a background object like a button and apply the conditional formatting to that. It eliminates the need for the extra fields. However you are limited to a "Flat color palette" not artistic as the gradient graphic.

[bruceR]

I think the original question was about highlighting the current record whether the user has done anything or not to select it. For example, just using control-down-arrow or scrolling through with the rolodex.

Conditional formatting can't do that AFAIK; you will have to click to select it.

[CobaltSky]

Thanks! I was hoping now to be able to do it natively but guess not yet. :

It's been possible to force the refresh natively (and thus achieve dynamic row highlighting) since 8.5 by using an undocumented behavior of the web viewer, and that still works in v9 - however it does produce some flickering on Windows (and has a few other quirky side effects if you don't set it up right).

Using that technique along with conditional formatting in v9 it is still possible to achieve list view highlighting (without having to click the row) - with the same caveats as under 8.5, but without requiring any calc fields.

I was under the impression that JMO was considering publishing a demo of it for v9. Maybe he will chime in. :

[mr_vodka]

Hi Ray.

Welcome back. Its nice to see you back posting in here. :

[Brudderman]

It's been possible to force the refresh natively (and thus achieve dynamic row highlighting) since 8.5 by using an undocumented behavior of the web viewer, and that still works in v9

I'm not familiar with this technique and would certainly be interested in that demo you mentioned--or at least some details on how it's done.

Thanks!

James

www.james-mc.com

[John Mark Osborne]

Ray:

Great seeing you at DevCon!

Yes, I did put together an example of highlighting the currently active record in list view. I challenged some notable FileMaker gurus at DevCon to come up with something but didn't realize you had a technique as well. Anyhow, here is the example file.

HILITEREC.zip

[John Mark Osborne]

I just talked to Ray via Skype (it's 3:30am in Australia) amd he has given me permission to post his version of highlighting the active record without a script or plug-in. It's basically the same as the version I posted earlier except it uses a subsummary part instead. The benefit is the subsummary part allows the web viewer to recalculate but doesn't show in the list view (unlike the trailing grand summary). He also has an 8.5 version in this download. One more thing... he wanted me to mention that he doesn't feel the technique works as well under Windows because there is flashing that occurs when the highlight is drawn. Anyhow, use these techniques as you wish.

Archive.zip

[Brudderman]

Both of these work well for me, and despite Ray's warnings about flashing, I don't see any at all. Very cool!

Thanks to both you and Ray for the demos!

James

www.james-mc.com

[CobaltSky]

Both of these work well for me...

That's great, James. Glad to hear you've now got some ways to move forward with this.

and despite Ray's warnings about flashing, I don't see any at all.

Well, the extent of flashing or flickering does depend on the solution, the machine you're viewing it on and the way you've implemented this technique (granted, the same may be said of various other techniques...).

One other caution is that you should keep in mind that the refresh behavior of web viewers in 8.5 and 9 differs from most other objects - which is in part what makes this trick possible. However we can't be certain that it will not change (especially given that the web viewer is a pretty new feature). So there is slightly greater possibility that "unintended uses" such as this may be impacted by changes in future releases. Not a reason not to use the technique (given that it does what you want), but nevertheless something to bear in mind and watch out for. :wink2:

[comment]

the refresh behavior of web viewers in 8.5 and 9 differs from most other objects - which is in part what makes this trick possible.

I am not too convinced about that. I believe this would work just as well if you replaced the web viewer with an unstored calculation field, using the same formula.

[CobaltSky]

I believe this would work just as well if you replaced the web viewer with an unstored calculation field, using the same formula.

Agreed, Michael. And that may provide a fall-back option (though a slightly less attractive one, given it adds clutter to the schema) should the behavior of the web viewer change in the future.

[comment]

I don't know about that, either. Personally I would prefer both calculations to be in the same place. Tucking away one part of the solution inside a web viewer may reduce the field count, but increase confusion during maintenance.

In any case, it is interesting to note just how lazy Filemaker is when refreshing the screen. If, for example, you make the conditionally formatted field wide, and the web viewer narrow, you can observe how Filemaker conditionally formats ONLY the overlapping part of the field.

[CobaltSky]

Personally I would prefer both calculations to be in the same place.

Both calculations? I'm not sure what you mean. In the example under discussion one calc is in the web viewer and the other is within the conditional formatted object. So in a sense they are in the same place - embedded in their respective objects on the layout.

Moreover since the purpose of both has nothing to do with the data but is associated exclusively with the interface, one might argue that is the "right" place for them.

Either way, I'm struggling to see how putting one of the calcs (or even both of them) into schema aids clarity. So I guess I'd beg to differ.

In any case, it is interesting to note just how lazy Filemaker is when refreshing the screen. If, for example, you make the conditionally formatted field wide, and the web viewer narrow, you can observe how Filemaker conditionally formats ONLY the overlapping part of the field.

True, it's interesting.

One could argue it's optimal (only redrawing what it needs to) although in a case such as this, where it's being used as a work-around for a screen refresh, it exposes the behavior as idiosyncratic. The fact that, if it's set up the way you've described, you can end up with half the highlight appearing on one record and the other half on another is just weird. :?

[comment]

In version 8.5, both could be in calculation fields. In version 9, one would be under conditional formatting, and the other ... well, I guess we won't agree on that.

the purpose of both has nothing to do with the data but is associated exclusively with the interface

That is the sad part - because if it could be applied to data (specifically: cached join results), this could be REALLY useful.

[CobaltSky]

In version 8.5, both could be in calculation fields.

In version 9, both could be in calculation fields too - if that is what you prefer. There is no *requirement* to use the new conditional formatting capability.

In fact if keeping track of things by having everything in schema truly reduces "confusion during maintenance", I guess the whole concept of conditional formatting of layout objects must appear pretty unattractive to you. There's not much that can be done with conditional formatting that can't be done by adding a calc field or two in schema.

Personally, I think it's *great* being able to put things where they belong in the interface and keep the schema uncluttered. For me, it reduces confusion (during maintenance and elsewise). But, as always, YMMV. :wink2:

[comment]

I believe this is getting a bit out of proportion. Conditional formatting is a useful feature - I don't think I have said anything to suggest otherwise.

The point is in this case the formatting depends on a pre-declared variable, so it is not possible to put all the elements of the technique "where they belong in the interface". Wherever you choose to do it, it's not going to be confined to a specific field instance on a specific layout.

Your first post could be misunderstood to mean that a web viewer was the only option for this. Once that has been clarified, it becomes a matter of personal preference. For the benefit of other readers, it should be mentioned that the variable is persistent (i.e. you must not declare another variable with the same name elsewhere), and that the web viewer object must be invisible. I think that should make the pros and cons of each approach quite clear, so anyone contemplating to use this technique can make up their own mind.

[CobaltSky]

Conditional formatting is a useful feature - I don't think I have said anything to suggest otherwise.

Well I'm glad we've clarified that, at least.

Once that has been clarified, it becomes a matter of personal preference.

Agreed.

For the benefit of other readers, it should be mentioned that the variable is persistent (i.e. you must not declare another variable with the same name elsewhere)...

Actually, for the purposes of this technique it doesn't matter if you declare another variable with the same name. At the first screen refresh (which is the first time it matters) the variable will be reinstated as the web viewer evaluates (before the highlight is drawn) - so there will be no discontinuity of highlighting functionality.

...and that the web viewer object must be invisible.

In fact, there is no requirement that the web viewer be invisible, only that it load no URL. And in any case, web viewers are never invisible as such in layout mode (ie they display a prominent "world" watermark icon). So the likelihood the developer will lose track of them (assuming that's your concern) is exceedingly low.

...so anyone contemplating to use this technique can make up their own mind.

Yes. I think that about sums it up. :wink2:

[comment]

Actually, for the purposes of this technique it doesn't matter if you declare another variable with the same name.

No, it doesn't matter for the purposes of this technique. But it might matter for the other purpose.

web viewers are never invisible as such in layout mode (ie they display a prominent "world" watermark icon). So the likelihood the developer will lose track of them (assuming that's your concern) is exceedingly low.

I guess you didn't look at JMO's demo.

[CobaltSky]

No, it doesn't matter for the purposes of this technique. But it might matter for the other purpose.

Which boils down to the "caveat emptor" that applies to *all* uses of variables - even including local and calc variables.

I guess you didn't look at JMO's demo.

The web viewer in JMO's demo is clearly visible. Its formula text shows at the upper left of the layout in layout mode and, when brought forward, its planet watermark is also visible. Pretty hard to miss.

There are many techniques that call for the stacking of objects. I think most developers understand that. :wink2:

[Raybaudi]

It's been possible to force the refresh natively (and thus achieve dynamic row highlighting) since 8.5 by using an undocumented behavior of the web viewer

I have found a way to do the same thing without the WebViewer...

The principle is the same but instead of the webViever I had put a merge field on the back of all the things.

The merge field is the calculation ( unstored ) field:

Let(

$$active = Get ( RecordNumber );

""

)

It seems less flickering on my PC.

[comment]

I have found a way to do the same thing without the WebViewer...

You could have found it back in August - right here in this thread.

[Raybaudi]

I am not too convinced about that. I believe this would work just as well if you replaced the web viewer with an unstored calculation field, using the same formula.

This is the lonely part of this thread where someone says that the webviewer can be replaced by a calc field.

I apologize with you if I didn't understand that you had an example.

So far the webviewer tecnique is the more pubblished... and the merge tecnique no.

[comment]

This is the lonely part of this thread where someone says that the webviewer can be replaced by a calc field.

Well, there's also about a page and a half of Ray and me arguing about which is better. No need to apologize, though. It's actually a good thing you brought this up again, because now that I think of it I realize that in version 9 it can be done purely by conditional formatting - no calculation field or web viewer is necessary:

HighlightActiveRecord9.fp7.zip

[David Jondreau]

Better & better!

:clap:

[Raybaudi]

This part must be tall enough to cover any list length?

No, if you create a footer part.

I'm happy to have given you the idea to use something like a merge field ( in this case a text box )

BTW: real flickering on Win.

P.S.: to prevent the conditional formatting in Preview Mode, it's better to add a condition to the formula:

$activeID = Table::SerialID and Get ( WindowMode ) = 0

HighlightActiveRecord9Mod.zip

[comment]

It doesn't work for me - the highlight stops rendering where the "publisher" object ends, with or without footer.

[Raybaudi]

On windows doesn't stop, even w/o footer, but header + sub-summary must be ≥ one page.

If they are <, than "the highlight stops rendering where the "publisher" object ends"

P.S.: how do you see my file ? Can you add new records and have the trick go on ?

[comment]

I don't see any difference between your file and mine (including when adding a new record). If the WINDOW is taller than the publisher object, the highlighting stops working when you get close to the bottom of the list. I don't see what page boundaries and/or footer have to do with it.

[Raybaudi]

The interest thing is that this trick works even in Table View, providing that that include header part.

[Raybaudi]

I don't see what page boundaries and/or footer have to do with it.

Neither I see too...

but this is what I can see on my Windows machine !

On windows doesn't stop, even w/o footer, but header + sub-summary must be ≥ one page.

It is obvious that we are in Layout Mode.

If the WINDOW is taller than the publisher object...

I have a 17" monitor... how can a window be taller than a A4 page ?

BTW: yes, it stop to work on windows too IF I ZOOM OUT

[Raybaudi]

I guess if "AutoResize" can do something here...

[MattFM]

I made a slight tweak to comment's example above... His is the simplest implementation of this I have seen, but instead of using conditional formatting on a field, I'm using a layout object (a button) to highlight the whole row instead.

Please Filemaker, just make row highlighting native in a future version!

HighlightActiveRecord9.zip

Edited March 16, 2008 by Guest