I don't remember anyone mention printing. Creating a bug free application that can print is a real pain. MFC is supposed to make it simple, but don't you believe that. However, I will see what I can do pertaining to the ability of printing complete or selected text.
Whatever you build (similar to the PST) should work with the Mac and BST for proper diversification.
It seems to me that every time someone wants to offer something up they get beat about the head if it won't run under every OS under the sun. The OP in this case made it clear that they choose to work in VC++ 6.0 so it seems counterproductive to raise this point.
The features I like and have used with various terminals in the past are:
VT100 emulation; write session to file, with option for received only, output only, both; ANSI Color, basic terminal width, font, etc.. selection; take input from file, optionally on hot key, like "F8 sends file X to terminal as if typed" kind of thing; input macro, where a specific input can be recorded and repeated on hot key or menu pick.
Erna was showing a terminal at UPEW that would write graphics to a window serially. That was pretty cool. Might be worth it to understand how that works.
Digression = 1
I wonder if a dual display Prop setup might not be worth it? Do, say 80x50 text, or 80x24, and a nice monochrome, or 4 color graphics display on a second screen?
Dedicate the entire prop to that, and serial comms.
Here's where I'm musing about that. Say the terminal can reproduce the same graphics serially? Now you've got both a PC output scenario, and or dedicated bench terminal output device using the same basic graphics data.
Digression = 0
Cool beans Bruce. Terminals are always good. I just rattled off the things I enjoy, though I very frequently use the minimum terminal, and actually that is sometimes just my TRS-80 Model 100 , or other classic Apple, CoCo computer.
There are a few C++ programmers that particpate in the forum. When I finish the initial framework and post it as open source, providing Parallax will let me upload the given file types, perhaps a few other people will jump in and add some more functionality. For now, I am just going to concentrate on making a very nice GUI for a working terminal app.
Perhaps I should have asked for suggestions that pertain to a WINDOWS GUI. I have got to learn to be more specific
However I want to thank everyone for their suggestions.
I just want to add that this is not like riding a bike. I have not done any serious C++ programming in several years and I have been going in circles since I started this project yesterday. However, I do believe that I am finally starting to make progress.
Where I enjoy a GUI is the "one off" kind of computing where I need to get in, decide the things that need to be decided, input those, perform the task, output and exit. Where that varies considerably, the GUI can be a very nice thing.
Where I don't enjoy a GUI is where things need to be repeated, or integrated as part of a process. It then becomes limiting. Much prefer keys, files, etc... for settings, leaving the GUI either working in tandem with files, so that either can make the change, or simply out of the way, minimal, so that the streams of data can just happen without that layer.
A great example of what I was talking about is this: Say there are two devices, each with a terminal needed, each with a serial. Run the program, connect to device 1, configure and discover, repeat for device two. So far so good, but what was learned, and what must be repeated and what must be remembered?
If there were, "write options to file", or the options were just files to begin with, then the good stuff was captured. Simply short cut the terminal for each device onto the desktop, each short cut referencing the environment or file needed for the terminal to understand it's configuration.
Two clicks later, I'm looking at the white on blue one, lucida fonts for my Propeller number 1, and two more clicks later, I'm looking at my yellow on red one, Courier, connected to my Linux tty device, etc....
Another device shows up, and it's a Prop! Great, copy the file, change blue to green, etc....
That's just a standard preference. It's my opinion the best programs are written to deal with files, and or are command line applications. From there, "wrap" the GUI around them such that it's optional. The GUI users don't know better, or don't care to know better, or even know! They just run the GUI, life is good. Those that do use their operating system at a command level get to do so.
So then, "minimal" is just all about lean operation options, not necessities.
One last thing. Archiving text / command data is easy! Archiving GUI data isn't so easy, requiring pictures and lots of thick descriptive elements to communicate configuration state.
All that said, please go for it in your GUI. My comment was not intended otherwise, nor is this post, which is just the explanation you asked for.
I am glad you brought up the propeller font, I have seen several requests and/or complaints pertaining to that issue. I will definitely try to address that one also.
I haven't read the whole thread but my 2 wants are:
1) Automatic enable (no need to press the button for each new code test).
2) Copy or Cut to clipboard so I can copy some values to report on this forum.
I have also seen several requests and/or complaints pertaining to issue #1, however I am unsure whether this is a general consensus. We'll see what others have to say, but I suppose it would be fairly easy to accomplish.
As for issue #2, the main view will be comprised of a rich edit view, so selecting and copying text should be a non-issue.
; Minimal Terminal in PureBasic
Global k$,c$,hndl
OpenConsole()
c$=" "
hndl = OpenSerialPort(#PB_Any,"COM6",115200,#PB_SerialPort_NoParity, 8, 1, #PB_SerialPort_NoHandshake, 1024, 1024)
Repeat
k$ = Inkey()
If k$ > "": WriteSerialPortString(hndl,k$): EndIf
If AvailableSerialPortInput(hndl)
ReadSerialPortData(hndl,@c$,1)
Print(c$)
EndIf
Until k$=Chr($1B) ;Esc
CloseSerialPort(hndl)
CloseConsole()
End
This compiles to a Windows EXE with 9 kByte (no DLLs or so required). Damn - no brownie points...
I have also written a Propeller Teminal 4 years ago (because there was no Parallax solution like the PST at the time) with a lot of Propeller related functions:
- Propeller Font
- .binary/.eeprom download
- Graphic commands
- Colors
- Mouse events
- Spin objects compatible to "TV_Text", "Keyboard" and "Mouse"
- many things more...
See the thread here: PropTerminal
The PropTerminal.EXE is a bit under 200 kB
Andy
Super good effort, Andy. I'll see if I can make it work, and take a look at PropTerminal too
I want to put it on a USB PIC micro that presents as a mass storage drive when connected to a PC, then once connected it will function like a combined FTDI serial chip and adc.
Looks like that Purebasic has some cross platform credentials too. Nice!
Handling the propeller font means Unicode characters and all the complexity that goes with that, I say leave that out for the future walk before you try to run.
Just see if you can receive good old 8 bit ASCII from the serial port and display it in a text memo control, I think called multiline text box in the MFC world.
Now that you mention it, I do remember reading that the Propeller font was unicode, and that makes sense, so I would have to agree. I believe I will leave the Propeller font for a more ambitious young man.
As for text display in MFC, you have EditView (like Notepad) and RichEditView (like Microsoft Word), each of these views originate from controls, being EditControl and RichEditControl respectively. Without looking it up, I believe multi-line capabilities are passed from the parent controls to the respective associated views.
The serial communication wrappers that I will be using rely on the RichEditView/RichEditControl for displaying text text. This is a good thing for those that like to control background color and font color, as well as other things.
However, I will agree that in the Parallax Serial Terminal, the input area has a class name of TMemo, but I believe this is a Delphi thing, not Microsoft.
@jmg
I am only willing to increase the baud rate options to 921,600, after that rate, I will allow for passing a manually entered number through to the driver.
As previously mentioned, I am not a serial communications genius, and my main contribution to this project will be the GUI. User options are easy for me to configure, but actually applying it to the serial communication will be a lot more difficult for me. But I am interested in suggestions, so please tell me more about the IP and OP pins, and perhaps I may be able to accommodate this request.
I was a little too brief there, the IP (input) and OP (output) pins means the handshake lines.
Pin 1 IP Data Carrier Detect DCD
Pin 2 IP Received Data RxData
Pin 3 OP Transmitted Data TxData
Pin 4 OP Data Terminal Ready DTR
Pin 5 - Signal Ground Gnd
Pin 6 IP Data Set Ready DSR
Pin 7 OP Request To Send RTS
Pin 8 IP Clear To Send CTS
Pin 9 IP Ring Indicator RI
The SW library I was using, allows these simple and direct accesses
ser.RTS := (True);
ser.DTR := (False);
ser.SendString(SomeString);
Sleep(2); // vary this, until we see pauses in String ?
IF ser.DSR THEN ...
IF ser.CTS THEN ...
IF ser.Carrier THEN ..
IF ser.Ring THEN ..
Add a Byte-rate Tx Test, that confirms Baud rates.
As for this request or suggestion, it sounds a little complicated, and it will require some thought.
In the simplest form, very easy : Take the time, send continually for eg 4 seconds, then take the time again, and report the Byte Rate = TotalCharsSent/TimeTaken.
Issues with the buffers make this simple code report high, so we found a better method, is to set up a stream, and AVOID the ends.
ie Transmit for 5 seconds, and sample [Time & Count] at 500ms and 4.5s, while it is streaming.
That's usually within 0.2% of the freq counter baud.
Better precision may be possible, but this was using simple calls. It's good enough to catch stop bit errors, and it will reveal creeping byte-gaps, as the USB ports have at the highest BAUD rates.
Cool project that you are doing and understand that you are looking for suggestions and here's one.
I love GUI programs and yours gives me an idea for you. What, if you come up with a way you can see what Propeller I/O pin is on ether a input that you turn in the Spin code or an output that was turned on from the spin code. All this would be displayed similar to Parallax's View Port, which shows you Propeller chip I/O.
The programs that I write are automation based (like my ship monitoring system), were I need to sometimes look at the I/O to see what I/O is on or off and it will help in the. A GUI with features like that are helpful and I do realize that I would need to write some Spin code in order for it to work.
I will continue to follow you as you continue to work your project.
I could be mistaken, but I believe in order for something like that to work, you would need to send command strings from the Propeller, and the software for the terminal would have to parse all the received data looking for those command strings. I believe it could be done, but I am not that ambitious, because it sounds pretty time consuming to implement. But just in case someone wants to tackle the job when I post it as open source, I am willing to discuss it.
In order for it to be useful to most people, the commands would need a standard. Additionally, I think it would be best to have a simple visual representation on the PC side, perhaps a dialog box with 32 LED bitmaps of alternating dk green and lt green. If a command is received for a pin going high, then a lt green bitmap is displayed and if a command is received for a pin going low, then a dk green bitmap is displayed.
Also 32 visual representations of LEDs would take up a bit of screen space, so I would suggest that the dialog box actually be a docking toolbar instead, which could be toggled on or off by a menu selection. And that way the box is not floating on top of the main window, it actually becomes part of it, providing that it is docked.
Bruce
EDIT: I would also recommend that if something like this is implemented, another thead should be created for parsing and displaying the I/O pin status, so it would not slow down the main thread of the application.
Getting those tab controls to just show up and be displayed properly in association with a RichEditView was very troublesome. However that was the first order of business for this project and it took me a day and half to accomplish that task
I now think that I have it beaten fairly into shape, so I can now move on to creating the actual interface and application. Like I said before, coming back to this after not having messed with it for several years... Well, lets just say that it has been a challenge.
Additionally, I found an update for the tab control (which helped speed things up), and the update can be found here:
As for text display in MFC, you have EditView (like Notepad) and RichEditView (like Microsoft Word), each of these views originate from controls, being EditControl and RichEditControl respectively. Without looking it up, I believe multi-line capabilities are passed from the parent controls to the respective associated views.
The serial communication wrappers that I will be using rely on the RichEditView/RichEditControl for displaying text text. This is a good thing for those that like to control background color and font color, as well as other things.
However, I will agree that in the Parallax Serial Terminal, the input area has a class name of TMemo, but I believe this is a Delphi thing, not Microsoft.
TMemo in Delphi is for making Notepad applications like your MFC EditControl and Delphi also has a
RichEditControl.
The Parallax Serial Terminal is not using either one for displaying text however. It is using a PaintBox.
A TPaintbox in Delphi is a component which gives you a canvas to draw on using GDI functions.
Actually Paintbox methods which wrap GDI functions.
Here is a code snip from the open source Parallax Serial Terminal from Debug.pas which is the main pas
file for this project.
In the code Receiver is a TPaintbox component.
{Need to render whole screen}
begin
for Idx := ScrTopLine to ScrTopLine+ScrHeight-1 do
begin {For all lines that need to be redrawn...}
{First draw the entire line unhighlighted}
Receiver.Canvas.TextOut(3,1+(Idx-ScrTopLine)*TxHeight,copy(ScrBuf.Line[Idx]^.Text,ScrLeftCol+1,ScrWidth));
if (Idx >= RxSelStart.y) and (Idx <= RxSelEnd.y) then
begin {If this is a highlighted line, draw the proper characters highlighted}
Receiver.Canvas.Font.Color := CPrefs[RxBgColor].IValue;
Receiver.Canvas.Brush.Color := CPrefs[RxFtColor].IValue;
Receiver.Canvas.TextOut(3+max(0,ord(Idx=RxSelStart.y)*((RxSelStart.x-ScrLeftCol)*TxWidth)),1+(Idx-ScrTopLine)*TxHeight,
copy(ScrBuf.Line[Idx]^.Text,max(ord(Idx=RxSelStart.y)*RxSelStart.x,ScrLeftCol)+1,(ord(Idx<>RxSelEnd.y)*(ScrWidth+ScrLeftCol))+(ord(Idx=RxSelEnd.y)*min(RxSelEnd.x,ScrWidth+ScrLeftCol))-(ord((RxSelStart.y=RxSelEnd.y) or (Idx=RxSelStart.y))*RxSelStart.x)-(max(ScrLeftCol-(RxSelStart.x*ord(Idx=RxSelStart.y)),0))));
Receiver.Canvas.Font.Color := CPrefs[RxFtColor].IValue;
Receiver.Canvas.Brush.Color := CPrefs[RxBgColor].IValue;
Note the text is being drawn on a Canvas using GDI Canvas.Textout
The reason this is done is it is difficult to do a serial terminal display using a component designed for
making a text editor or word processor.
There are two problems you cannot do goxy style actions where you need to move the cursor to some
XY location and Display text. Your terminal would be responding to say the position(x,y) string from
Parallax Serial Terminal.spin or your parsing VT100 ESC sequences.
Components like EditView and RichEdit want to scroll lines .
The other issue is if you are receiving line after line after line etc the Edit style components will just keep adding lines until it chokes. By using a Paintbox Canvas you are only using it for display of the lines you
serially received and keep in your own data structures . You decide how many lines you want to keep in a back buffer that have scrolled off the top of you display window if any and can receive lines all day into your
80x25 display screen done using a Paintbox Canvas you draw the text on.
Maybe the code you have does this, I do not know so I sent this so you would have some info to think
about as you design your terminal.
That was a very interesting post. I have never come across this "choking issue" in past applications, but it is definitely food for thought. However I do believe I am going to stick with the RichEditControl, because that sounds like some major reprogramming alterations to pass it all onto the GDI. Additionally, at that point, you also lose the option for any copy and paste operations you may want to achieve. The guy that wrote the article and wrappers sure sounds like he knows what he is doing, and other people have recommended it, and the code looks clean. I guess I will just build it, keep my fingers crossed, and see what happens. I am sure it will be useful for something
The TMemo class in the PST is being used for the input of text and TPanel is being used to display the output, or at least that is what Spy++ reads.
Bruce
The TMemo in the PST is the single line where you enter text to be sent out serially.
The received text is drawn in the large area below that line which is a TPaintbox.
TPanel components are used to partition a form into sections and are also
containers of other components. The TPaintbox is contained in a TPanel as well
as many other parts of the PST form.
Also I like your idea of build it your way and see, nothing like doing that to see for yourself.
To many get talked out of doing anything , nothing like doing it and seeing the issues and
even if you get it working and learned alot one can also be thinking I never want to do that again .
Comments
Bruce
I have never touched a Mac system in my entire life, nor have I ever wrote a program for a Mac. I would not even know where to begin.
Bruce
It seems to me that every time someone wants to offer something up they get beat about the head if it won't run under every OS under the sun. The OP in this case made it clear that they choose to work in VC++ 6.0 so it seems counterproductive to raise this point.
C.W.
VT100 emulation; write session to file, with option for received only, output only, both; ANSI Color, basic terminal width, font, etc.. selection; take input from file, optionally on hot key, like "F8 sends file X to terminal as if typed" kind of thing; input macro, where a specific input can be recorded and repeated on hot key or menu pick.
Erna was showing a terminal at UPEW that would write graphics to a window serially. That was pretty cool. Might be worth it to understand how that works.
Digression = 1
I wonder if a dual display Prop setup might not be worth it? Do, say 80x50 text, or 80x24, and a nice monochrome, or 4 color graphics display on a second screen?
Dedicate the entire prop to that, and serial comms.
Here's where I'm musing about that. Say the terminal can reproduce the same graphics serially? Now you've got both a PC output scenario, and or dedicated bench terminal output device using the same basic graphics data.
Digression = 0
Cool beans Bruce. Terminals are always good. I just rattled off the things I enjoy, though I very frequently use the minimum terminal, and actually that is sometimes just my TRS-80 Model 100
Perhaps I should have asked for suggestions that pertain to a WINDOWS GUI.
However I want to thank everyone for their suggestions.
Bruce
-Phil
Bruce
Including executables?
For terminal, the least GUI possible.
I am curious why you say that. The GUI encompasses a lot of attributes, functionality, and capabilities.
From radio buttons to check boxes to drop down menus to rich edit controls to edit boxes to spin controls to scroll bars..............The list goes on
Andy presented your desired app a little earlier in the thread
; Minimal Terminal in PureBasic Global k$,c$,hndl OpenConsole() c$=" " hndl = OpenSerialPort(#PB_Any,"COM6",115200,#PB_SerialPort_NoParity, 8, 1, #PB_SerialPort_NoHandshake, 1024, 1024) Repeat k$ = Inkey() If k$ > "": WriteSerialPortString(hndl,k$): EndIf If AvailableSerialPortInput(hndl) ReadSerialPortData(hndl,@c$,1) Print(c$) EndIf Until k$=Chr($1B) ;Esc CloseSerialPort(hndl) CloseConsole() EndEDIT: Can't forget those selectable fonts and those beautiful colors
Where I enjoy a GUI is the "one off" kind of computing where I need to get in, decide the things that need to be decided, input those, perform the task, output and exit. Where that varies considerably, the GUI can be a very nice thing.
Where I don't enjoy a GUI is where things need to be repeated, or integrated as part of a process. It then becomes limiting. Much prefer keys, files, etc... for settings, leaving the GUI either working in tandem with files, so that either can make the change, or simply out of the way, minimal, so that the streams of data can just happen without that layer.
A great example of what I was talking about is this: Say there are two devices, each with a terminal needed, each with a serial. Run the program, connect to device 1, configure and discover, repeat for device two. So far so good, but what was learned, and what must be repeated and what must be remembered?
If there were, "write options to file", or the options were just files to begin with, then the good stuff was captured. Simply short cut the terminal for each device onto the desktop, each short cut referencing the environment or file needed for the terminal to understand it's configuration.
Two clicks later, I'm looking at the white on blue one, lucida fonts for my Propeller number 1, and two more clicks later, I'm looking at my yellow on red one, Courier, connected to my Linux tty device, etc....
Another device shows up, and it's a Prop! Great, copy the file, change blue to green, etc....
That's just a standard preference. It's my opinion the best programs are written to deal with files, and or are command line applications. From there, "wrap" the GUI around them such that it's optional. The GUI users don't know better, or don't care to know better, or even know! They just run the GUI, life is good. Those that do use their operating system at a command level get to do so.
So then, "minimal" is just all about lean operation options, not necessities.
One last thing. Archiving text / command data is easy! Archiving GUI data isn't so easy, requiring pictures and lots of thick descriptive elements to communicate configuration state.
All that said, please go for it in your GUI. My comment was not intended otherwise, nor is this post, which is just the explanation you asked for.
;o)
You could easily create boxed menus, simple windows, in system schematics, signal diagrams .....
I am glad you brought up the propeller font, I have seen several requests and/or complaints pertaining to that issue. I will definitely try to address that one also.
Bruce
1) Automatic enable (no need to press the button for each new code test).
2) Copy or Cut to clipboard so I can copy some values to report on this forum.
I have also seen several requests and/or complaints pertaining to issue #1, however I am unsure whether this is a general consensus. We'll see what others have to say, but I suppose it would be fairly easy to accomplish.
As for issue #2, the main view will be comprised of a rich edit view, so selecting and copying text should be a non-issue.
Bruce
Super good effort, Andy. I'll see if I can make it work, and take a look at PropTerminal too
I want to put it on a USB PIC micro that presents as a mass storage drive when connected to a PC, then once connected it will function like a combined FTDI serial chip and adc.
Looks like that Purebasic has some cross platform credentials too. Nice!
cheers
tubular
Yes, including executables.
-Phil
Just see if you can receive good old 8 bit ASCII from the serial port and display it in a text memo control, I think called multiline text box in the MFC world.
Tom
Now that you mention it, I do remember reading that the Propeller font was unicode, and that makes sense, so I would have to agree. I believe I will leave the Propeller font for a more ambitious young man.
As for text display in MFC, you have EditView (like Notepad) and RichEditView (like Microsoft Word), each of these views originate from controls, being EditControl and RichEditControl respectively. Without looking it up, I believe multi-line capabilities are passed from the parent controls to the respective associated views.
The serial communication wrappers that I will be using rely on the RichEditView/RichEditControl for displaying text text. This is a good thing for those that like to control background color and font color, as well as other things.
However, I will agree that in the Parallax Serial Terminal, the input area has a class name of TMemo, but I believe this is a Delphi thing, not Microsoft.
Bruce
That would be fine.
I was a little too brief there, the IP (input) and OP (output) pins means the handshake lines.
The SW library I was using, allows these simple and direct accesses
ser.RTS := (True); ser.DTR := (False); ser.SendString(SomeString); Sleep(2); // vary this, until we see pauses in String ? IF ser.DSR THEN ... IF ser.CTS THEN ... IF ser.Carrier THEN .. IF ser.Ring THEN ..In the simplest form, very easy : Take the time, send continually for eg 4 seconds, then take the time again, and report the Byte Rate = TotalCharsSent/TimeTaken.
Issues with the buffers make this simple code report high, so we found a better method, is to set up a stream, and AVOID the ends.
ie Transmit for 5 seconds, and sample [Time & Count] at 500ms and 4.5s, while it is streaming.
That's usually within 0.2% of the freq counter baud.
Better precision may be possible, but this was using simple calls. It's good enough to catch stop bit errors, and it will reveal creeping byte-gaps, as the USB ports have at the highest BAUD rates.
That all sounds like it could be fairly easily obtained.
Bruce
Cool project that you are doing and understand that you are looking for suggestions and here's one.
I love GUI programs and yours gives me an idea for you. What, if you come up with a way you can see what Propeller I/O pin is on ether a input that you turn in the Spin code or an output that was turned on from the spin code. All this would be displayed similar to Parallax's View Port, which shows you Propeller chip I/O.
The programs that I write are automation based (like my ship monitoring system), were I need to sometimes look at the I/O to see what I/O is on or off and it will help in the. A GUI with features like that are helpful and I do realize that I would need to write some Spin code in order for it to work.
I will continue to follow you as you continue to work your project.
I could be mistaken, but I believe in order for something like that to work, you would need to send command strings from the Propeller, and the software for the terminal would have to parse all the received data looking for those command strings. I believe it could be done, but I am not that ambitious, because it sounds pretty time consuming to implement. But just in case someone wants to tackle the job when I post it as open source, I am willing to discuss it.
In order for it to be useful to most people, the commands would need a standard. Additionally, I think it would be best to have a simple visual representation on the PC side, perhaps a dialog box with 32 LED bitmaps of alternating dk green and lt green. If a command is received for a pin going high, then a lt green bitmap is displayed and if a command is received for a pin going low, then a dk green bitmap is displayed.
Also 32 visual representations of LEDs would take up a bit of screen space, so I would suggest that the dialog box actually be a docking toolbar instead, which could be toggled on or off by a menu selection. And that way the box is not floating on top of the main window, it actually becomes part of it, providing that it is docked.
Bruce
EDIT: I would also recommend that if something like this is implemented, another thead should be created for parsing and displaying the I/O pin status, so it would not slow down the main thread of the application.
Getting those tab controls to just show up and be displayed properly in association with a RichEditView was very troublesome. However that was the first order of business for this project and it took me a day and half to accomplish that task
I now think that I have it beaten fairly into shape, so I can now move on to creating the actual interface and application. Like I said before, coming back to this after not having messed with it for several years... Well, lets just say that it has been a challenge.
Additionally, I found an update for the tab control (which helped speed things up), and the update can be found here:
http://msdn.microsoft.com/en-us/magazine/cc188936.aspx
Bruce
TMemo in Delphi is for making Notepad applications like your MFC EditControl and Delphi also has a
RichEditControl.
The Parallax Serial Terminal is not using either one for displaying text however. It is using a PaintBox.
A TPaintbox in Delphi is a component which gives you a canvas to draw on using GDI functions.
Actually Paintbox methods which wrap GDI functions.
Here is a code snip from the open source Parallax Serial Terminal from Debug.pas which is the main pas
file for this project.
In the code Receiver is a TPaintbox component.
{Need to render whole screen} begin for Idx := ScrTopLine to ScrTopLine+ScrHeight-1 do begin {For all lines that need to be redrawn...} {First draw the entire line unhighlighted} Receiver.Canvas.TextOut(3,1+(Idx-ScrTopLine)*TxHeight,copy(ScrBuf.Line[Idx]^.Text,ScrLeftCol+1,ScrWidth)); if (Idx >= RxSelStart.y) and (Idx <= RxSelEnd.y) then begin {If this is a highlighted line, draw the proper characters highlighted} Receiver.Canvas.Font.Color := CPrefs[RxBgColor].IValue; Receiver.Canvas.Brush.Color := CPrefs[RxFtColor].IValue; Receiver.Canvas.TextOut(3+max(0,ord(Idx=RxSelStart.y)*((RxSelStart.x-ScrLeftCol)*TxWidth)),1+(Idx-ScrTopLine)*TxHeight, copy(ScrBuf.Line[Idx]^.Text,max(ord(Idx=RxSelStart.y)*RxSelStart.x,ScrLeftCol)+1,(ord(Idx<>RxSelEnd.y)*(ScrWidth+ScrLeftCol))+(ord(Idx=RxSelEnd.y)*min(RxSelEnd.x,ScrWidth+ScrLeftCol))-(ord((RxSelStart.y=RxSelEnd.y) or (Idx=RxSelStart.y))*RxSelStart.x)-(max(ScrLeftCol-(RxSelStart.x*ord(Idx=RxSelStart.y)),0)))); Receiver.Canvas.Font.Color := CPrefs[RxFtColor].IValue; Receiver.Canvas.Brush.Color := CPrefs[RxBgColor].IValue;Note the text is being drawn on a Canvas using GDI Canvas.Textout
The reason this is done is it is difficult to do a serial terminal display using a component designed for
making a text editor or word processor.
There are two problems you cannot do goxy style actions where you need to move the cursor to some
XY location and Display text. Your terminal would be responding to say the position(x,y) string from
Parallax Serial Terminal.spin or your parsing VT100 ESC sequences.
Components like EditView and RichEdit want to scroll lines .
The other issue is if you are receiving line after line after line etc the Edit style components will just keep adding lines until it chokes. By using a Paintbox Canvas you are only using it for display of the lines you
serially received and keep in your own data structures . You decide how many lines you want to keep in a back buffer that have scrolled off the top of you display window if any and can receive lines all day into your
80x25 display screen done using a Paintbox Canvas you draw the text on.
Maybe the code you have does this, I do not know so I sent this so you would have some info to think
about as you design your terminal.
Tom
That was a very interesting post. I have never come across this "choking issue" in past applications, but it is definitely food for thought. However I do believe I am going to stick with the RichEditControl, because that sounds like some major reprogramming alterations to pass it all onto the GDI. Additionally, at that point, you also lose the option for any copy and paste operations you may want to achieve. The guy that wrote the article and wrappers sure sounds like he knows what he is doing, and other people have recommended it, and the code looks clean. I guess I will just build it, keep my fingers crossed, and see what happens. I am sure it will be useful for something
The TMemo class in the PST is being used for the input of text and TPanel is being used to display the output, or at least that is what Spy++ reads.
Thanks for your post Tom.
Bruce
The TMemo in the PST is the single line where you enter text to be sent out serially.
The received text is drawn in the large area below that line which is a TPaintbox.
TPanel components are used to partition a form into sections and are also
containers of other components. The TPaintbox is contained in a TPanel as well
as many other parts of the PST form.
Also I like your idea of build it your way and see, nothing like doing that to see for yourself.
To many get talked out of doing anything , nothing like doing it and seeing the issues and
even if you get it working and learned alot one can also be thinking I never want to do that again .
Tom
I see says Bruce