Fake Console Application

[Jeff Gaines]

I want to create something that acts like a Command Window where users can
enter text and on hitting return some action will be taken depending on
the text that was entered. I will also want to write back to the
'console'. I don't want users to be able to cursor all over the console -
I want to capture the up/down keys and put previous text in to the console
- in fact I want it to pretty well be a command window but with control
over what goes into it.

I've tried a RichTextBox but the user can move the cursor at will. I have
also tried a User Control with a disabled RichTextBox and a Text Box for
input at the bottom - control is much better but the user doesn't get the
feel that he/she is typing in to a console window.

Has anybody written/come across anything like this? I have had a look on
Code Project but I suspect I may not be using appropriate search terms.

Many thanks.

 

[Peter Duniho]

I want to create something that acts like a Command Window where users
can enter text and on hitting return some action will be taken depending
on the text that was entered. I will also want to write back to the
'console'. I don't want users to be able to cursor all over the console
- I want to capture the up/down keys and put previous text in to the
console - in fact I want it to pretty well be a command window but with
control over what goes into it.

I've tried a RichTextBox but the user can move the cursor at will. I
have also tried a User Control with a disabled RichTextBox and a Text
Box for input at the bottom - control is much better but the user
doesn't get the feel that he/she is typing in to a console window.

Has anybody written/come across anything like this? I have had a look on
Code Project but I suspect I may not be using appropriate search terms.

I haven't seen something specific, but a basic text box isn't that
difficult to write. Just a bunch of nit-picky details one has to get
right (especially if you want to support things like copy/paste, etc.).
If it really comes down to it, you might find that's the best approach
for your needs.

Other than that...

It might help if you can explain more specifically the need for a
console-like control that works in the way you describe. Is it because
you have what is actually a GUI program, but in which you desire
something that's console-like (i.e. you can't simply write a console
applicaton)? Or is there some other design goal driving this?

As far as using the built-in controls, you may be able to improve on the
approach you've already tried by changing the colors/format of the input
TextBox to match the read-only state (not disabled...that's too hard to
read) of a regular TextBox (or RichTextBox, if you really need that
one), removing the frames from the text boxes themselves, and putting
them in a single Panel that provides the outer border. You can handle
SelectionChanged and override any attempt on the user's part to select
text in the non-input text box. That might provide a more integrated
"look" for the user to achieve your goals (though, keeping in mind the
potential to frustrate the user).

Pete

 

[Jeff Gaines]

It might help if you can explain more specifically the need for a
console-like control that works in the way you describe. Is it because
you have what is actually a GUI program, but in which you desire something
that's console-like (i.e. you can't simply write a console applicaton)?
Or is there some other design goal driving this?

In my retirement I have started to look at Prolog again - in particular
interaction between a C# NET app and Amzi prolog. I want to try and write
something like the (usually extremely crude) IDEs that I have come across
with many Prolog incantations - broadly an editor taking up about three
quarters of the main window and a 'console' under that where you can type
commands that will act on the file in the editor.
All the IDEs I've come across have a similar issue - the cursor wanders
about all over the place when it really needs to stay at the end of the
'console'.
I am having some success with the combined (read only) Rich Text Box
together with a Text Box for input - I have managed to run 'Dir' in a
Command Window and pipe the output back to the Rich Text Box.
The main goal of the project is to keep my brain exercised which seems to
be working

 

[BobF]

In my retirement I have started to look at Prolog again - in particular
interaction between a C# NET app and Amzi prolog. I want to try and
write something like the (usually extremely crude) IDEs that I have come
across with many Prolog incantations - broadly an editor taking up about
three quarters of the main window and a 'console' under that where you
can type commands that will act on the file in the editor.
All the IDEs I've come across have a similar issue - the cursor wanders
about all over the place when it really needs to stay at the end of the
'console'.
I am having some success with the combined (read only) Rich Text Box
together with a Text Box for input - I have managed to run 'Dir' in a
Command Window and pipe the output back to the Rich Text Box.
The main goal of the project is to keep my brain exercised which seems
to be working

Have you explored the possibility of embedding emacs or vim?

((I don't if this is even possible ...))

 

[Peter Duniho]

In my retirement I have started to look at Prolog again - in particular
interaction between a C# NET app and Amzi prolog. I want to try and
write something like the (usually extremely crude) IDEs that I have come
across with many Prolog incantations - broadly an editor taking up about
three quarters of the main window and a 'console' under that where you
can type commands that will act on the file in the editor.

Okay, so basically it's what I said: your program is really a GUI
program, but you have a desire to include a console-like control in the GUI.

All the IDEs I've come across have a similar issue - the cursor wanders
about all over the place when it really needs to stay at the end of the
'console'.

Why does it need to stay there? Would it not suffice for the cursor to
return to the proper position if the user types something into the
console? Is it really your intent to prevent the user from being able
to select and copy output from the console-like control?

Something else to think about: while I understand your description of
other Prolog IDEs (though unfortunately have no first-hand experience
with it...when I was playing with Prolog, all I had was a strictly
command-line UI, no graphical/curses IDE at all ), the idea of using
a console to execute commands seems counter-intuitive in the context of
a GUI. Generally, the point of the GUI is to replace typed-in commands
with graphical interactions (buttons, menus, etc.). So maybe it's worth
considering not trying to follow so closely examples that may not be all
that great to start with, and coming up with something better?

Pete

 

[Jeff Gaines]

Have you explored the possibility of embedding emacs or vim?

I think I'd rather give up retirement and go back to work

 

[Jeff Gaines]

Okay, so basically it's what I said: your program is really a GUI program,
but you have a desire to include a console-like control in the GUI.

Yes - it's for immediate testing of the Prolog code before it gets
compiled to be used by a C# app.

Why does it need to stay there? Would it not suffice for the cursor to
return to the proper position if the user types something into the
console? Is it really your intent to prevent the user from being able to
select and copy output from the console-like control?

Interesting.... I find it confusing myself but it's a good point. It's
brought back memories of a very old machine, perhaps a BBC, where one of
the selling points was that you could move the cursor around and copy code
from 'up the screen'.

Something else to think about: while I understand your description of
other Prolog IDEs (though unfortunately have no first-hand experience with
it...when I was playing with Prolog, all I had was a strictly command-line
UI, no graphical/curses IDE at all ), the idea of using a console to
execute commands seems counter-intuitive in the context of a GUI.
Generally, the point of the GUI is to replace typed-in commands with
graphical interactions (buttons, menus, etc.). So maybe it's worth
considering not trying to follow so closely examples that may not be all
that great to start with, and coming up with something better?

Yes indeed, not sure I'm creative enough but it's food for thought.

Thanks Peter

 

[Peter Duniho]

[...]

Something else to think about: while I understand your description of
other Prolog IDEs (though unfortunately have no first-hand experience
with it...when I was playing with Prolog, all I had was a strictly
command-line UI, no graphical/curses IDE at all ), the idea of
using a console to execute commands seems counter-intuitive in the
context of a GUI. Generally, the point of the GUI is to replace
typed-in commands with graphical interactions (buttons, menus, etc.).
So maybe it's worth considering not trying to follow so closely
examples that may not be all that great to start with, and coming up
with something better?

Yes indeed, not sure I'm creative enough but it's food for thought.

For what it's worth: you're a programmer that has gotten this far, both
in your profession and in terms of this specific project. There's a
certain degree of testing of your skills that took place for you to get
that far. You've seen plenty of GUI applications, I assume. I doubt
it's true that you're not creative enough to translate a command-line UI
to a graphical one.

So, yes...food for thought. Chow down!

Pete