"Electric Shock" and GTRR

[grantwood]

Hello,

I realize that my title seems a bit odd, but I don't know how else to describe the screen redraw problem I'm having on Windows (I develop on a Mac, which seems immune to this particular problem). I'm using FMP 8.0v1 Advanced.

One example where this weird screen redraw occurs is deleting a portal row. I do the following when you click on a trash can icon in a portal row:

1) Call a delete script with the primary key as the script parameter.

2) Go to a behind-the-scenes layout and set a global key field to the script parameter.

3) Go to the actual record to delete via a GTRR step (using the global key field above)

4) Delete the record and return to the original layout.

I also do some other housekeeping things (like logging that the record got deleted), but the script is pretty simple.

As far as I can tell, the "electric shock" occurs as soon as I set the global key field. The shock seems to be more pronounced if there are multiple portals on a given layout.

Is this how Filemaker on Windows normally refreshes portals, or am I doing something wrong?

Regards,

Sean Mills

[LaRetta]

You will always get some 'shock' when working on Windows. It jumps and flashes more than Macs. Do you include a Freeze Window first?

But I'm wondering why you don't use 'Delete Portal Row' because when the row trash can is selected, FM knows the row/record to delete. You can still include 'housekeeping' steps before the deletion. Your process sounds a bit like overkill.

Can you post your file or give us your exact scripting process? We'd be happy to assist with it.

LaRetta

[grantwood]

Hi LaRetta,

For deleting, my script logic is probably overkill, but I have other places where I set a global key and experience the "shock". I'll see if I can work around these as well.

Thanks,

Sean

[LaRetta]

"I have other places where I set a global key and experience the "shock"."

Without knowing your exact process it's a bit difficult. But you may be experiencing a lag in commit time. You might try adding a Commit Record/Request after setting the key. If it's refresh, try adding Refresh Window [Flush cache join] ... I don't have that checkbox option (I'm on 7.0v1) but I've heard it helps with refresh issues. It might speed up (and thus make the flash less obvious).

LaRetta

[Reed]

why are you using 7v1? It's chock full 'o bugs...

[grantwood]

Hi Reed,

Good thought. I'm using 8.0v1.

As far as I can tell, if I have several portals on a given layout, and if I call a script that goes to a behind-the-scenes layout and then returns, I get this screen redraw. I don't even have to set any fields on this other layout, and Freeze Window doesn't seem to help.

Here's the main place the redraw appears: I prefer not to have users enter a portal directly to add/update data, so I provide global fields, which usually are placed underneath the portal. Anyway, I have a script attached to a button next to the global fields which handles the actual adding/updating, and this script goes to a behind-the-scenes layout.

As an aside, the main reason I don't allow users to enter portals directly are for validation and audit logging purposes. I happen to have some automation to handle these functions, so I don't need or use Filemaker's built-in validation (it hard to manage a lot of fields that need validating).

Anyway, I digress. I wish I could understand why, at version 8, we still have redraw issues on Windows. Maybe 8.0v1 has some redraw bugs.

Thanks,

Sean

[LaRetta]

Hi Dana,

7.0v1 is certainly full of bugs and I know every one of them. And I recommend that NO ONE stay on 7.0v1 and I appreciate you telling me so, also! But this solution is also tied to SecureFM (full windowing, menus and TO triggering) which had its own set of bugs when it first came out for 7). So I just designed around them (creating my own fixes). Then when I upgraded to 7.0v3 and I upgraded SecureFM upgrade (in response to FM's upgrade), I had problems everywhere. I had to switch us back to 7.0v1 until I could resolve it. Even though 7.0v1 is buggy, it works *perfectly with my design.

But then I heard 8 was coming out. So I put off upgrade to 7.03 (and dealing with the fixes of my fixes) and move directly to 8 instead - only one set of final problems to work on. But SecureFM for 8 wasn't out yet (it is now, although not yet for Developer). I can't afford to fix over and over ... no time; especially on a design that is functioning. I wish I could.

I have started my evaluation and move to 8. I will be more than happy to leave 7.0v1 in the dust.

* I dance around and force refreshes; split calcs so they return the correct results (which breaks in 7.0v1 when together, etc).

LaRetta

[LaRetta]

" which usually are placed underneath the portal."

Stacking will cause portal flash also. Try moving those globals out and see if it helps. Portals (on Windows anyway) works best if portal is sent to the back. FM tries to draw fields to the front.

There are many posts which deal with screen flash. The way to pin down what is the worst offender, is to remove everything, place ONE portal and start adding and testing as you go. You might search for Eliminating the Flash Effect here on forums (or even just the word FLASH). There were many good suggestions from many people about the issue. A portal whose fill (background) matches your layout will reduce the flash effect as well.

Portals with large number of related records, portals with aggregate or unstored calcs, transparent portal backgrounds, all contribute. And the more portals you add, the more obvious the flash because those portals need to be drawn, calculated, related records sorted etc.

LaRetta