[Lazarus] RE : Displaying text with colour and insertion point

[Mark Morgan Lloyd]

Mark Morgan Lloyd wrote:
> Ludo Brands wrote:
>>> Looking at the CmdLine component, it appears OK as a command window 
>>> (i.e. accepting keyboard input etc.) but isn't so hot when the 
>>> principal requirement is to display text pushed into the underlying 
>>> strings storage from elsewhere: in particular, there isn't a way to 
>>> force the insertion point marker to the end of what's just been output.
>>
>> Do you mean that when typing a command the output of the command is
>> overwriting part of the previous output added with TCmdBox.Write or
>> TCmdBox.WriteStream? As long as data written with TCmdBox.Write or
>> TCmdBox.WriteStream is terminated by a linefeed (TCmdBox.Writeln('') or a
>> #10 as last character) that doesn't happen. 
> 
> No, what I mean is that I want to literally put the marker where a 
> mechanical print head would put the next character. In addition I want 
> to be able to (non-destructively) backspace, i.e. the insertion point 
> (caret marker etc.) should be stepped back towards the start of the 
> line, and a subsequent TCmdBox.Write will overwrite.
> 
> Very much like a mechanical typewriter, since that was how terminals of 
> that vintage behaved. There's example output at 
> http://wotho.ethz.ch/APL-1130/2741_APL_Demo.png (it's ETH, but I don't 
> think there's a Pascal connection), I've got most of a standalone 
> terminal emulator that behaves in the same way but haven't got the 
> colour aspect working due to lack of a suitable component (and lack os 
> sufficient skill/experience to write my own).

I should have been referring to this as CmdBox rather than CmdLine, but 
I think we're talking about the same thing. For the benefit of Paul and 
anybody else following this, here's what its author (Julian) has to say:

 > > > you can stream the content to a file with Cmdbox too (SaveToFile).
 > > >
 > > > Idea:
 > > > To solve your issues you could modify the StartRead procedure a
 > > > little to permit custom caret positioning.
 > > >
 > > > Details:
 > > > The StartRead procedure enables "Input" mode showing a prompt and
 > > > setting the caret exactly after the prompt.
 > > > You could hack this part a bit and just set the Caret whereever
 > > > you want it.
 > > > Since you do just everything by catching keyboard signals, none
 > > > of the other procedures would interfere with caret positioning and
 > > > you could just call StartRead with the extra parameter to get your
 > > > effects.
 > > > Once the "input" is complete you could call "StopRead" and add the
 > > > content simply by WriteLine.
 > > >
 > > > I think the hack would take you 2 lines and should work.
 > >
 > > So that boils down to making sure that FInputX and FInputY indicate
 > > the caret position (in pixels), and FInputPos and FInputMinPos are
 > > derived from what's already on the line rather than from the prompt.
 > > Possibly a minor hack somewhere so that backspace can optionally be
 > > non-destructive.
 > >
 > > Another approach would be to push everything through the keyboard
 > > interface, i.e. characters from both the keyboard and line appear
 > > through key events (that would still need a tweak to StartRead to
 > > prevent it losing the position whenever it was called).
 > >
 > > I'm temporarily dropping this so I can look at the TRichMemo
 > > approach, since it should require minimal modification compared with
 > > my existing usage of TMemo. However I anticipate coming back to it.
 >
 > You may care more for FCaretX than for FInputX and FInputY.
 > Actually you don't have to know anything other then FCaretX which
 > you could add as explicit parameter to StartRead.
 > The non destructive backspace would be on your side since you
 > rewrite the input manually anyway. You just "set" the current
 > output line with StartRead with every change.
 >
 > FInputPos and FInputMinPos are also internal. For ordinary application
 > FInputMinPos prevents you from deleting the prompt.
 >
 > I would say...a two line hack and propably a similar code as you
 > are using now with the Memo.

I'll probably be coming back to this at some point. I'm not entirely 
convinced that for full-duplex operation a localised modification to 
StartRead() will do the job, needs experimentation.

-- 
Mark Morgan Lloyd
markMLl .AT. telemetry.co .DOT. uk

[Opinions above are the author's, not those of his employers or colleagues]