When I run it it shows a list of projects (@select). Then I pick one and enter into that project.

The project for me is a "context". So, when I enter it, it brings back to me all the histories from THAT project. So, directories for all drives are set according to that project . Also ALIAS and many other things.

When I leave the project, it saves it all back.

So far, so good.

However, I'd like to restore the SCREEN of the project, as I left it last time I entered it.

Currently I do it using an EXE of my onw.

But I found a BTM for doing that. This is an old BTM that I inserted at the end of this message.

The BTM work but, it DOES not reposition the cursor position (the prompt) where it was.

Do you have something similar ? Or other idea ?

Follows the original btm :

---------------------

:: SCAP.BTM Utility to capture and restore the screen contents
:: By: Frederick Sohn
:: Date: 27 Mar 96 05:18:00
::
:: Slightly modified from SCREEN.BAT by Stian Jakobsen, DOS World May
:: 1996 p. 22
::
:: Here's a neat little *.BAT, just copied from a magazine and slightly
:: modified. It captures and then restores the current screen. Anybody
:: want to improve upon it as a 4DOS *.BTM? The magazine editors would
:: like to find the author; all they know is that he posted it from Norway.

You can get the current cursor position using the %_ROW and %_COLUMN
variables. And restore the cursor using SCREEN

-Scott

JOSE ADRIANO BALTIERI <> wrote on 07/28/2010 10:00:42
AM:

> Hello !
>
> I have a kind of a project manager built upon 4NT (now TCC).
>
> When I run it it shows a list of projects (@select). Then I pick one
> and enter into that project.
>
> The project for me is a "context". So, when I enter it, it brings
> back to me all the histories from THAT project. So, directories for
> all drives are set according to that project . Also ALIAS and many
> other things.
>
> When I leave the project, it saves it all back.
>
> So far, so good.
>
> However, I'd like to restore the SCREEN of the project, as I left it
> last time I entered it.
>
> Currently I do it using an EXE of my onw.
>
> But I found a BTM for doing that. This is an old BTM that I inserted
> at the end of this message.
>
> The BTM work but, it DOES not reposition the cursor position (the
> prompt) where it was.
>
> Do you have something similar ? Or other idea ?
>
> Follows the original btm :
>
> ---------------------
>
> :: SCAP.BTM Utility to capture and restore the screen

> :: By: Frederick Sohn
> :: Date: 27 Mar 96 05:18:00
> ::
> :: Slightly modified from SCREEN.BAT by Stian Jakobsen, DOS World May
> :: 1996 p. 22
> ::
> :: Here's a neat little *.BAT, just copied from a magazine and slightly
> :: modified. It captures and then restores the current screen. Anybody
> :: want to improve upon it as a 4DOS *.BTM? The magazine editors would
> :: like to find the author; all they know is that he posted it from

I'm tempted to (tonight perhaps) write a pair of functions for
4CONSOLE) to save/restore the console together with buffer size,
window size, attributes (colors), and cursor position. It wouldn't be
hard (probably fun). The file would have to be in a binary format,
probably not readable.

I'm tempted to (tonight perhaps) write a pair of functions for
4CONSOLE) to save/restore the console together with buffer size,
window size, attributes (colors), and cursor position. It wouldn't be
hard (probably fun). The file would have to be in a binary format,
probably not readable.

| Actually, if you put the text into the file first, followed by the
| attributes and separated the two with a NULL, you could TYPE the
| file or LIST it to see the contents in a human readable form.

Even better, to keep the format fixed, the attributes (buffer and window
sizes, etc.) could be in front (with numeric information in decimal),
followed by the buffer contents.
This brings up an interesting point: if I understand things correctly,
the following relationships are always true between TCC and 4console.dll
internal variables:

|Actually, if you put the text into the file first, followed by the
|attributes and separated the two with a NULL, you could TYPE the file or
|LIST it to see the contents in a human readable form.

I suppose, but ReadConsoleOutput() gets them both in an array of
CHAR_INFO structures. It'd be easiest, most efficient, and fastest to
WriteFile() that whole array to a file. And they can be restored all
at once with WriteConsoleOutput(). And there's always SAVECSB if you
want just the text.

Scott Mintz

That's true. However, I was thinking of separate API calls to
ReadConsoleOutputCharacter() and ReadConsoleOutputAttribute() and the
correspondng Write calls. If you don't really care about the actual
contents then your method is better.

-Scott

vefatica <> wrote on 07/28/2010 04:47:54 PM:

> On Wed, 28 Jul 2010 15:14:30 -0400, samintz <>
> wrote:
>
> |Actually, if you put the text into the file first, followed by the
> |attributes and separated the two with a NULL, you could TYPE the file

> |LIST it to see the contents in a human readable form.
>
> I suppose, but ReadConsoleOutput() gets them both in an array of
> CHAR_INFO structures. It'd be easiest, most efficient, and fastest to
> WriteFile() that whole array to a file. And they can be restored all
> at once with WriteConsoleOutput(). And there's always SAVECSB if you
> want just the text.
>
> I could also restore
>
> 1. buffer size
> 2. window size
> 3. window position
> 4. window title
> 5. cursor position
>
> ... I suppose even the command history, dir history, aliases, and
> functions but that might be going overboard and I doubt a
> one-size-fits-all approach to doing that would really fit all.
>
>
>
>

| I suppose, but ReadConsoleOutput() gets them both in an array of
| CHAR_INFO structures. It'd be easiest, most efficient, and fastest
| to WriteFile() that whole array to a file. And they can be restored
| all at once with WriteConsoleOutput(). And there's always SAVECSB
| if you want just the text.
||
| I could also restore
|
| 1. buffer size
| 2. window size
| 3. window position
| 4. window title
| 5. cursor position
|
| ... I suppose even the command history, dir history, aliases, and
| functions but that might be going overboard and I doubt a
| one-size-fits-all approach to doing that would really fit all.

The OP states that he uses alternatate set of environment variables and
aliases for each project, but already has code to save and restore them.
However, he also was interested in restoring not only the text on the
screen, but also its colors. That job was much simpler in the old days when
screen buffers were stored at 0xB0000 in readable graphics adapters, with
one byte for color and another byte for text character. If something like
that is possible with current systems, that's what I understand the OP's
desire to be.
--
Steve

The OP states that he uses alternatate set of environment variables and
aliases for each project, but already has code to save and restore them.
However, he also was interested in restoring not only the text on the
screen, but also its colors. That job was much simpler in the old days when
screen buffers were stored at 0xB0000 in readable graphics adapters, with
one byte for color and another byte for text character. If something like
that is possible with current systems, that's what I understand the OP's
desire to be.
--
Steve

While this could be run as an .EXE, I could put it into a .DLL, which could be called with @winapi. The ultimate would be to have it as a plugin, but I tried once to convert the Delphi Plugin Template to PowerBASIC, but my skills are not that good for that. Thank goodness that the Plugin SDK came with a Delphi template, at least. Come to think of it, this should be fairly easy to implement as a plugin with Delphi.

| The OP states that he uses alternatate set of environment variables and
|aliases for each project, but already has code to save and restore them.
|However, he also was interested in restoring not only the text on the
|screen, but also its colors. That job was much simpler in the old days when
|screen buffers were stored at 0xB0000 in readable graphics adapters, with
|one byte for color and another byte for text character. If something like
|that is possible with current systems, that's what I understand the OP's
|desire to be.

The console is truly a window. I doubt it has anything comparable to
the old hardware video buffer. And the console screen buffer may be
much larger than the part you see.

I have something that works ("SAVECON filename" and "RSTRCON
filename"). It has absolutely no error control yet (but I think
little can go wrong as long as you give them filenames) and the only
help is via the CONHELP command. And I might have fixed a bug in
CONSIZE inadvertantly.

There are new (32-bit) 4console.zip files at

ftp://lucky.syr.edu/4plugins/4console.zip

and

ftp://barnyard.syr.edu/pub/vefatica/4plugins/4console.zip

I'd like some feedback (thanks).

As it turned out, with my big (80 x 9999) screen buffer, I couldn't
read/write the whole thing at once (neither as CHAR_INFOs nor as CHARs
and attributes separately. The APIs just won't do it. So I'm doing
it line by line. It's still fast, in my case under 1 sec. For that
buffer size, the file is just over 3MB.

I have something that works ("SAVECON filename" and "RSTRCON filename"). It has absolutely no error control yet (but I think
little can go wrong as long as you give them filenames) and the only
help is via the CONHELP command. And I might have fixed a bug in
CONSIZE inadvertantly.

Has anyone tried these? I updated them a couple times; they're more robust. One thought is to save the console screen buffer only as far as the current cursor row; presumably it will be empty thereafter. That can make it quicker (though it's already fast) and make the files smaller. Upon restoring, it'd redimension/reposition the console as it was but only write down to the saved old cursor row (I could precede that with a "CLS /C" in case the current console has output past the restore point.