GUI container field changing state (to all white)

[netbuilder]

I'm trying to use global container fields for some GUI elements in a layout and am having a problem with them disappearing or going 'all white' when other buttons are pressed in Browse mode. Specifically, I've got a list layout with a couple of buttons in each row along with data. In the header I've put a graphic task bar (container field),and some info on top of it, including other buttons (also container fields) and merge fields. If a user clicks a buttons in the list rows, the container fields in the header all go completely white, and obscure everything else within their footprint (as if they had been brought to the front of the layout). I discovered a partial fix to this problem by changing the task bar container field fill from transparent to any color, but this 'all white' flashing still occurs inside the footprint of any merge fields sitting on the task bar. (Kind of look likes the effect you get from some of the row fields highlighting techniques.) The [container] buttons sitting on the task bar also continue to flash all white when they are pressed -- well actually one does and one doesn't. (hmmm... but can't find any relevant difference between the two.)

Does anyone have a suggestion/technique for how to get rid of this behavior? It is obviously disconcerting to click on something down in a list layout and have items in the header bar disappear or change state like this.

Thanks,

Jim

[Tony O]

Good Morning Netbuilder,

Are the global container fields really necessary to the solution? If they are graphical elements - why not just place them on the layout?

Beyond that, are there other GUI elements that are overlapping the container fields (buttons, fields, popup lists)? That would cause some confusion and the behavior you're experiencing. Experiment with the container field access turned off and see if the behavior changes.

hth,

Tony

[netbuilder]

Thanks for your response Tony!

The container field construction is being used to facilitate both (a) multi-function buttons, in which the button graphic changes to reflect the action it will perform, and ( in the case of the task bar, ease of replacing that graphic element over 50+ layouts when the need arises. The construction here is calculation container fields sitting on the task bar, with the actual buttons being simple squares sitting in the back layer behind everything. The container calc changes the button graphic to match the anticipated action of the underlying button script. The merge field (record # of total records) is simply sitting on the task bar. There are other layout elements further along the task bar in either direction, none of which are having issues, but none are data/merge fields or calculated containers either. There are no other overlapping elements with these fields, other than the construction I described.

I have tried different combinations of setting button behavior, field formatting, fill/no-fill, etc. on these various elements, but so far no combination eliminates the awkward white-out of either the merge field when a list row button is pressed, or of the container buttons when one of it's neighbor buttons is pressed.

Oddly, I have since discovered that the calc container fields do not generate this unwelcome behavior when sitting in the header of layouts shown in Form view... only those in List view -- and *only* when there is more than one record in the found set. The merge field behaves the same way. Wait -- just had an inspiration... the merge field is ALSO a calculation field (record count within the found set). In fact, all the calculation fields here are dependent on 'Get (RecordNumber)', which probably explains what's happening. In list view when I click on a button that is in another record, these [unstored] calculations might trigger already on 'mouse down'... and if so could be what is causing the white-out behavior. As a test I clicked on the current record in list view... no white-out. It only happens when I click into another record.

OK... I guess that solves the mystery of why it is happening. Not sure what I can do about it, other than consider if the calculations can somehow not include a reference to the current record...

Regards,

Jim