not resolved yet!
Has anywone tried Refresh Window with/without the various possible parameters to see if that also might serve as a work around?
Might be quicker/simpler than the manual steps.
I did several tests, including Refresh Window which, with both parameters activated, showed best consistency but still not reliable and, 'specially with 'delete external Datas in Cache…' (Externe Daten im Cache löschen) activated, slowed down performance drastically.
This once used to work (before FM12v3?). Looks like FMI skipped some rendering-tasks in favor of gaining performance at all.
Though cheating on that subject.
would you please:
- read this report
- confirm that you acknowleged
- do some tests
- have this forwarded to FMI Development Department
Thank you for the post.
To attempt to replicate this, I performed the following test:
1. Created a new database file called "GraphicRender.fmp12"
2. Created 2 tables: DATA & Graphics
3. Created 3 fields in the DATA table: name (text), number (number field), fk (foreign key text field)
4. Created 2 fields in the Graphics table: Graphics (container field), pk (primary key auto-enter serial)
5. Created a relationship from Graphics::pk --- DATA::fk
6. Created a layout associated to the DATA table with four fields: name, number, fk, and Graphics::Graphics (related field).
7. Created 5 records in the Graphics table and placed 5 different images in the Graphics container field: 160 KB PNG, 30 KB PNG, 12 KB PNG, 713 KB JPEG, and a 1.2 MB JPEG.
8. Created 5 records in the DATA table, placing 1, 2, 3, 4, and 5 in the fk field.
9. Closed the database and reopened 5 times to each of the 5 records.
Each test performed loaded the graphic in the related container field without rendering issues. Am I possibly missing a step to replicate?
There might be 2 steps missing:
- the container-field is related via 2 hops
- the grafic from related container-field is maybe 100x5px. The attributes in Layout-Mode therefore are set to "magnify -to-fit" (Bild passend verkleinern oder vergrössern), constrain proportion=off.
This used to work with FMA 11 anyway and has to be concidered as a bug. (I'm not sure if this issue appeared even later with FM12v3?!).
Fact that grafic mostly renders on second touch might indecate that there's something wrong "under-the-hood".
Though please have this report forwarded to FMI Developer Dept.. as what it is: Another annoying bug!!!
I just went thru my personal notes and can confirm now:
Bug appeared with FM12 v3!
Thank you for the reply.
I received the example runtime solution and after clicking on "Calendar" saw the behavior in the screenshot provided prior. However, a runtime is not sufficient example file to provide to Testing and Development since determining the root cause of the issue would require a full access account.
Because I don't have full access to the file I'm guessing here, but from what I can tell there appears to be both merge fields and conditional formatting to add to potential factors since only one layout behaves this way.
Are you willing to provide the database file(s) used to create the runtime and full access credentials, so I can take a look "under the hood"? If so, please check your inbox at the top of this page for instructions on how to submit your file.
To test our new theory of using "two hops" relationship, I created 2 new tables. The new relationship follows:
Graphics::id --- JUMP::fk ---- DOUBLEJUMP::fk --- DATA::fk (see screenshot)
Once again, tests were performed with 5 different graphics. The container field was set to "Enlarge to Fit" and the box was unchecked for "Maintain Original Proportions." All 5 graphics loaded in the related container field without rendering issues.
If you are able to replicate this behavior outside of the current runtime solution, using a new database file built in FileMaker Pro 12 or one of the starter solutions, please let me know.
If we can replicate the behavior in house, then I can submit to Testing and Development.
I will defenitely not hand out my designer password for a intellectual property that I spent more than 30'000h of development. I don't have time and ressources to create and provide you with a clone.
It's well known that the development department has any "Back Door" to get into the design.
As you know, if you start a solution with the Key-File which is "MBZZ.BZZ", it will start in FMA or FMP mode. Though no runtime-mode required. (this is a strong USP with FileMaker in terms of scaleability: Start with RunTime-Mode with [MedicalBizz.exe], later you might wish to extend your solution to network-capability with FMP-licenses on all PC's and start Host-App in FMP-Mode [MBzz.BZZ] and access host with all FMP clients.) Though due to the routine of generating RunTime, the files MBzz.BZZ, usrd.BZZ and rsc.BZZ are de facto .fmp12-files
Maybe you missed another step in your tests. The graphics file I use is verry small though FMP has to scale up a great amount.
The bug appears foremost on the "Adressen" Layout and all the "edit" layouts. FM is doing rendering-work as reqired when go-to-next-record and then back (one up / one down). This strongly indicates that there is a inconsistency under the hood in v3!
If you start MedicalBizz in FMP-Mode [MBzz.BZZ], you can access the host with all yours iOS devices to see same behaviour in FM Go.
This rendering process worked flawless with FM 12 v2!
This bug appeared with FM 12 v3 first.
Thank you for the reply.
I tested again with a very small image (21 pt x 25 pt) and was still unable to replicate outside of your file.
Your solution was forwarded to Testing and Development. I will let you know if the Development and/or Testing departments require more information.
Thank you for reply.
Our Testing department has some additional questions about the structure of the example file provided:
1. Is the container field in question a calculated container?
2. Is the related table from a different file or the same file?
Thank you for taking care for this issue.
if (Auswahl = "Mitarbeiter" ODER "Coworker"; FarbenMitarbeiter::f_Field; Per_Therapeut::Farbe_gif)
[√] Ergebnisse nicht speichern --nur bei Bedarf neu berechnen
[√] nicht berechnen wenn verwendete Felder leer sindYES. The main file is "MBzz.BZZ". All user-data's are in the external file USRD.BZZ.Generally, almost every Layout in file MBzz.BZZ is based on tables from the external file USRD.BZZ.for example field f_Farbe in Layout Adressen in file MBzz.BZZ is:file:/ USRD.BZZ with table Adressen::f_Farbe where calculation set's value from TO FarbenMitarbeiter OR Per_Therapeut=> external File / Calculation / 1 hop to TO's… and YES, this used to work flawless before FM12v4kind regardsBenjamin
Thank you for additional information.
Our Testing department had a previous report (not through the Forums) of this occurring with calculated container fields from an external table if the container field referencing image is from a related container in another external table.
In other solutions some success was reported with the following workaround:
Enable a Refresh Window script for OnRecordLoad trigger.
Could you test to see if using the above workaround corrects the display issue in your solution?