You may reduce the Hardware Acceleration in the Windows System. This usually helps.
Thanks for the idea, Winfried. Even though I've been doing DBMS development since 1985, please forgive me as I'm not very knowledgable on networks or hardware and never in the past had to fiddle with graphics or monitor acceleration in Windows.
The ThinkPad uses nVidia Quadro FX 570M card/driver(?) and it's always been running on the default settings. Also, the SyncMaster 191T Res = 1024 x 768.
Since this flashing issue only occurs in FM large text fields, it was hoped that there might be some FM config settings that need tweaking.
Any other thoughts? Much appreciated.
Sure would appreciate a little help with this issue and inquiry.
Do any of the FM Techs offer help here?
What version of FileMaker is this? The reason I ask is that double-buffering on Windows was independently implemented in version 12, which significantly reduces window flashing issues.
v11.0 Pro Advanced purchased in January. And, this problem only occurs in large text fields used for client history notes. Makes no sense.
What can be done, changed or configured differently to eliminate this issue?
Thanks for your input.
Bill, you first asked the question if spell checking mattered. Did you test yourself by turning it off?
And then you asked in this email if "changed or configured differently" would help. Answer: yes, probably. If a "large' text field is the problem, would a portal with related records help? Have you tested your own ideas? If it's a design issue, you are the designer. If it's a FileMaker "redraw" issue, then posting to the here and directly to FMI might help.
(report an issue)
The issue you're describing is most likely due to the lack of intrinsic double-buffering in versions of FileMaker prior to version 12. Because FileMaker is cross-platform and the Mac has its own double-buffering at the OS level, FileMaker did not implement this feature earlier. Further, since FileMaker does periodic screen refreshes when needed, the flashing will be more noticeable than in other programs. In all probability, this is why you only see it with FileMaker.
Now that we've explained why it happens, we need to look at what to do about it. You keep asking about what can be done, but haven't said what you've tried. Did you try turning off hardware acceleration, as suggested by Winfried? As Beverly pointed out, screen refreshes are more noticeable when applied to large areas; hence, reducing the visible area of the field will also help - perhaps by using a scroll bar with the field. You can also use related records in a Notes table, as she suggests, which will both reduce the needed display space and improve your data model - since each note becomes a discrete entry rather than one large block of text (it's a better data tracking practice to do it that way). Finally, version 12 does implement double-buffering, so the screen flashing issue is greatly reduced. You can also reduce the contrast on the screen - instead of stark white fields with black text, try a light gray background.
So the answer is "yes", a lot can be done to reduce screen flicker. But ideas need to be tried to determine whether or not they work in your particular situation.
Thanks for the reply, Beverly. Yes, spell checking was turned off yet the flashing remains.
As for the field format settings, no, it has not been used via a portal as that never occurred to me since many of the free demo databases that have been downloaded and studied do not have their large text fields in portals. Additionally, this text field's config settings have been compared to similarly large text fields in the "bps_Contacts" and "FMStartingPoint2" (Richard Carlton) demo apps and are the same.
So, yes, I have tested all ideas that I know about and cannot figure out what the problem may be. Can large text fields ever have an anomaly that would corrupt functionality without FM popping up an error alert?
Hmm, "redraw" issue? How come it doesn't occur in other layouts or views? Only the Form view. Should a call into Tech Support be made or are there other field config settings I should test?
Thanks so much.
Mike, thanks for the info and new ideas to try. Makes sense and gives me more options to test in follow up to what was noted in my reply to Beverly.
Please forgive me as I have no idea on how to config and/or test hardware acceleration as noted in my reply to Winfried's fine suggestion.
As for the large field with a scroll bar, yes, it is white with 12pt black text and consumes 45-50% of the screen "real estate" space. Based on what I've just learned about FM screen refreshing and double-buffering, I'll now try reducing the size of this field since I'm hesitant to upgrade to v12 until the forum bug reports decrease. Fair?
Oh, this "Notes" text field already is in a Notes_Table with appropriate PKs relating it to the parent as abstract normalization "standards" are employed in my designs. So, if reducing the screen size of this field doesn't help, then I'll test your screen contrast idea and report back on that in the days ahead.
It's hoped that this reply and the one to Beverly provides better clarity on what I already have tried and tested to resolve this issue.
Sure do appreciate your info and guidance. Thank you!
Absolutely, Bill! thanks for the clarification. I didn't see any attached screenshot in your post. I think you've been clear enough to not need one. It may not necessarily be the number of characters (size) of the field, but possibly the dimensions (size) on the layout. Also, thanks for clarifying what you've tried.
Screens and how they redraw can depend on other elements on the layout and in what *order* they redraw. The layout is actually composed of "layers of objects" athough somewhat inconsequential (*most* of the time) - can be a factor. [A point that in older version the screen redraw was used to create quasi-animation based on the redraw of each layer!]
To "see" the layers, select any one object and Send to Back, then Bring to Front (undo if necessary). If there are other objects that touch that one, you can actually see the layer. If there is nothing else sharing bounds, you will not think the object "moves", but it does! We don't have a handy dialog like in FireWorks or other drawing applications to list these layers. And we don't have a "z-index" value on the object in the Inspector to examine or edit.
So, could it be the redraw "order" that is making the flicker (along with perhaps the dimensions of the field)?
You seem to have a good handle on testing, and investigating options...so I think you will do great with FM.
Thanks for your kind words as well, Joshua. Gotta say, this is a very helpful forum.
I like the technique. It's intriging and works well. But especially on Windows, it will does flash on a regular basis as the web viewer re-renders with every movement, record change, window resize, etc.
Me too! It's dynamic and requires much less coding than with a ton of NavScripts as used in Richard Carlton's awesome StartingPoint2 demo.
Joshua,thanks for your confirmation that the NavFramework WebViewer is the cause of the flashing, which occurs less now that the graphics acceleration is set to 60% instead of "full." Nevertheless, the flashing still occurs; sometimes in just the WebViewer menu bar, other times in the layout below the menu bar and other times in both.
In response to Mike Duncan's post above:Thanks for the info. FWIW, currently, I only ever plan to use the layout Form and Table views; although, maybe List view might have value in the future. So for now, I'm just focused on the MenuBar for Form view.
As for Window sizes, mine always are set to full screen. If I want to enter Client Notes, the U.I. will either be a "drill-down" into the related record from a portal where the MenuBar would then be displayed or will call a smaller pop-up layout from the Notes portal line-item that will not have the MenuBar (as in images below) since the user will first have to close that smaller Notes layout window with "action buttons" before navigating away to another Client record. In order to minimize data-entry errors, that approach was employed from 1989-2002 with all corp client solutions and was a workflow structure that SalesLogix also used as well.
Lucky me... As this "conversion project" has a prototype to follow.
However, as a FM newbie, please forgive me... I do not have much of a handle yet on the fancy cool scripts and custom functions logic (NavFramework & BackButton) nor know how to go about even designing neat stuff like that; which I doubt is in any FM documentation as it probably all comes from everyone's "outside" creativity and generosity within these posts.
It's also possible that a version using my techniques could be built without using the web viewer, it's just convenient to use a web viewer to display a variable since it requires no database structure... but you could set a field or two with repetitions that are calculated to display the same variables that are being displayed in the web viewer and it would have the same functionality. That would work in FM 11 as well, in 12 I think you can even dispaly a variable on a layout.
That said, while it's probably asking too much, Mike, how might I learn how to program what you've described using that construct versus the WebViewer. Are there any resources that you or others could redirect me to or share some sample code to help get me started? That would be great!
Thanks so very much for your posts today.
You've been given great advice but I notice you didn't say the FM version. Usually we need to run a few Updaters after downloading. Does yours say 11.0v3?
Stacking objects increases flash greatly - even objects touching each other increases flash. Also, if you have changed the size of the field or the font, it can force FM to adjust a bit as it draws. Fields even a few px shorter than needed in height can cause flash. You might try this ... set your font to the size you want (with no objects selected so it becomes the default). Then create your field and place it on an empty layout. The field should not be transparent, color the background white if you wish to match background; transparency increases flash.
I forgot to mention that if you want border create rectangle with no fill. Place it large enough and outside of the text field so it does not touch it.
Oops, sorry 'bout that, LaRetta and Mike. It was mentioned that v12 was not being used but overlooked saying that version "11.0v3" is being used that just was purchased this past January.
Yes, indeed, great advice and thank you all very much! Been focused on the database "data" design elements (tables, fields, relationships, scripts, custom functions, menus, etc.)... Not how objects might affect screen refreshing and flashing as those types of issues haven't been encountered in past database "projects;" the last one being in MSSQL and SalesLogix.
Therefore, please know and understand that I had no idea that "Stacking objects increases flash greatly" cause it was not noted in any "cautionary" statement in "The Missing Manual" nor FM Help file in said appropriate layout sections. If it was, then it's hidden in some "fine print" that hasn't been found yet.
Can anyone please provide a redirect to where this issue is discussed as it seems to have important value for all us newbies.
LeRetta and others, based on your input and looking at the screen shot above, are you saying that having all the smaller objects (fields, labels, horz lines, buttons, etc.) sitting on top of the large gray rectangle that is visually "framing" the layout is a "bad" design technique given the "stacked object screen flashing issue (bug?)" being discussed here? Since FM provides buttons for 3-levels of stack control in the Inspector, would using 3-levels max per layout still be troublesome?
Either way, what design approach would be better to achieve the same kind of borders and divider lines as depicted above without using layered rectangle objects?
Again, all of your input and ideas are greatly appreciated!
Edit_1: PS: None of the fields are transparent as they all are filled with some color from the pallet, including the rectangle objects.
Edit_2: PPS: Even in the FM Help section, "Moving objects forward or backward on a layout," it shows four levels of stacked objects without discussing its impact on screen flashing and refresh. Since this seems to be a valid, platform-driven issue, how come it's not covered in the docs?