Can anyone spot why I can enter 69 Characters on a line when I defined this Multi Line INFLD as 3 line of 60 Characters. Or have I miss understood how it works?



Example program can be downloaded from here.

No hurry im done for the day, I think the sun/heats getting to me.

Unfortunately, the multi-line edit control (using by INFLD multi-line mode) does not support the concept of individual line length limits. When you specified XMAX=60 and MAXCHARS=132, that sets the width to 60 display grid units, ||H enabled wrap at the edge of the control. The problem is that the font size within the control is smaller than the font on which the grid was based. Why?

I looked up ||F and oddly, do not find it in the TYPE code list. What I do find is ||f, which ways "force fixed-pitch font". Looking at the code, I see a note "implement ||f variation of ||F that uses the actual fixed-pitch (text-mode) font".

When I change ||F to ||f in your sample program, the font becomes much bigger and the result is closer to what you were hoping for. However, because the edit control uses up space for the vertical scroll bar, and possible a couple of pixels for borders, setting the display width to 60 doesn't allow for the full 60 characters, so I added a couple to the width.

The picture below shows your program with ||F changed to ||f and XMAX increased from 60 to 62, with a single-line control using XMAX=60 for comparison. Note that for the second control, the entire 60 characters fit. In the multi-line version, I needed to add 2 to make up for the vertical scroll bar (although that might be an approximation). Also note that the plain text display (in between the two controls) uses the same exact font as the font inside the controls. (You can tell from your screen shot, but the font that it selected turned out to be considerably smaller than the standard text-mode font.)

Thanks replacing ||F to ||f and the extra 2chrs looks like it sorted one of my problems.



but :rolleyes: have two more little problems, this is where GUI programming is not as simple as good old fashion dumb terminal style split up 3 lines of 60, or im really going the wrong away about it so is anyone knows a better way please yell. (I may go and re-try XText a little later)

The idea is simple and to allow user to enter 3 lines of 60 and the text is later printed on a document again in 3 lines of 60.

Meanwhile the two problems (possible even features) I came across using MultiLine INFLD are as follows:

1. Im finding Word Wrap (whats a great feature) knocks all the texts out when split ito 3 lines later on to print on a report. (Maybe spaces are required after the word before it wraps?)


2.If I delete or clear the text part remains in the MAP3 array fields and not cleared.


Both can be seen/tried in the following updated example here.

As I say may be im trying too hard or going the wrong way about all this or doing the impossible and mix old style programming/field storage with a new style.

All suggestions welcome.. or do I make life easy and give 3 separate lines of 60, but then user looses the nice word wrap etc.

Thanks.

Why do you insist on having 60 characters in 3 lines?

Is it to print the text in a limited area (e.g. label), and the 60x3 is to control the text to not overflow?

I would use the Multi-line INFLD, save the text in a text$,s,180 and print it using //TEXTRECTANGLE where you can define the area where to print.

I just don't know if you're using GDI print.

Yes Jorge its just a limited Text Note (stored in an old fashion random data file) and is printed in several places, normally in 3 lines.

Sorry dont use GDI printing, oneday we get around to changing to it..

I hate to say this, but this is exactly the kind of thing that INMEMO was designed for, with lots of attention towards making sure the fixed-pitch text displays, prints, and stores in a nice predictable array. It's kind of ironic that we have to go to so much effort in GUI mode to try to simulate the 1 char = 1 column = 1 byte scheme which came so naturally in text mode.

That said, I think maybe XTEXT will do a better job of this. I'm not sure what you tried before, but it seems that you could set TXC'WRAPWIDTH to 60, which will make it wrap at 60 characters, independent of the font or display width (although that may look weird if the font is not fixed and the width not reasonably appropriate). You can also set TXC'MAXBYTES TO 180. But I guess the difficulty was how to limit it to only 3 lines. (Another irony is that there is actually an alternative simplified version of the underlying XTEXT control that has a line limit parameter, but it doesn't have hardly any of the other features we want). Surely there must be some way I can force it to stop at X lines though?

On the problem with INFLD not clearing the entire INFLD'ENTRY parameter, I believe it is because your MAP layout is a bit weird, and may be re-interpreted by the compiler. Here's what you have:

MAP1 INFLD'ENTRY,S,180
MAP2 LINE'ARRAY,@INFLD'ENTRY
MAP2 TEXT'LINES(3),S,60

I suspect that because INFLD'ENTRY is followed by MAP2 variables, it is being treated effectively as an unformatted variable, and thus you don't get automatic null fill past the first null. What you probably wanted was something more like this:

MAP1 LINE'ARRAY
MAP2 TEXT'LINES(3),S,60
MAP1 INFLD'ENTRY,S,180,@LINE'ARRAY

I agree I started with INMEMO whats great (and used in a lot of places), then I thought "hey new program lets bring it into the 21st Century and GUI’y it all up"... and that’s where i've started to shoot myself in the foot..(as you can tell)

XText as you say was just about there with the WRAPWIDTH at 60 and MAXBYTES at 180 but as you say I could not stop it at 3 lines.

btw, I tried the
MAP1 LINE'ARRAY
MAP2 TEXT'LINES(3),S,60
MAP1 INFLD'ENTRY,S,180,@LINE'ARRAY
and that still failed to clear the data, but dont worry if you think XText is the way to go...somehow..

Or maybe, I'll use INMEMO, but it will look funny after all the other GUI changes, so maybe its 3 simple edit boxes.

If you use three independent input fields with the TYPE$ F (fast), I guess that, when the user type in the 60 character he will be automatically positioned on the next field, maybe you could even remove the TYPE$ F from the third field avoiding the user to go to the next field.
This way you would get some kind of word wrap using three fields :rolleyes:

Apologize if, again, I'm saying something stupid, but since yesterday I just came here to relax for a while and try to forget the cahotic scenario around me ; we are about to move to a new office (tomorrow) so, I'm working in the middle of boxes and everything is out of place (except my espresso machine )

Thanks Jorge, thats not a bad idea...

Hope the move goes well, and give us a yell if you want be to pop over and help, well ok, make an espresso or two.

I've got something coming up similar to this that I have wondered what the best way to handle would be. I have a field in a claim that is 200 bytes of free form text. What is the best GUI way to handle this? Should I use multi line infld, xtext, or something else?

My concern is the wrapping at the end of an input line. I will have to add a space at the end of each line of input (except the last) before putting it in the field. Do any of the available options account for this, or do I just need to limit them to something under 200 bytes. I could also check after they come out of the field, which might actually be the simplest and best way.

Sounds similar Herman, I feel my pain is halved…

If your only limit is the overall number of bytes, then I don't see why XTEXT wouldn't work fine as-is, although your concern about wrapping suggests that you have individual line limits as well.

I'm going to try to crack the problem of limiting the number of lines, after which it seems that XTEXT would give you everything you could want - a limit on line length, a limit on overall length, a limit on number of lines.

Would XText have a similar problem with the Word Wrap as the Multiline INFLD? my tests show the "word" could still be broken up...?

But i'll let you have a play when you have time, Thanks..

In my situation, I can only pass 1 line of only alphanumeric characters, no CR or LF. If they enter this in multiple lines, I'm going to have to add a space on the end of n-1 lines so there is a space between words when I concatenate lines. There may be no way other than a check afterwards for this type of thing.

While working on xtext, is it possible to display the number of characters typed? Don't know if this would be of any value or not.

I guess the easiest thing for me would be to have only 1 line infld with maxchars = 200. Don't like not seeing everything though.

I'm not sure I understand what all the fuss is about wrapping, unless the issue is that you must ensure that soft line breaks (i.e. those established by word-wrapping during keypunching) are preserved, everywhere and for all time.

Taking Herman's case for example, if a single field of 200 characters would work, except that you can't see it all at the same time, then what would be wrong with an XTEXT or multi-line INFLD, with whatever screen width and auto-wrap? (The wrap would only be for display purposes and wouldn't affect the data, unless the user actually inserted a hard line break, but you could prevent that by capturing ENTER as an exitcode.)

To clarify: With XTEXT, I don't think there would be any need for you to add spaces at the line breaks, as long as you don't use the TXFF_TEXT_LINES (text with line breaks) format. I would use the direct buffer mode for such a small memo anyway, and it should look to you just like one string of space-delimited words. What appears as a line break on the screen would just be a space in the text string.

As for displaying the number of characters, sorry, XTEXT will display the current line and column number, but not the overall character number. (Anyone smart enough to be a pharmacist can probably do the math though.)

As for Steve's issue with the "word" being broken up, sorry, I don't understand. Both INFLD and XTEXT will word-wrap, only resorting to character wrap in extreme cases (where there are no word breaks). Isn't that pretty standard? The one common wrapping problem that people report to me is with INMEMO, where depending on the circumstances/options, it may allow a non-space in the last position of a line, or not. So if you enter under one discipline, and then later reload the memo without the MMO_NAF flag, you may get "premature" wrapping.

One other thing I should note about XTEXT: normally in a word-processing control, you set the limits based on paper size. So for example, if you have room for a block of comments that will print in a 4" by 2" rectangle, then you set up the ruler/margins/limits accordingly, but don't really worry about how it wraps or how many characters are used. As long as you use XTEXT to print it back out again, you should be able to reproduce the printer equivalent of the size/shape/style on the screen, which was sort of the whole point of word processing, wasn't it?

Are we making this too complicated?

Its amazing how the most complicated things are simple and a simple 3x60 editbox becomes complicated..

With the "Word Wrap" I was thinking XText would do much the same as this example above:



Maybe not..

It appears to me that the "problem" is simply that the editor (whether INFLD, XTEXT, or some other) doesn't know about your 3x60 array, and only sees it as a 180 character string. But you're probably printing it as 3 separate 60 char strings. So it isn't really a failure of the edit control to word wrap, but of your printing routine to word wrap.

INMEMO would solve that problem, but XTEXT would also solve it (provided you let it do the printing, which I guess is not on the table).

What you appear to want is an editor that will not only turn soft line breaks into hard ones, but will also space-fill from the line break to the maximum size of that line, so that each logical line starts at the beginning of a new element in the array (exactly what INMEMO specializes in).

I don't believe that any GUI-style edit control would understand that concept. So even if we did add a maximum lines feature, you'd still have this problem.

The one possible workaround is to use XTEXT with file mode and TXFF_TEXT_LINES, so that it output hard line breaks where the wraps occurred. Then you'd need to read those lines back into your array elements individually.

Jack, I think your suggestion will do exactly what I want. I guess I had forgotten that it would return one string, which is exactly what I need.

Thank you.

Using TXFF_TEXT_LINES may well be a good idea, i'll give it a try Monday...

If you could stop XText at x amount lines that would great, if not, dont worry I think ive used all my BBS Post Credits on this topic alone.

Have a great weekend.

I hadn't played with Multi Line INFLD until just now but it doesn't seem to work the way I would have envisioned it. I thought it would work like 3 individual XCALL INFLDs. So if I had not specified the typecode of ] to strip trailing blanks then in the example above I would have expected each line to come back 60 characters long with WORD and WRAP each on its own line.

Just throwing in my 2 cents.

I decided to use Jack's suggestion for my situation and it seems to work great. The only real problem I had was that a CR is returned on the end of the destination string. This may only happen if I use enter to exit xtext, I didn't check that out. What I did was add xtx'dst = xtx'dst[1;txc'outbytes] and all seems well.

Im still to give this a try i've got side tracked with some XTree self service combo box hiccups, but glad it worked for you Herman whats good news.