[fpc-pascal] Drawing window out line
Tomas Hajny
XHajT03 at hajny.biz
Thu May 22 12:33:04 CEST 2014
On Thu, May 22, 2014 10:51, Mark Morgan Lloyd wrote:
.
.
> Going back to the earlier message:
>
> > note : we can not use Video and CRT Unit both in single unit. i want
> > to use CRT unit only.
>
> Perhaps somebody would like to confirm this, but my understanding is
> that Video and CRT can't be used in the same /program/, not just the
> same /unit/. Unless there's a very good reason, I'd have thought that
> using FreeVision would have been the best way to go, since this already
> knows about things like window outlines and stands a reasonable chance
> of having already sorted out e.g. codepage selection issues.
.
.
Two comments:
1) (In)compatibility of units Video and Crt is platform (implementation)
specific thing. They can be used together without any issues on platforms
providing sufficient access to the console (i.e. basically anything except
for *nix platforms which provide limited set of console features
accessible across the different operating systems and technical
implementations) _as_long_as_you_know_what_you_do_ (i.e. you should
understand that changing the video buffer without UpdateScreen intermixed
with Crt.Write calls will obviously not give a reasonable outcome and
results of Crt.Write may not be accessible for reading via VideoBuf^).
Among others, this includes Win32 as well as far as I know.
2) FreeVision has its limitations too - especially when talking about
stuff like Unicode (which may be handled better in unit Crt due to fewer
limitations/more limited set of features provided there). Unfortunately,
that's partly valid also for unit Video - it would need to be
extended/updated for multibyte encoding, because the current
implementation hard-codes that the TVideoCell = word. I have started
working on extending and updating unit Video to cover this and allow
building unit Crt functionality on top of unit Video (and Keyboard) in
rather generic manner very long time ago, but I have never finished it
because it required quite a lot of time (in order to make it working on
all supported platforms) which I didn't have. Some concepts in this area
are still not completely obvious, because we may not have generic
(platform-independent) functionality for e.g. finding out how many display
characters are necessary for a Unicode string which may not be normalized
yet (i.e. it may include standalone accents which need to be combined with
the main letter, etc.).
Tomas
More information about the fpc-pascal
mailing list