Has anyone worked out the arcane magic by which FM12 decides if an object is or is not in a portal?

[Synthezoid]

I'm doing my first major project and experiencing a great deal of trouble with keeping my portals operating correctly. I'm an old-time FM developer, almost full time since v2.1, and understand fully how portals work in every version of the program from 3-11.

It seems like there are bugs in the portals in v12. I have a field in a portal, I nudge it one pixel to the right or down, still within the portal visually, and suddenly it doesn't work any more... it doesn't repeat, and if I drag the whole portal, it doesn't move with it anymore.

My understanding was, the top left corner of a field determines whether it is in a portal or not, and in FM12 you have to drag it into the portal, portals can be moved on top of objects now without "including" them if the object wasn't dragged intentionally into the portal. But it's taking me 5 and 6 tries, dragging fields out of and back into portals, before it suddenly works, and I can't detect any rhyme or reason to when it works and when it doesn't.

It seems like maybe now an object has to be completely contained by the first portal row, ie both the top left and bottom right corners must be within it, in order to be included in the portal? This is a huge inconvenience if true... but even this has not been consistent, sometimes fields that extend down past the bottom of the first row (to eliminate verical space between the fields) repeat as part of the portal and move with it when dragged, but sometimes not.

It's like, I have a field in the portal. Nudge it up a pixel- it's not in the portal anymore. So nudge it back down a pixel- and still not in the portal. Move it far out of the portal, save the layout, move it back to it's original position when it worked fine. Still not in the portal. Do that two or three more times. Give up, go have a beer, and wonder if I want to be a FileMaker developer anymore. Come back, try the same exact thing once more, and this time it works.

Has anybody figured out the specific rules for when a field is or is not in a portal?

Unfortunately I can't attach a copy of the file, it's confidential.

If I could editorialize for a second, I'm pretty disgusted by this first major project experience with FM12. It seems like they included a couple of "gee whiz" not particularly useful proof-of-concept features (fugly layout themes that you can't customize and invariably include unwanted padding on every object? What? Making portals more easily moveable, at cost of making it nearly impossible to move a field within one without breaking it? Huh?) and made a whole bunch of giant steps backwards in terms of polish and usability. I have a lot of trepidation that FM13 will be another step backwards for someone's crazy idea of what it would be "neat" to include. I mean, working with portals is a very fundamental aspect of FM development to go and suddenly make difficult. I depend on FM for my livelihood and this experience doesn't bode well.

[Synthezoid]

Ack! No matter what I do now, I cannot, cannot, cannot place a field in the portal. Drag, duplicate, cut, paste, create new, name it. The portal DOES NOT accept the fields as being contained within it. I'm going to have to rewrite from scratch in FM11 if I can't figure this out. I hope FMI fixes this in 12v5 or 13, I can't work like this at all. This has ground my project to a complete standstill.

[bruceR]

No need for all that trouble. When struggling with this shrink field height so it is clearly shorter than row height and make sure it is clearly inside the row.

[LaRetta]

Yes, portals in 12 are different.  The are sticky which means that objects that FM as identified as belonging to the portal will move if you move the portal (unlike prior versions). It also means that if you decrease the size of a portal to half and there are fields or objects in the portal, they can disappear but still be inside the portal.  If you move an object in and out of the portal carefully, you can actually feel a 'give' like a faint tug as it is identified by the portal.  I had a top developer laugh in my face when I said that ... but I swear it is true - I have replicated it repeatedly.  You can't always feel it but once you feel it, you will know what I mean.

 

A field can be truly inside the portal but still not be identified as such but I have always been able to move it or copy/paste it and have it then be identified.  Be sure the portal is Arrange > Send to Back and the object is Arrange > Send to Front (I THINK this can help but it is only a WAG).

 

It also seems that folks are having more problems if it is a converted file (from prior versions).  You may wish to create new portals and just re-specify the fields within.  Overall, this has been reported by some but not everyone.  Hopefully it is just a single portal.

 

Also we used to be able to let objects extend below the first row but now it will not work - it again thinks it is outside of the portal.  So yes, they are more touchy.  Enough so that one shouldn't use 12 for development?  Not at all.  But the next version will be out soon (and no, I don't know exactly when) but I suspect many of the small oddities we're experiencing will have been cleaned up.

[Synthezoid]

The things where you can't have a field extend down past the bottom of the row is inconsistent. I had it working just fine for a few hours, and then it suddenly stopped again after I moved a field horizontally within the portal row.

Just now, I even had a field that I increased the font size on by 1 point, which didn't affect the size or position of it at all as it was already bigger than needed to accomodate the larger text... and the portal "dropped" it. Because I changed the font formating. Sorry, FM12 is a *DOG*. They're on 12v4 and it still isn't fixed.

I definitely think it's a serious enough concern to avoid developing on it... I have wasted over 2 hours tonight just on trying to get the fields in a single portal to show up right, something that would have taken 15 seconds on any other version of FileMaker within the last 15 years. Not being able to place fields in portals is an extremely serious problem. It's just not ready for primetime, it's v.4 and it still acts like an early beta. I very rarely feel this strongly about software, but I'm honestly disgusted that they would release this, let alone let it get to rev 4 of the major release without bothering to fix these dealkiller bugs.

[Fitch]

Thanks for opening up this topic. I agree, portals are seriously annoying to work with now. Layouts in general are more annoying to work with IMO.

 

I think LaRetta's advice about object stacking order and Bruce's advice about boundaries pretty much covers it. I admit, there are times when I end up dragging fields completely out of the portal and back in to make it stick, and I've wondered like you, wtf is the secret formula.

 

I'm optimistic about the next version, though. We'll see. I am working almost exclusively in FM12 now. You do get used to it.

[ron G]

I've been having similar problems with portals.

I've been developing a membership app for about 1 1/2 years. 

Today, for no apparent reason, FM refuses to bring data from a table into the portal.  I should say, it refuses to bring 'some' data into the portal.

 

As you can see, each Visitor has information in the 'brown' fields except Allen, Paul.

I added his information in the same table that holds the same information for Edwards, John and Newguy, I.M..  But, Allen's information does not fill the fields?  Why?  I don't know.

 

I tried 'nudging' the fields.  I tried, copying and pasting the fields.  I tried deleting and recreating Allen's record.  I tried recreating the portal.  (that was a nighmare that resulted in using a backup copy of the app... I never could recreate the portal).... 

 

Yep, Portals in FM are seriously screwed up and you can add me to the growing list of dissatisfied developers who waste hours of time trying to do something that should be quick, easy and reliable.

 

[Fitch]

I suspect there is something going on with the data in your case.

[LaRetta]

I agree with Tom ... most times, it is something which is overlooked.  I've worked on something for several hours, only to post here and have others spot the obvious issue immediately - dumb things, too.  

 

Missing data from a single record (when two prior rows work) indicates data issue, record-commit (thus lack of refresh/flush cache)  issue or index issue ... nothing to do with the portal at all.

[Fitch]

Back to the original topic... I believe it was in Matt Petrowsky's DevCon session he mentioned that nudging an object with the keyboard can disconnect it from the portal -- drag it with the mouse to re-connect it. Yay, carpal tunnel!