Hi Gerry,

My answer to question five, the following alternative approaches spring
to mind:

1 Repackage your C++ Forth as a DLL and host that within the VB
process. You should be able to provide a simple Forth/VB interface
based on TYPE, EMIT, ACCEPT, REFILL, etc. You will have to provide
other words (ie. functions/callbacks) for driving the GUI. A separate
makefile can be used for generating a standalone EXE Forth. You can
debug your Forth using the C++ debugger by specifying VB.EXE as the
debug process.
2 Provide a mapping to a C++ GUI library, such as MFC, within your C++
Forth. This sounds quite awkward and a lot of work.
3 Devise a foreign function interface within your Forth so that you can
make direct Win32 OS calls. Lots of work but will give the most
flexibility.

My view is that GUI coding can be very time consuming and fiddly.
Driving a simple bespoke interface such as an Othello board should work
fine using streams. If you are happy with your approach then stick
with that.

John Harper wrote:

I take this all back. I misread what was going on with
the character lengths and arraynesses of a.

I guess I shouldn't post in a hurry, sigh.

Dick Hendrickson

Dick Hendrickson wrote:

Dick Hendrickson wrote:

But I'm still a little confused. If vstring is declared as a pointer to a scalar
(the scalar being a length-1 character), then how can it accept an array subscript?

Rich

...

Rich Townsend wrote:

vstring is a scalar character variable of length one.
vstring(1:nc) isn't an array subscript, it's a character
section selector. They jusy happen to have the same
syntax and you need to look at the declaration to tell
what "(1:nc)" really is. Since the length of vstring is
one, nc must be less than or equal to 1 to be valid.

Dick Hendrickson wrote:

Rich Townsend wrote: