Hi Guys

Is there a way to have a field automatically condense,compress or squeeze text entered by a user if it is longer than the field size?

thanks

fastest

No but you might outfit the field with a scrollbar...

--sd

... unless you use a plugin that allows "On-Exit" functionality (there it goes again, S

I don't think the problem is triggering, Jerry. That could be done with version 7's auto-enter (replace existing). The question is what to trigger.

That could be done with version 7's auto-enter

Indeed, but as Albert Harum-Alvarez started one of his articles in Advisor - is everything a nail, when holding a hammer in your hand.

So just because you initially stumble over Copy/paste, repeating fields and the lack of eventtriggers in the sence MsSQL defines them <sarcasm>...there is no apparent need for further and more humble SEARCH for alternative methods.</sarcasm>

-sd

comment: Right, I hadn't thought of that. I really need to get up to speed with v7!

fastest: If you explain how you might like to condense your text, we might be able to help write a calculation for it.

J

It is basically fitting in as much text as possible for viewing (browse) and printing. Where applicable I have used the scroll bar. But this is for a fixed length field. Sorry I couldn't answer quicker.

Fastest

Well, just to give an example of what comment suggested, you might set up this field to Auto-enter a calc (uncheck Do not replace existing value):

Case ( 

  Length ( theField ) > 80 , 

   Substitute ( theField , " " , "" ) , 

   theField 

) 

which will strip the entry of spaces if the text entered is greater than 80 characters. Maybe that's not the best plan in your case, but you get the idea.

J

QuinnTech...I guess what I am asking for is to change the format of the type to condense to allow as much of the info as possible. So that it doesn't eliminate the spaces between words. Thanks sorry for not being as clear from the beginning.

But change of Font as well as style is posible. The calc'functions might have something to offer in this direction:

TextStyleRemove ( text ; styles )

TextFont ( text ; fontName {; fontScript} )

TextStyleAdd ( text ; styles )

--sd

You could try something like:

TextStyleAdd (

field ;

Case ( Length ( field ) > 100 ; subscript ; Length ( field ) > 75 ; condense ; plain )

)

Don't know how much that will help.

Comment,Soren and of course QuinTech thanks alot this seems to do it.

But now I'm getting picky. Is it possible to have a variable Condense format?

Meaning by altering the numbers the compression of the type isn't as tight?

The below is what I have now.

TextStyleAdd (

namelast ;

Case ( Length ( namelast ) > 44 ; Condense; Plain ; Length ( namelast ) > 36 ; Condense ; Plain )

)

Oh, no...

First, I hope you won't be offended - but I wasn't altogether serious, and didn't expect you to take this seriously either. Condensing/resizing text automatically sounds to me like an atrocious idea - surely, as a user, I would jump out of my seat if any application did this to me!

Second, and this IS serious, your Case() formula is incorrectly structured. Plain is the default choice, and it should appear only once, at the end. Since apart from Plain the only other choice is Condensed, only one condition is required, and only one condition will be considered. So pick either 44 or 36.

Finally, and again I am just being silly here - but feel free to use it if it works for you:

TextSize (

field ;

Case (

Length ( field ) > 20 ; 9 ;

Length ( field ) > 10 ; 10 ;

12 )

)

--- ADDENDUM --

One thing to be aware of when using text formatting functions: the formatting becomes part of the data. Unlike formatting a field in Layout mode, this formatting sticks. If you put this field on another layout, and format it to show big 24pt. characters, it will ignore the layout settings and be as small as the TextSize() function dictates. Likewise when copying - it will be copied as styled text, and retain the style when pasted.

Comment, what we have here is a failure to communicate...purely out of my ignorance. I didn't even catch your joke that's how good I am. But with your help and others this forum has helped this user of FMP become a better user and hopefully more in the future.

Now your ADDENDUM scares me since this info is used in many places. I don't think I even want to change the size. What do you do when there is more info than a field can hold in browse mode or printing, other than enlarge the field?

Thanks again

Fastest (by the way my user name is a joke...since I obviously am not the fastest)

What do you do when there is more info than a field can hold in browse mode or printing, other than enlarge the field?

For browsing, add scroll bars to the field. For printing - enlarge the field.

Filemaker is a very flexible program, but a page layout application it is not. Ultimately, data gets precedence over form. That said, there are all kind of tricks and shticks you could try (at a price), for instance use a calc field to DISPLAY the data (the original data is untouched, the calc field adjusts its size). You can probably find a couple of more of these if you search the forum.

"Is there a way to have a field automatically condense, compress or squeeze text entered by a user if it is longer than the field size?"

No. But there is no need to.

In browse mode FMP will automatically expand an active field to display the contents, unless the field is formatted to display a scroll bar in which case it isn't necessary.

For previewing and printing, you do exactly the opposite: make a print layout that is large enough to accomodate all the text you ever expect (you have up to 10 full pages for each record to expand into, so it's pretty generous). Then use the Sliding/Printing feature to make the fields and body part shrink-fit to the data in each record.

Well it looks like I am leaving all as is. It's just not worth it. Maybe I'll try the Calculated field one day.

Thanks to all

Fastest