Not sure if I've been staring at a screen for too long, but if I have a text string, e.g., 200 characters long, and I use the FMT command shouldn't I "see" @TM put into appropriate place in the text variable.

For some reason in this simple exercise I don't see my Text Mark.

For example,

TXT=some string variable that is greater than 60 charaters….." Txt=Fmt(Txt,"T#60") *

I don't see a TM being inserted every 60th position or so and as a result I can't do some other manipulation..e.g.

*

Convert @TM to @VM in TXT

CNT=Count(TXT,@VM) + (TXT NE ) * Thanks for looking at this. Any comments, fire away, Ray Chan OI32, 4.12 Win2K, Win2K Services </QUOTE> —- === At 03 NOV 2002 01:20AM Ray Chan wrote: === <QUOTE>Here's something else I should add. I'm entering new text into an EditBox. It seems that when I xlate to this data the first time, I can successfully "format" the data via the FMT command (i.e., FMT(txt,'T#60) ) However, if I go back to the EditBox and save it with new data, then when I xlate to the data again, my FMT doesn't work. Nada.. I don't see the @tm injected and my process which looks for @tm fails ;-( Here's something I just tried: ln1: convert @tm to @vm in Txt (or swap @tm with @vm in Txt ) ln2: Txt=Fmt(Txt,"T#60") ln3: Convert @TM to @VM in TXT If I do the above a swap or covert, fmt, and then a convert, I get the result that I'm after. I see my @tm, etc. I'm happy that it works, but I don't understand why. Would someone care to shed some light why the above works. Why do I need to do two converts? I'm reluctant to send this, but at this point, I very curious. I don't think that I'm going crazy. Oh well, Ray Chan </QUOTE> —- === At 03 NOV 2002 04:51AM Oystein Reigem wrote: === <QUOTE>Ray, Why is it you need @TMs in your data? To avoid the text going beyond the right border of the edit box? If you untick Horz. scroll bar the edit box will wrap the text for you. - Oystein - </QUOTE> —- === At 03 NOV 2002 05:33AM Oystein Reigem wrote: === <QUOTE>Ray, I've never used Fmt T. I tried it, to see how it works. It does insert @TMs. You said you didn't see them. If you show the result in an edit box, you won't see them, except that the text will wrap at each @TM. FMT right-pads with spaces so each element becomes the same length. This is to be expected. I don't know if it's desireable in your case. FMT tries not to chop words in two. But if a word is too long (]60 chars in your case) it will. It does not insert any hyphen. FMT can make mistakes. I tried to format some text as T#10. Here's the result. To make it easier to show you what happened I've changed all spaces to periods: Input: "Det.var.en.gang.en.liten.pusekatt.som.var.så.forferdelig.lei.seg" Output: "Det.var.en gang.en… liten….. pusekatt.. som.var………….. så…….. forferdeli g.lei.seg" As you can see one of the elements became 21 chars long instead of 10. - Oystein - </QUOTE> —- === At 03 NOV 2002 05:37AM Oystein Reigem wrote: === <QUOTE>Ray, Another comment: Whatever it is you want to use FMT for might not work well if the font is a proportional one. - Oystein - </QUOTE> —- === At 03 NOV 2002 12:53PM Richard Hunt wrote: === <QUOTE>Ray, I am confused in a bad way… 1) Xlate to an EDITBOX ??? 2) If you convert @TM to @VM and then do a FMT… it will format all the values (multi values) within that string individually. After the convert, you might end up with many short length multi valued strings, and their multi valued lengths might be too small for the FMT to make any changes. If you could explain a bit more, or even include more code, it might shed some light to your problem. Just want to let you know that I use the FMT using the "T#" format code, and it works fine for me. </QUOTE> —- === At 03 NOV 2002 01:02PM Oystein Reigem wrote: === <QUOTE>Richard, Could you do me a favour and try Fmt( "Det var en gang en liten pusekatt som var så forferdelig lei seg", "T#10" ) ? - Oystein - </QUOTE> —- === At 03 NOV 2002 01:18PM Ray Chan wrote: === <QUOTE>Oystein, Why is it you need @TMs in your data? To avoid the text going beyond the right border of the edit box? If you untick Horz. scroll bar the edit box will wrap the text for you. I use the @tm to maintain backward compatibility with old data from AREV and older processes that we have converted to OI. For example, in AREV, when data were entered into a text field AREV put the @TM in the appropriate place. Because of our printing routines, we would convert the @tm to @vm and put the data into a table within our report. Well in OI when we enter data into an EditBox, I guess we discovered it doesn't use @TM by default. Most of testing was done with old AREV data and the printing was perfect because the data fitted our preconceived notions . This proves that one can never do enough testing. We played with using the "T#n" conversion in the EditBox, but this was unsatisfactory as it left the little "u" character. The first time you enter the data no, then go back in to save and come again whamo. So we got rid of the "T#n" conversion. Any case, we finally changed our routine to accommodate the printing of old and newer data. We first strip out all @tm, if there are any (old data yes, new data no), then we use the FMT command to format our data using @tm as the data must fit into a fix-lenght area of our report. Then we convert the @tm to @vm for our printing (or something like that). Sofar this seems to solve our problem . It does insert @TMs. You said you didn't see them. If you show the result in an edit box, you won't see them, except that the text will wrap at each @TM. We are not inserting the @tm into an EditBox. We are reading data and then use the FMT(TextData,'T#60') to format the data. As I said, if you do this before you make any new change, you will see the TM. However, after you modify the data and extract the data again for manipulation, we don't see the @TM being inserted. I know this sounds strange, but it's true. I believe your story about the "tick mark" not being there okay . Anycase that's why we had to alter our routine (see above.) Oh yes, I haven't forgotten, but been busy. I will talk to you later, Tally ho and Det er bra ??? Ray </QUOTE> —- === At 03 NOV 2002 02:01PM The Sprezzatura Group wrote: === <QUOTE>Det var en gang en liten pusekatt som var sa forferdeli g lei seg The Sprezzatura Group World Leaders in all things RevSoft </QUOTE> —- === At 03 NOV 2002 02:03PM Oystein Reigem wrote: === <QUOTE>Ray, We first strip out all @tm, if there are any (old data yes, new data no), … New data maybe. If the user hits enter while keying in data in the edit box a @TM will be inserted. A newline. A paragraph mark. A deliberate attempt by the user to start a new paragraph. When you strip out all @TMs you rob him of his formatting. - Oystein - </QUOTE> —- === At 03 NOV 2002 02:59PM Richard Hunt wrote: === <QUOTE>Oystein, Here is the result. "Det var en gang en liten pusekatt som var så forferdeli g lei seg" Exactly what I would expect. The " " being the text mark (@TM). You got me curious now… I see no problem. Are you having problems with it? </QUOTE> —- === At 03 NOV 2002 03:30PM Ray Chan wrote: === <QUOTE>Richard, Well when I said I Xlate to an EditBox, what I meant is that I'm using Xlate to access the data that was created via an EditBox. Well I agree this seems all very strange, but with my old code and old data I could get the result I would expect. However, if I go back to the Data and make some change to it, then using the old code, the process would falter. No kidding… My original code was something like this: Txt=Xlate(FileName,ID,1,'X') Convert @TM to @VM in TXT CNT=COUNT(TXT,@VM) + (TXT NE )[/i] This, of course, as you see would not work with new data entered via OI (EditBox) since there are no TM. So then we preceded before the Convert above this line. Txt=Fmt(Txt,"T#60") As noted earlier, this only worked the first time and before any changes were made to the data (don't know why. Maybe you might know.) After you change the data in the EditBox, the Fmt didn't seem to function at all. That was yesterday . Well I agree it should work. As it is simple and straightforward. But for me at least I had to resort to some work-around ;-( Oh well, thanks for your help, Ray Chan </QUOTE> —- === At 03 NOV 2002 04:57PM Oystein Reigem wrote: === <QUOTE>Sprezzatura, I can't see your trailing spaces. Here with me one of the elements got too many trailing spaces. - Oystein - </QUOTE> —- === At 03 NOV 2002 05:01PM Oystein Reigem wrote: === <QUOTE>Ray, If I were you I'd put a debug statement before that Fmt statement. Then I could see exactly what the content of the Txt variable was - before and after converting with Fmt. - Oystein - </QUOTE> —- === At 03 NOV 2002 05:35PM Ray Chan wrote: === <QUOTE>Oystein, Ahhhh, too bad you're not here to help. I had a DEBUG before, after, on top and below to trace this down. There might be a simple explanation for what I see or don't see, but for now it escape me. This might be job for Jack Daniel. Ciao, Ray </QUOTE> —- === At 03 NOV 2002 06:00PM Oystein Reigem wrote: === <QUOTE>Ray, What's in Txt before? Just ordinary run-of-the-mill characters? No delimiters? (What about spaces?) - Oystein - </QUOTE> —- === At 04 NOV 2002 12:38AM Ray Chan wrote: === <QUOTE>Oystein, Unfortunately, nothing is in the string. As I said, at "one" point in time before any changes are made you see the @tm. Then after any changes are made, nothing and I mean NOTHING shows. I'm there is some explanation, but maybe this is a mystery of life. Ray </QUOTE> —- === At 04 NOV 2002 03:02AM Oystein Reigem wrote: === <QUOTE>Ray, According to you - this is your code: … Txt=Xlate(FileName,ID,1,'X') Txt=Fmt(Txt,"T#60") Convert @TM to @VM in TXT CNT=COUNT(TXT,@VM) + (TXT NE '') … When is it the Txt variable contains nothing? After Txt=Xlate(FileName,ID,1,'X') or after Txt=Fmt(Txt,"T#60")? And what is nothing? The null string (a string of length zero)? - Oystein - </QUOTE> —- === At 04 NOV 2002 03:45AM Don Miller - C3 Inc. wrote: === <QUOTE>Oystein / Ray: When I do this kind of stuff, I put the text into a dialog-box that uses a mono-spaced font (Courier New usually). On return, I uppdate the TEXTVAL property which converts CR/LF (0D/0A) to @TM. I frequently do this when the data itself is MV'd (e.g., comment lines within a multi-valued array). In this way, you can use normal "windoz-ie" characters like tabs and cr/lf or cut and paste from other sources. Before returning, the process checks the length of the text itself to make sure that the errors in FMT don't creep in .. as you observe that they sometimes do. This was never a problem in AREV but OI's a horse of another color (not always the expected one, I might add). Make sure that you turn off horizontal scrolling in your textbox so that auto wrap works. We resize the textbox window in the create event to make it fit with the desired final format. This seems to work in both OI 16 and OI 32. HTH Don M. BTW, if alcohol is a crutch, then Jack Daniel's is a wheelchair D </QUOTE> —- === At 04 NOV 2002 05:10AM Oystein Reigem wrote: === <QUOTE>Don - you seem to agree with me there are bugs in Fmt "T#n". Should we ask Revelation to get the "T#n" formatting corrected? I use Fmt very little myself, and not "T#n". Sprezz - does Slist use Fmt "T#n"? At one time it did. I don't know if it does now. - Oystein - </QUOTE> —- === At 04 NOV 2002 10:18AM Donald Bakke wrote: === <QUOTE>I don't *think* this will help Ray's current situation because he is trying to massage old data, but we have a routine we wrote called Format_Rec_Text() that takes any string and computes where the line breaks should be based on the font and a theoretical width of an editbox. It uses the Utility("TEXTREC") message to help get the job done. We wrote this so we could achieve a true WYSIWYG output from our application to an OIPI report. Ray, this should be included with your copy of FrameWorks. If you don't have it and you are interested then let me know and I'll send it to you. [email protected] SRP Computer Solutions, Inc. </QUOTE> —- === At 04 NOV 2002 10:22AM The Sprezzatura Group wrote: === <QUOTE>Another thing you might want to look at is the TEXT/TEXTVAL difference when using an EDITBOX. If you use DEFPROP, then you are using TEXTVAL, which converts the data to cr/lf combinations. However, a straight FMT should work at the appropriate character position. The Sprezzatura Group World Leaders in all things RevSoft </QUOTE> View this thread on the Works forum...