I recall seeing this issue in FM 11 on some then-aging monitors, primarily when the Zoom level was being used at other-than-100%. It may have had to do with system settings on the monitor itself in some cases.
I would be sure the monitor is set with a refresh rate of 60–80mhz, and that the window is left at 100% zoom level.
Once the problem manifested on a client machine, a full reboot of the client fixed it if the user quit fiddling with the screen -- usually!
One other issue had to do with scrolling the window on oversized layouts (which often had become oversized because of a 150% Zoom!). Something about the redrawing of 150% objects during rapid scrolling still caused portals to go wonky.
My theory: I suspect that many of the objects which trigger this problem are of pixel sizes which do not translate well to odd zoom levels, such a 97x213 pixel object at 150%, so what size does the monitor try to render? On Portals, such objects become repeating rows, so while it may render one or a few okay, as some point the next repetition of the object is so far out of place by a pixel or more for the screen to place it correctly.
Thanks Stephen for answering me back. We are using 100% zoom and the issue has been occurring on different monitors throughout our system. My monitor is as below, with a refresh rate of 60 mhz. Our system scrolling is working fine, it is only when we "Restore Down", then maximize that this issue happens. Our solution was built in 12, but being run in 13. We had no issues with rendering when run from 12, but in 13 we do. No changes have been made to the layouts. Any other thoughts?
- See brilliant picture quality
- HD LCD display, with a 1366 x 768p resolution
- Up to 5msd response time for clear, fast moving action
- Dynamic contrast for incredible rich black details
- Easy to connect and enjoy
Samsung 24 inch E2420 LCD Monitor Specification:
Brand Samsung Model E2420 Widescreen Yes Aspect Ratio 16:9 Optimum Resolution 1920 x 1080 Response Time 5ms Interface One VGA, One DVI Size 570*342.4*67mm Dot Pitch 0.277mm
We're actually lucky that the trigger onLayoutSizeChange was introduced with 13 and allows an easy fix to this issue. (Not that I think one should need it on every layout!)
It sounds to me like the screen refresh rate, though worth testing at other speeds, may be secondary to record caching during the screen redraw, since this is a portal issue, only affecting redrawing of related record fields.
In your script trigger, it might improve redraw speed if you do the screen refresh but turn off the Flush Cache option on that step, assuming that the basic scripted resizing of the screen wasn't happening during a Commit Records script.
If you are also committing related records, then I would suggest avoiding multiple resizings of the screen in quick succession during flushing/recaching.
(Why is the screen being resized twice in a row?)
Hey Stephen, I have tested the issue out on multiple screens and computers, even from other offices, and am getting the same result. The issue in portal lists happens on the stretch field on many different layouts. The amount of records (as long as the list is longer than the screen) has no bearing on the result. The exact same solution run in FM 12 has NO issues... It seems that the anchored fields to the right of the stretch field in the portal list do not refresh properly and are sucked in to where the stretch field is developed at in layout mode. The solution was built in 12 and is now being used in 13, my guess is that there is a conversion issue at hand. I have yet to develop a full layout from scratch in 13, but I will test that out. I would be quite upset if I have to rebuild layouts throughout our system due to bad conversion.
Thanks again for your response.
Let us know if a 13-native layout solves the problem or continues it, when you can.
My own suspicion is that the screen rendering has changed between Server 12 and Server 13, and rapid changes is screen size redraws is at the root of the problem.
We know the screen rendering engine behind Server 13 for webDirect is new, and was revd to better use the CSS-based layout drawing, so I suspect there were changes to the rest of the Server's screen-rendering system as well.
(Still wondering why multiple screen resizings are needed in quick succession in your process.)
Hey Stephen, we use multiple monitors of different sizes with our solution. We can have multiple windows open with multiple files, hope that answers your question. I was able to replicate the issue when re building the layout from scratch in FM 13. I'm running out of ideas. I'm thinking the OnLayoutSizeChange script may be my only short term solution, which is not great since we have over 1300 layouts in just over 50 files...
Thanks for your insight Stephen!
If the problem is limited to portal rows, one hopes that greatly reduces the number of layouts which are in need of special attention.
You can probably run a DDR on the system to locate those with portal objects.