This actually started in FM11... I don't think FileMaker thinks this is a bug. But I consider it another bonehead change. I can't think of any reason to have done this.
I think the limit is actually 8 tabs on the Mac. It may be different in Windows. It has nothing to do with monitor size. I was a bit annoyed when I first experienced this, as I often list my formula comments neatly tabbed to the right. I also like my code lined up a certain way. I often hierarchically tab my formulas to aid in expressing the purpose. While it is a minor issue I did like it better the old way.
I tried it in both 11 and 12 on Windows. FM lets me inserts as many tabs as I want...it just reflows based on the width of the calculation dialog window.
Here is what I see for a typical calculation using tabs in FMP10:
And here is what I see for the same calculaion in FMP12:
I have about 100,000 lines of code in custom functions alone that contains about 300,000 tab characters and most of them appear screwed up in FMP12.
This is quite upsetting to me!
This has been a real bug bare of mine for years and the reason I prefer to layout out calculations in Windows rather than the Mac. By the way, are you using a Mac?
The way it used to work is that you could lay out calculations with pretty much as many indents (tabs) and characters as you wished in the Windows version of FMP - using nice big windows! In the Mac version there used to be a critical no. of characters (can't remember off hand how many) once you used a tab and when you went over the character threshold it just wrapped and your nicely laid out calculations looked a mess. Particularly frustrating with custom functions.
When I previously reported this in the old forums here I received plenty of 'this works fine on my Mac' messages, but it wasn't just the number of tabs, it was a tab combined with a number of characters you entered on each line.
A quick test now on Mac FMP 12.0v2 seems to have a maximum of 12 tabs on a calculation line, providing there is only a few characters between tabs. However if you then add a string of characters between some of the tabs, this number reduces and the text wrap occurs.
Please report this on the forums at http://www.filemaker.com/support/forum_selection.html and if you can confirm you've done this, I'll support your posting with some more detailed testing.
I have reported the issue and I don't think it was via the link you provided. I will report it there as well.
Will you please join me in getting this fixed?
I figured out what is happening. A tab moves the cursor to the next integer value that is a multiple of 6 pixels on the screen. In FMP12, you can type 12 tabs and text stays on the same line. On the 13th tab it displays on the next line. So 12 tabs is "at or over the limit." Therefore, somewhere between 66 pixels and 72 pixels it resets to the next line.
Dig a little deeper...
FMP uses Lucida Grande 11-point font to display calculations on a Mac.
Type the following comment starting on a new line:
It takes 67.67 pixels to display. If you type a tab after this, it stays on the same line.
Now type the same comment with one more period at the end:
That takes 68.37 pixels to display. Adding a tab at the end causes the reset.
So 68 pixels is the reset point.
To generalize, typing any characters that ocupies less than 68 pixels stays on the same line. After that point, all text displays normally except for a tab which starts displaying on the next line.
Text display gone amuck!
Probably not the best day to do this (Saturday), but we've added to your posting in the 'Report a Problem' section in the FM Forums. I see we've already had the 'this is a known problem' comment, but hopefully someone from FMI will read it and understand where we're coming from.
Funny how we're expected to just accept a 'known bug'. We reported this in FMP 11.0v1, we got to 11.0v4, now 12.0v2 and it is still a 'known bug'.
Our worst experience of this was failing to complete a £30k job due to a 'known bug' with ActiveX command in 2008. We were working with another FM developer using one of their products and we managed to completely isolate the problem and supply simple example files to FMI. We know the issue reached the US 'bug meeting', but their response was that they were not going to look at it prior to version 10's release. We've never dared go near ActiveX again and the project was canned by the client. This cost us (and the other developer) hundreds of hours tracing the problem and then trying to work around it.
But to put it in perspective, we have a really good FileMaker team in the UK and, from what we read, things are far worse with other companies and their products. Even after 25 years of using FileMaker, there are still times it blows us away and it is still a pleasure to introduce it to new customers.
The frustrating thing is that marketing always seems to win over technical and it could be so much better!