Odd Layout Behavior - duplicate vs "hand made" additions to a portal row gives different results

classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Odd Layout Behavior - duplicate vs "hand made" additions to a portal row gives different results

Paul Bostwick
Hey all,

long time no post.

I have a portal that has a few fields from related records, and some of them are formatted as checkboxes that we can enter while in find mode. I wanted to add another checkbox from another boolean field to the portal row… I copied the one next to where I wanted the new one (too lazy to even drag very far) brought up the inspector, changed the field referenced, made sure the field was IN the portal row and had not become attached to the surrounding area above (reflexively)... and then browsed the records and (here is the problem) ONLY the top row showed the new checkbox… I went in and re-checked and even over compensated in pulling the box down to be certain it was not “hanging from the top” Still no dice.

I tried adding the field “by hand” Going to the menu bar selecting the field tool putting the field in the portal row. Specifying Checkbox as the format, Selecting the usual Value list that works everywhere else and shrinking the box to  not show the “1” but just the X in the box… Browsed… Lovely, Check box in every row. some checked some not checked… Just as hoped… Now I try to change the font to Verdana. IT WON”T CHANGE. I can click on it select Verdana and 14pts from the format menu. But it will not change. Can do the same thing in the inspector… and get the same resistance to change… Hummmmm….

Experiment Three! Duplicate one of the Verdana ones… but do not change the field it references! It works as expected. Change the field reference (same table same relation, just scroll down to the desired field) NOW it only shows on the first portal row! Dang!

So my interim solution is to leave it formatted “wrong” but I am worried that this might be more meaningful… File corruption? FM bug? i’ve never seen a shows on the first row but no others behavior outside of accidentally placing the field overlapping the edge of the portal…

Thoughts?
_______________________________________________
FMPexperts mailing list
[hidden email]
http://lists.ironclad.net.au/listinfo.cgi/fmpexperts-ironclad.net.au
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Odd Layout Behavior - duplicate vs "hand made" additions to a portal row gives different results

Richard DeShong
Hi Paul,

First, what version of FMP (and FMS, if using)?

Second, can you add a field to the same layout, but not in that portal,
and then change the font to Verdana?


On 4/21/2017 4:13 PM, Paul Bostwick wrote:

> Hey all,
>
> long time no post.
>
> I have a portal that has a few fields from related records, and some of them are formatted as checkboxes that we can enter while in find mode. I wanted to add another checkbox from another boolean field to the portal row… I copied the one next to where I wanted the new one (too lazy to even drag very far) brought up the inspector, changed the field referenced, made sure the field was IN the portal row and had not become attached to the surrounding area above (reflexively)... and then browsed the records and (here is the problem) ONLY the top row showed the new checkbox… I went in and re-checked and even over compensated in pulling the box down to be certain it was not “hanging from the top” Still no dice.
>
> I tried adding the field “by hand” Going to the menu bar selecting the field tool putting the field in the portal row. Specifying Checkbox as the format, Selecting the usual Value list that works everywhere else and shrinking the box to  not show the “1” but just the X in the box… Browsed… Lovely, Check box in every row. some checked some not checked… Just as hoped… Now I try to change the font to Verdana. IT WON”T CHANGE. I can click on it select Verdana and 14pts from the format menu. But it will not change. Can do the same thing in the inspector… and get the same resistance to change… Hummmmm….
>
> Experiment Three! Duplicate one of the Verdana ones… but do not change the field it references! It works as expected. Change the field reference (same table same relation, just scroll down to the desired field) NOW it only shows on the first portal row! Dang!
>
> So my interim solution is to leave it formatted “wrong” but I am worried that this might be more meaningful… File corruption? FM bug? i’ve never seen a shows on the first row but no others behavior outside of accidentally placing the field overlapping the edge of the portal…
>
> Thoughts?
> _______________________________________________
> FMPexperts mailing list
> [hidden email]
> http://lists.ironclad.net.au/listinfo.cgi/fmpexperts-ironclad.net.au

--
Richard DeShong
Logic Tools
510-642-5123 office
925-285-1088 cell

_______________________________________________
FMPexperts mailing list
[hidden email]
http://lists.ironclad.net.au/listinfo.cgi/fmpexperts-ironclad.net.au
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Odd Layout Behavior - duplicate vs "hand made" additions to a portal row gives different results

Paul Bostwick
I can add it to another area of the layout BUT>>> It will not change to Verdana… It will change to Ariel… and to Mistral (random choices) but NOT to verdana (it replaces Verdana with Helvetica!) Interesting.

> On Apr 21, 2017, at 4:41 PM, Richard DeShong <[hidden email]> wrote:
>
> Hi Paul,
>
> First, what version of FMP (and FMS, if using)?
>
> Second, can you add a field to the same layout, but not in that portal, and then change the font to Verdana?
>
>
> On 4/21/2017 4:13 PM, Paul Bostwick wrote:
>> Hey all,
>>
>> long time no post.
>>
>> I have a portal that has a few fields from related records, and some of them are formatted as checkboxes that we can enter while in find mode. I wanted to add another checkbox from another boolean field to the portal row… I copied the one next to where I wanted the new one (too lazy to even drag very far) brought up the inspector, changed the field referenced, made sure the field was IN the portal row and had not become attached to the surrounding area above (reflexively)... and then browsed the records and (here is the problem) ONLY the top row showed the new checkbox… I went in and re-checked and even over compensated in pulling the box down to be certain it was not “hanging from the top” Still no dice.
>>
>> I tried adding the field “by hand” Going to the menu bar selecting the field tool putting the field in the portal row. Specifying Checkbox as the format, Selecting the usual Value list that works everywhere else and shrinking the box to  not show the “1” but just the X in the box… Browsed… Lovely, Check box in every row. some checked some not checked… Just as hoped… Now I try to change the font to Verdana. IT WON”T CHANGE. I can click on it select Verdana and 14pts from the format menu. But it will not change. Can do the same thing in the inspector… and get the same resistance to change… Hummmmm….
>>
>> Experiment Three! Duplicate one of the Verdana ones… but do not change the field it references! It works as expected. Change the field reference (same table same relation, just scroll down to the desired field) NOW it only shows on the first portal row! Dang!
>>
>> So my interim solution is to leave it formatted “wrong” but I am worried that this might be more meaningful… File corruption? FM bug? i’ve never seen a shows on the first row but no others behavior outside of accidentally placing the field overlapping the edge of the portal…
>>
>> Thoughts?
>> _______________________________________________
>> FMPexperts mailing list
>> [hidden email]
>> http://lists.ironclad.net.au/listinfo.cgi/fmpexperts-ironclad.net.au
>
> --
> Richard DeShong
> Logic Tools
> 510-642-5123 office
> 925-285-1088 cell
>
> _______________________________________________
> FMPexperts mailing list
> [hidden email]
> http://lists.ironclad.net.au/listinfo.cgi/fmpexperts-ironclad.net.au

_______________________________________________
FMPexperts mailing list
[hidden email]
http://lists.ironclad.net.au/listinfo.cgi/fmpexperts-ironclad.net.au
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Odd Layout Behavior - duplicate vs "hand made" additions to a portal row gives different results

Richard DeShong
So, make plenty of backups of this fm file.

First thing to try:  Your system has a "font cache".  Google how to
clear this cache so that your OS rebuilds it.


On 4/21/2017 5:23 PM, Paul Bostwick wrote:

> I can add it to another area of the layout BUT>>> It will not change to Verdana… It will change to Ariel… and to Mistral (random choices) but NOT to verdana (it replaces Verdana with Helvetica!) Interesting.
>> On Apr 21, 2017, at 4:41 PM, Richard DeShong <[hidden email]> wrote:
>>
>> Hi Paul,
>>
>> First, what version of FMP (and FMS, if using)?
>>
>> Second, can you add a field to the same layout, but not in that portal, and then change the font to Verdana?
>>
>>
>> On 4/21/2017 4:13 PM, Paul Bostwick wrote:
>>> Hey all,
>>>
>>> long time no post.
>>>
>>> I have a portal that has a few fields from related records, and some of them are formatted as checkboxes that we can enter while in find mode. I wanted to add another checkbox from another boolean field to the portal row… I copied the one next to where I wanted the new one (too lazy to even drag very far) brought up the inspector, changed the field referenced, made sure the field was IN the portal row and had not become attached to the surrounding area above (reflexively)... and then browsed the records and (here is the problem) ONLY the top row showed the new checkbox… I went in and re-checked and even over compensated in pulling the box down to be certain it was not “hanging from the top” Still no dice.
>>>
>>> I tried adding the field “by hand” Going to the menu bar selecting the field tool putting the field in the portal row. Specifying Checkbox as the format, Selecting the usual Value list that works everywhere else and shrinking the box to  not show the “1” but just the X in the box… Browsed… Lovely, Check box in every row. some checked some not checked… Just as hoped… Now I try to change the font to Verdana. IT WON”T CHANGE. I can click on it select Verdana and 14pts from the format menu. But it will not change. Can do the same thing in the inspector… and get the same resistance to change… Hummmmm….
>>>
>>> Experiment Three! Duplicate one of the Verdana ones… but do not change the field it references! It works as expected. Change the field reference (same table same relation, just scroll down to the desired field) NOW it only shows on the first portal row! Dang!
>>>
>>> So my interim solution is to leave it formatted “wrong” but I am worried that this might be more meaningful… File corruption? FM bug? i’ve never seen a shows on the first row but no others behavior outside of accidentally placing the field overlapping the edge of the portal…
>>>
>>> Thoughts?
>>> _______________________________________________
>>> FMPexperts mailing list
>>> [hidden email]
>>> http://lists.ironclad.net.au/listinfo.cgi/fmpexperts-ironclad.net.au
>> --
>> Richard DeShong
>> Logic Tools
>> 510-642-5123 office
>> 925-285-1088 cell
>>
>> _______________________________________________
>> FMPexperts mailing list
>> [hidden email]
>> http://lists.ironclad.net.au/listinfo.cgi/fmpexperts-ironclad.net.au
> _______________________________________________
> FMPexperts mailing list
> [hidden email]
> http://lists.ironclad.net.au/listinfo.cgi/fmpexperts-ironclad.net.au

--
Richard DeShong
Logic Tools
510-642-5123 office
925-285-1088 cell

_______________________________________________
FMPexperts mailing list
[hidden email]
http://lists.ironclad.net.au/listinfo.cgi/fmpexperts-ironclad.net.au
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Odd Layout Behavior - duplicate vs "hand made" additions to a portal row gives different results

Bruce Robertson
In reply to this post by Paul Bostwick
Tried to change it how?
With the font tools at the top of the layout, in the tool bar area?
Or using the Inspector palette?

FWIW I have encountered many cases where the toolbar mods don’t work; but the inspector does work.

> On Apr 21, 2017, at 4:13 PM, Paul Bostwick <[hidden email]> wrote:
>
>  Now I try to change the font to Verdana. IT WON”T CHANGE. I can click on it select Verdana and 14pts from the format menu. But it will not change. Can do the same thing in the inspector… and get the same resistance to change… Hummmmm….

_______________________________________________
FMPexperts mailing list
[hidden email]
http://lists.ironclad.net.au/listinfo.cgi/fmpexperts-ironclad.net.au
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Odd Layout Behavior - duplicate vs "hand made" additions to a portal row gives different results

Paul Bostwick

> On Apr 21, 2017, at 6:22 PM, Bruce Robertson <[hidden email]> wrote:
>
> Tried to change it how?
> With the font tools at the top of the layout, in the tool bar area?
> Or using the Inspector palette?
>
Tried both ways… other fonts will “stick” but Verdana reverts to Helvetica… both ways: menu driven and via the inspector palette.


> FWIW I have encountered many cases where the toolbar mods don’t work; but the inspector does work.

This is on a served file and the behavior (the first line portal trouble) was displayed on two different client machines. I have not gone back to check if all this behavior is happening on the first client. But the initial problem happened the same way on two separate clients.

-Paul
_______________________________________________
FMPexperts mailing list
[hidden email]
http://lists.ironclad.net.au/listinfo.cgi/fmpexperts-ironclad.net.au
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Odd Layout Behavior - duplicate vs "hand made" additions to a portal row gives different results

Paul Bostwick
In reply to this post by Richard DeShong

> On Apr 21, 2017, at 5:51 PM, Richard DeShong <[hidden email]> wrote:
>
> So, make plenty of backups of this fm file.
on it...
>
> First thing to try:  Your system has a "font cache".  Google how to clear this cache so that your OS rebuilds it.
This is a served file and this trouble happened on two separate clients the same way (see other email) Does not seem like a client issue… Are the fonts pushed from the server? or some fonts? I’ve had clients with dead fonts that could not see the text in that font on layouts that used them… Pretty funny conversation where they describe their screen. This does not seem like that sort of problem. But rebuilding fonts seems like it couldn’t hurt.

>
>
> On 4/21/2017 5:23 PM, Paul Bostwick wrote:
>> I can add it to another area of the layout BUT>>> It will not change to Verdana… It will change to Ariel… and to Mistral (random choices) but NOT to verdana (it replaces Verdana with Helvetica!) Interesting.
>>> On Apr 21, 2017, at 4:41 PM, Richard DeShong <[hidden email]> wrote:
>>>
>>> Hi Paul,
>>>
>>> First, what version of FMP (and FMS, if using)?
>>>
>>> Second, can you add a field to the same layout, but not in that portal, and then change the font to Verdana?
>>>
>>>
>>> On 4/21/2017 4:13 PM, Paul Bostwick wrote:
>>>> Hey all,
>>>>
>>>> long time no post.
>>>>
>>>> I have a portal that has a few fields from related records, and some of them are formatted as checkboxes that we can enter while in find mode. I wanted to add another checkbox from another boolean field to the portal row… I copied the one next to where I wanted the new one (too lazy to even drag very far) brought up the inspector, changed the field referenced, made sure the field was IN the portal row and had not become attached to the surrounding area above (reflexively)... and then browsed the records and (here is the problem) ONLY the top row showed the new checkbox… I went in and re-checked and even over compensated in pulling the box down to be certain it was not “hanging from the top” Still no dice.
>>>>
>>>> I tried adding the field “by hand” Going to the menu bar selecting the field tool putting the field in the portal row. Specifying Checkbox as the format, Selecting the usual Value list that works everywhere else and shrinking the box to  not show the “1” but just the X in the box… Browsed… Lovely, Check box in every row. some checked some not checked… Just as hoped… Now I try to change the font to Verdana. IT WON”T CHANGE. I can click on it select Verdana and 14pts from the format menu. But it will not change. Can do the same thing in the inspector… and get the same resistance to change… Hummmmm….
>>>>
>>>> Experiment Three! Duplicate one of the Verdana ones… but do not change the field it references! It works as expected. Change the field reference (same table same relation, just scroll down to the desired field) NOW it only shows on the first portal row! Dang!
>>>>
>>>> So my interim solution is to leave it formatted “wrong” but I am worried that this might be more meaningful… File corruption? FM bug? i’ve never seen a shows on the first row but no others behavior outside of accidentally placing the field overlapping the edge of the portal…
>>>>
>>>> Thoughts?
>>>> _______________________________________________
>>>> FMPexperts mailing list
>>>> [hidden email]
>>>> http://lists.ironclad.net.au/listinfo.cgi/fmpexperts-ironclad.net.au
>>> --
>>> Richard DeShong
>>> Logic Tools
>>> 510-642-5123 office
>>> 925-285-1088 cell
>>>
>>> _______________________________________________
>>> FMPexperts mailing list
>>> [hidden email]
>>> http://lists.ironclad.net.au/listinfo.cgi/fmpexperts-ironclad.net.au
>> _______________________________________________
>> FMPexperts mailing list
>> [hidden email]
>> http://lists.ironclad.net.au/listinfo.cgi/fmpexperts-ironclad.net.au
>
> --
> Richard DeShong
> Logic Tools
> 510-642-5123 office
> 925-285-1088 cell
>
> _______________________________________________
> FMPexperts mailing list
> [hidden email]
> http://lists.ironclad.net.au/listinfo.cgi/fmpexperts-ironclad.net.au

_______________________________________________
FMPexperts mailing list
[hidden email]
http://lists.ironclad.net.au/listinfo.cgi/fmpexperts-ironclad.net.au
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Odd Layout Behavior - duplicate vs "hand made" additions to a portal row gives different results

Stefan Schütt
In reply to this post by Paul Bostwick
Hi Patrick,

> Paul Bostwick <[hidden email]> kirjoitti 22.4.2017 kello 2.13:
>
> and then browsed the records and (here is the problem) ONLY the top row showed the new checkbox…

Coming in late...

Yup. This is a known problem. The general fix for this is to either move the ”non-sticking” field up above the portal. I use the arrow keys for this.

Then deselect the field, select it again, and move it back down. In 15 (at least) you will see a blue horizontal line when the field is in the same line as the rest of the fields. This will usually help.

The main thing is that when moving a field into a portal, it is important that the fields boundaries are completely within the first portal row.

When fixing this, which is a quite common issue, I mostly make the fields small enough to fit inside the first portal row.

When you duplicate (using the Duplicate-command) the field actually moves 9 points to the right and down. Which might move it below the bottom of the first portal line (as seen in Layout mode).

The other way that I have found, and which has been verified by FMI, is to use the Field Picker.

In the Field Picker you need to select the table Occurence used in the portal, then select the field you want and drag it into the portal.

And, this *is* a bug. Introduced in 13, fixed with a v-update, broke again in 14. Still broken in 15.

One of the most irritating and time consuming layout bugs around. But it is fixable.

Regarding the font-problem. You did not say what OS (Mac or Windows, versions), what FMP/FMS versions.

If Mac, you should check with the Font Book, if the Verdana is corrupted. Otherwise you have got some good advice already

__
Stefan Schutt, Mouse Up, Finland



_______________________________________________
FMPexperts mailing list
[hidden email]
http://lists.ironclad.net.au/listinfo.cgi/fmpexperts-ironclad.net.au
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Odd Layout Behavior - duplicate vs "hand made" additions to a portal row gives different results

Mikhail Edoshin-2
In reply to this post by Paul Bostwick
Hi,

As far as I've noticed in FileMaker for an object to be "enclosed" by a
portal, tab panel, or slide panel, you have to manually drag them there
with the mouse. I call it "magic dragging" :) If you use anything other
than dragging (type the coordinates in the inspector, use arrow keys,
align tools) this won't happen. At the same time if you move your object
out of the enclosing object with any of that, it will get unstuck just
fine; there are also subtle bugs with pasting when the pasted elements
land across such a magic area.

This started in v12, I believe, when they changed their layout engine.
Given that dragging also degraded very much (too sensitive, wrong
constrained drag behavior, etc.) the whole experience is rather
frustrating. I don't think they will ever fix that though. I myself find
solace in the stoic philosophy and the "shikata ga nai" principle [1] :)

No idea about the font issue; sometimes FileMaker refuses to change the
font because of the field language, but I doubt this could be the case
for Verdana and it normally warns about it. If it doesn't change it with
various modifier keys or doesn't copy the format with the format
painter, I'd suspect something wrong with the layout.

[1] https://en.wikipedia.org/wiki/Shikata_ga_nai

Kind regards,
Mikhail

On 4/22/2017 2:13 AM, Paul Bostwick wrote:

> Hey all,
>
> long time no post.
>
> I have a portal that has a few fields from related records, and some of them are formatted as checkboxes that we can enter while in find mode. I wanted to add another checkbox from another boolean field to the portal row… I copied the one next to where I wanted the new one (too lazy to even drag very far) brought up the inspector, changed the field referenced, made sure the field was IN the portal row and had not become attached to the surrounding area above (reflexively)... and then browsed the records and (here is the problem) ONLY the top row showed the new checkbox… I went in and re-checked and even over compensated in pulling the box down to be certain it was not “hanging from the top” Still no dice.
>
> I tried adding the field “by hand” Going to the menu bar selecting the field tool putting the field in the portal row. Specifying Checkbox as the format, Selecting the usual Value list that works everywhere else and shrinking the box to  not show the “1” but just the X in the box… Browsed… Lovely, Check box in every row. some checked some not checked… Just as hoped… Now I try to change the font to Verdana. IT WON”T CHANGE. I can click on it select Verdana and 14pts from the format menu. But it will not change. Can do the same thing in the inspector… and get the same resistance to change… Hummmmm….
>
> Experiment Three! Duplicate one of the Verdana ones… but do not change the field it references! It works as expected. Change the field reference (same table same relation, just scroll down to the desired field) NOW it only shows on the first portal row! Dang!
>
> So my interim solution is to leave it formatted “wrong” but I am worried that this might be more meaningful… File corruption? FM bug? i’ve never seen a shows on the first row but no others behavior outside of accidentally placing the field overlapping the edge of the portal…
>
> Thoughts?
> _______________________________________________
> FMPexperts mailing list
> [hidden email]
> http://lists.ironclad.net.au/listinfo.cgi/fmpexperts-ironclad.net.au

_______________________________________________
FMPexperts mailing list
[hidden email]
http://lists.ironclad.net.au/listinfo.cgi/fmpexperts-ironclad.net.au
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Odd Layout Behavior - duplicate vs "hand made" additions to a portal row gives different results

Jonathan Fletcher-2
Mikhail,

Not contradicting you; merely expanding on what you said. I have found the nudge keys do indeed work to fix the Stupid FileMaker 12 Portal Bug (tm), if you do it a certain way. I HATED FileMaker 12 for WEEKS until I figured out a way to reliably get fields to belong to a portal! (My wife will tell you I wasn’t a happy camper then.)

My way:

1. Drag-select all the objects that you want in the portal row, and make sure they are all aligned, the same height and no more than the height of the portal row. (I just use all the keyboard shortcuts for the aligning and sizing.) Make sure they are placed where you want them.

2. Nudge the selected objects with the DOWN cursor keys 3 to 6 pixels, and then back up again the same amount.

That should do it. Check to see if they’re properly captured by selecting just the portal, hitting any cursor key to make sure none of the unselected row objects is left behind. If they all move with the portal, move it back and you’re good to go.

The field picker doesn’t work for me for precise work in the portal for the aforementioned reason and a few others, so I’m more of a copy-and-paste person when it comes to portal fields. I end up having to use the above technique several times as a portal evolves during development. The good news is that my technique just takes literally five seconds to employ.

Jonathan




> On Apr 22, 2017, at 4:59 AM, Mikhail Edoshin <[hidden email]> wrote:
>
> Hi,
>
> As far as I've noticed in FileMaker for an object to be "enclosed" by a portal, tab panel, or slide panel, you have to manually drag them there with the mouse. I call it "magic dragging" :) If you use anything other than dragging (type the coordinates in the inspector, use arrow keys, align tools) this won't happen. At the same time if you move your object out of the enclosing object with any of that, it will get unstuck just fine; there are also subtle bugs with pasting when the pasted elements land across such a magic area.
>
> This started in v12, I believe, when they changed their layout engine. Given that dragging also degraded very much (too sensitive, wrong constrained drag behavior, etc.) the whole experience is rather frustrating. I don't think they will ever fix that though. I myself find solace in the stoic philosophy and the "shikata ga nai" principle [1] :)
>
> No idea about the font issue; sometimes FileMaker refuses to change the font because of the field language, but I doubt this could be the case for Verdana and it normally warns about it. If it doesn't change it with various modifier keys or doesn't copy the format with the format painter, I'd suspect something wrong with the layout.
>
> [1] https://en.wikipedia.org/wiki/Shikata_ga_nai
>
> Kind regards,
> Mikhail
>
> On 4/22/2017 2:13 AM, Paul Bostwick wrote:
>> Hey all,
>>
>> long time no post.
>>
>> I have a portal that has a few fields from related records, and some of them are formatted as checkboxes that we can enter while in find mode. I wanted to add another checkbox from another boolean field to the portal row… I copied the one next to where I wanted the new one (too lazy to even drag very far) brought up the inspector, changed the field referenced, made sure the field was IN the portal row and had not become attached to the surrounding area above (reflexively)... and then browsed the records and (here is the problem) ONLY the top row showed the new checkbox… I went in and re-checked and even over compensated in pulling the box down to be certain it was not “hanging from the top” Still no dice.
>>
>> I tried adding the field “by hand” Going to the menu bar selecting the field tool putting the field in the portal row. Specifying Checkbox as the format, Selecting the usual Value list that works everywhere else and shrinking the box to  not show the “1” but just the X in the box… Browsed… Lovely, Check box in every row. some checked some not checked… Just as hoped… Now I try to change the font to Verdana. IT WON”T CHANGE. I can click on it select Verdana and 14pts from the format menu. But it will not change. Can do the same thing in the inspector… and get the same resistance to change… Hummmmm….
>>
>> Experiment Three! Duplicate one of the Verdana ones… but do not change the field it references! It works as expected. Change the field reference (same table same relation, just scroll down to the desired field) NOW it only shows on the first portal row! Dang!
>>
>> So my interim solution is to leave it formatted “wrong” but I am worried that this might be more meaningful… File corruption? FM bug? i’ve never seen a shows on the first row but no others behavior outside of accidentally placing the field overlapping the edge of the portal…
>>
>> Thoughts?
>> _______________________________________________
>> FMPexperts mailing list
>> [hidden email]
>> http://lists.ironclad.net.au/listinfo.cgi/fmpexperts-ironclad.net.au
>
> _______________________________________________
> FMPexperts mailing list
> [hidden email]
> http://lists.ironclad.net.au/listinfo.cgi/fmpexperts-ironclad.net.au

--
Jonathan Fletcher
[hidden email]

Kentuckiana FileMaker Developers Group
Next Meeting: 4/25/17

Sent from a device not known for spontaneous combustion

_______________________________________________
FMPexperts mailing list
[hidden email]
http://lists.ironclad.net.au/listinfo.cgi/fmpexperts-ironclad.net.au
Loading...