It still needs quite a bit of work, but this is how the terminal is starting to shape up. Keep in mind that the terminal can be sized and that it will not remain this size.
I can see that it's all coming together with your project. So, what is left too do?
Yea, it is coming together, but what I have done so far is all the easy stuff. The next order of business is to get the input area and scrollbar to size properly upon application initialization, which will be slightly difficult. After that, there will still be a lot left to accomplish.
Think of it as an electrical project, with a bunch of pushbuttons, transistors, LEDS, display, etc.... It all has to be wired correctly to work. All I have done so far is just positioning some of the main components. This project still needs a few more components, then it needs to be wired properly, and all the supporting source code needs to be added or written. Of course that is just an analogy.
If I had to guess, I would say the project is about 20% - 30% complete.
Some of you folks want the ability to paste into the serial terminal. Of course I assume this is for input, because I can't think of any reason you would want to post to the output of the terminal.
Can someone please explain the reason behind the requests to paste?
Additionally, I cannot see it being feasible to posting more than one line of code, but I could be wrong. Please explain if you are seeking this capability.
Personally (and for a limited few others), we use Forth and an easy way to build up a Forth image is to load a Kernal into EEPROM and then through the serial connection you add words to create your Forth "vocabulary" before you save the modified image to EEPROM. So during development, it is common to use an editor to create multi-line text containing Forth word definitions and then paste that into teh serial terminal so Forth can compile it.
Historically, Forth was writtten in blocks (multi-line "chunks" of code) and then the blocks were edited, loaded and forgotten as needed to develop an application.
The cut/paste capability to the editor input stream gives you that capability on the Prop through the serial interface.
I found your information useful, but I was hopefully looking for a detailed description.
From what you posted, I assume you meant something similar to or actually a "SEND FILE" command, where the program could open a file, iterate the file line by line, sending the lines through the terminal.
Instead of providing an input area that will accept multi-lines, which sounds like a pain, how about the ability to paste just one line. If more than one line is needed, just create a file and use SEND FILE. Does this sound reasonable to everyone?
Bruce
EDIT: Or am I missing something, such as the concept behind send file?
Can someone please explain the reason behind the requests to paste?
Faster than typing? Having a send file utility is good, but many times it's much easier to have one file with lots of commands open in an editor and selectively copy/paste to the terminal. Used to do this all the time line by line when working with routers, etc... that are not easy/fast to reprogram. Working with small easily reprogrammed devices like Propeller with simple languages make copy/paste less important to me.
Is there anytime that you would want to paste more than one line of code into the input area?
If this is what people want, I foresee this being a problem, because the pasted code would need to be iterated, or at least that is the way I see it.
EDIT: On second thought, why should it matter if the control characters are present? But it is a large paste, the buffer would need to be appropriately sized.
Has anyone ever pasted numerous lines into the input area of a serial terminal?
Has anyone ever pasted numerous lines into the input area of a serial terminal?
Bruce,
Constantly! Details follow:
Again, back to Forth. In building a new Forth image or creating an application, you might start out with the basic Kernal (a .spin program loaded through the Propeller Tool);
- start your serial terminal to Forth
- open some Forth source into your editor. Say you want to add a file system to support EEPROM files but want to change something, (the definitions are 461 lines of code)
- make your changes, ctrl-A, ctrl-C, click on terminal window, ctrl-V (or right click in case of Terra-Term) and it pastes it into the input stream as if you were typing
- Bingo-bango, you now have EEPROM FS support
With a send file command, you save the text, open the "Send File" dialog in the terminal program, navigate to the file, select it, click OK then the code is loaded.....this takes longer than ctrl-A, ctrl-C, click on a window, ctrl-V - I'm happy with my workflow with my current tools but if a new tool comes up developed by a Forum member, I sure would try it out to see if it added value.
Forth Development is very interactive and iterative. You often, edit, select, copy, switch to termial, paste (which causes compile), test, forget, repeat.........hopefully, you are forgetting, editing and loading/compiling smaller and smaller portions of your source file through each iteration.
WIth a send file, it would be edit, save file (or the portion of an entire file you need to re-load), switch to terminal, open up dialog, navigate to file, load file (causing a compile), test forget, repeat....
I could see similar scenarios with a testing script or command file sent to a prop...incremental, variable changes within a file which makes send file difficult to use over cut/paste.
As for control characters, they should stay embedded and be sent as part of the file, in most cases, it would just be CR/LF/TAB important in the case of CR/LF in the text.
The Forth ipserver vocabulary is 31K and the HTTP vocabulary is 29K, I cut/paste these into Terra Term (my current serial terminal of choice) often with only minimal but occasional pacing hiccups.
As for the detail, say there is text somewhere. Could be in a editor, on screen, or produced by some application.
The ideal workflow for the paste use case is simply to highlight that text, and feed it character by character, including line feeds and such to the terminal exactly as if the user typed it, using the standard windows functions for those things.
For the file, a select source file option, combined with a send file option would be good, so the user can decouple file selection from input begin indication.
Instead of cutting and pasting an entire file to the terminal view, why not have an upload file option, which essentially would be the same thing as pasting to an input field. Perhaps the ability also to 'tag' a button on the Serial terminal to a specific file, the idea having multiple files to 'upload' depending on which button you press.
This could be useful in a situation where you wanted to run a series of pre-defined orchestrated events, and still needed some manual intervention if the events didn't follow a specific time line or order.
Bruce
Last night had a lot of thunder and lightning so I did not see your last jpg
Looks good but it does strike me that it is looking more like a test editor than an terminal application.
You have what looks like a file new menu item is caught my eye. You could also just be building
a test things out app and what they say right now is not important.
My thoughts on sending text is opening a file selection dialog and then reading it line by line and sending it
is simpilist. The display received data display area is not a text editor and you do not edit text there , the
single line where you type what you want sent yes, that can also be multi line depending on the control you
use to implemement that feature. I can see stopping serial comm and scrolling back in the receive buffer and
highlighting the text and resending that text. Also paste text into the what I want to send line not the receive
display area. If that line is a multiline editor like the TMemo in Delphi which is what it is in the PST just because
only one line is showing does not mean it cannot hold more that one line.
Sorry if I have miss read what you intend to do but if seems like we are trying to turn the terminal display area into
a text editor and that is the wrong place, if serial data is coming in you will chase it off the top of the window as
new lines of data come in if you try and edit there. Opening a file and adding it line by line to the what I want to send
line or pasting into that line from the clipboard is the way to go.
Done that way the same code that waits for a cr in the edit component to send what the user typed can be used to
send line by line what is in a file or on the clipboard.
@Unsoundcode - It has been quite some time since I have messed with the clipboard operations. If I recall correctly, there should be three options for pasting.
From the Edit menu
From the Toolbar
From a context menu, providing I am a nice guy and give you guys one
@Beau
Perhaps even have two send file functions.
Send file line by line
Send files in predetermined data chunks
I think you and I are thinking along the same lines.
the idea having multiple files to 'upload' depending on which button you press
I also think that you and I are thinking along the same lines. I believe I am only going to provide for single line support in the input area, if someone pastes more than one line into the input box, then that is upto them. By no means is this going to be a text editor, however it will have some of the same features as a text editor.
This post will most likely be periodically updated, so check back often to see if there is any new information.
This is what I have decided so far.
Single line input only
The ability to copy out of or paste into the input area
The ability to copy out of the output area
The ability to set font color for both the input and output windows
The ability to set background color for both the input and output windows
The ability to send a file line by line or in chunks
The ability to print the output area
Allow multiple instances of the same application, which can be achieved through the start menu, the New menu, or the Toolbar.
Provide open source files
Search output for specified text
Due to the fixed height dimension of the input window and the math involved with controling the scrollbar for the input window, there will only be support for a single font size and type
Undecided options
Support for the Parallax font
Multiple buttons for selective file uploading
Indicator of high/low patterns for pins
** In response for undecided option #2, I believe the best solution for this option would be a selectively viewable non-docking toolbar, having numerous buttons consecutively numbered, with each button being associated with a file path that could be obtained through a file open dialog box. By having this as a non-docking toolbar, the main application would not appear to be cramped for space.
*** In response for undecided option #3, I believe the best solution for this option would be a selectively viewable non-docking toolbar, having numerous simulated LEDs. By having this as a non-docking toolbar, the main application would not appear to be cramped for space.
It took me a while, but I finally got the input window and the scrollbar to size in conjunction with the main window. The program kept complaining that these two items were not windows. After losing several hairs, I reread some of the documentation, and to my ultimate surprise I found these dreadful words:
The returned pointer may be temporary and should not be stored for later use.
I wish I would have noticed that sooner
Anyhow here is a similar pic to one of the others, but with everything adjusted properly. There will be additions, but this is what it will resemble.
Upon further investigation, a CRichEditCtrl that is embedded in a CDialogBar that is embedded in a CReBar control is not that easy to communicate with, not to mention the difficulty of controlling the scrolling action of the CRichEditCtrl with an external scrollbar. I may need to rethink my approach.
As indicated in my previous post, there are some serious complexities with my current design. The most complex issue was the inabilily to communicate with the scrollbar. However, before giving up on this design, I figured I would try to rectify the communication process one more time before trying something new. Last night I found an article that stated communication between the CScrollBar class and the CDialogBar class would be unobtainable unless I derive a subclass from the CDialogBar class object and pass all communication through it. So I decided to give it a try. Before I attempted anything else, I wanted a communication solution for the input text box area. I wanted to be able to control it, communicate with it, and have it function the way I wanted it to.
After subclassing the CDialogBar class, I was still having problems with design, functionality, and desired characteristics, that is until I wrote the following piece of test code.
BOOL CTerminalInputBar::PreTranslateMessage(MSG* pMsg)
{
if(pMsg->message)
{
if(pMsg->wParam == (WPARAM)VK_RETURN)
{
//Test Communication
CRichEditCtrl *pInputRichEditCtrl;
pInputRichEditCtrl = (CRichEditCtrl*)GetDlgItem(IDC_TERMINAL_INPUT);
pInputRichEditCtrl->SetSel(0, -1);
pInputRichEditCtrl->Clear();
CScrollBar *pInputRichEditCtrlScrollBar;
pInputRichEditCtrlScrollBar = (CScrollBar*)GetDlgItem(IDC_TERMINAL_INPUT_SCROLLBAR);
pInputRichEditCtrlScrollBar->SetScrollRange(0, 100, FALSE);
pInputRichEditCtrlScrollBar->SetScrollPos(50, TRUE);
//Return nonzero if the message was translated
//and should not be dispatched
return TRUE;
}
}
return CDialogBar::PreTranslateMessage(pMsg);
}
With this code I have proved that I am now capable of communicating with and controlling both the CScrollBar and CRichEditCtrl classes embedded within a CReBar class. I must say this is pretty awesome, because I have learned something new about creating applications with the CReBar class object, and communicating with classes embedded within. I like it.
So now I can go forward again. The next major obstacle is to get the external scrollbar to coincide with the amount of text within the rich edit control.
To sum it up, the current design will work Hey Dr_Acula, I just solved a major part to this puzzle
Comments
I think I will surprise a lot of people with this.
Hidden talents.
Bruce
I looked at the pics you posted and it looks like your putting the pieces together.
Tom
In about another hour, I will be posting a pic of how the main terminal is starting to look. I must say that so far I am pleased with it.
Bruce
It still needs quite a bit of work, but this is how the terminal is starting to shape up. Keep in mind that the terminal can be sized and that it will not remain this size.
Bruce
I can see that it's all coming together with your project. So, what is left too do?
Yea, it is coming together, but what I have done so far is all the easy stuff. The next order of business is to get the input area and scrollbar to size properly upon application initialization, which will be slightly difficult. After that, there will still be a lot left to accomplish.
Think of it as an electrical project, with a bunch of pushbuttons, transistors, LEDS, display, etc.... It all has to be wired correctly to work. All I have done so far is just positioning some of the main components. This project still needs a few more components, then it needs to be wired properly, and all the supporting source code needs to be added or written. Of course that is just an analogy.
If I had to guess, I would say the project is about 20% - 30% complete.
Bruce
Some of you folks want the ability to paste into the serial terminal. Of course I assume this is for input, because I can't think of any reason you would want to post to the output of the terminal.
Can someone please explain the reason behind the requests to paste?
Additionally, I cannot see it being feasible to posting more than one line of code, but I could be wrong. Please explain if you are seeking this capability.
Bruce
Testing a standardized set of use cases, program data firmware updates, data acquired from another source, etc...
Those are good use cases. There are many others.
Historically, Forth was writtten in blocks (multi-line "chunks" of code) and then the blocks were edited, loaded and forgotten as needed to develop an application.
The cut/paste capability to the editor input stream gives you that capability on the Prop through the serial interface.
I found your information useful, but I was hopefully looking for a detailed description.
From what you posted, I assume you meant something similar to or actually a "SEND FILE" command, where the program could open a file, iterate the file line by line, sending the lines through the terminal.
Bruce
Instead of providing an input area that will accept multi-lines, which sounds like a pain, how about the ability to paste just one line. If more than one line is needed, just create a file and use SEND FILE. Does this sound reasonable to everyone?
Bruce
EDIT: Or am I missing something, such as the concept behind send file?
EDIT: On second thought, why should it matter if the control characters are present? But it is a large paste, the buffer would need to be appropriately sized.
Has anyone ever pasted numerous lines into the input area of a serial terminal?
Bruce,
Constantly! Details follow:
Again, back to Forth. In building a new Forth image or creating an application, you might start out with the basic Kernal (a .spin program loaded through the Propeller Tool);
- start your serial terminal to Forth
- open some Forth source into your editor. Say you want to add a file system to support EEPROM files but want to change something, (the definitions are 461 lines of code)
- make your changes, ctrl-A, ctrl-C, click on terminal window, ctrl-V (or right click in case of Terra-Term) and it pastes it into the input stream as if you were typing
- Bingo-bango, you now have EEPROM FS support
With a send file command, you save the text, open the "Send File" dialog in the terminal program, navigate to the file, select it, click OK then the code is loaded.....this takes longer than ctrl-A, ctrl-C, click on a window, ctrl-V - I'm happy with my workflow with my current tools but if a new tool comes up developed by a Forum member, I sure would try it out to see if it added value.
Forth Development is very interactive and iterative. You often, edit, select, copy, switch to termial, paste (which causes compile), test, forget, repeat.........hopefully, you are forgetting, editing and loading/compiling smaller and smaller portions of your source file through each iteration.
WIth a send file, it would be edit, save file (or the portion of an entire file you need to re-load), switch to terminal, open up dialog, navigate to file, load file (causing a compile), test forget, repeat....
I could see similar scenarios with a testing script or command file sent to a prop...incremental, variable changes within a file which makes send file difficult to use over cut/paste.
As for control characters, they should stay embedded and be sent as part of the file, in most cases, it would just be CR/LF/TAB important in the case of CR/LF in the text.
Send file would be cool too.
As for the detail, say there is text somewhere. Could be in a editor, on screen, or produced by some application.
The ideal workflow for the paste use case is simply to highlight that text, and feed it character by character, including line feeds and such to the terminal exactly as if the user typed it, using the standard windows functions for those things.
For the file, a select source file option, combined with a send file option would be good, so the user can decouple file selection from input begin indication.
Jeff T.
This could be useful in a situation where you wanted to run a series of pre-defined orchestrated events, and still needed some manual intervention if the events didn't follow a specific time line or order.
Last night had a lot of thunder and lightning so I did not see your last jpg
Looks good but it does strike me that it is looking more like a test editor than an terminal application.
You have what looks like a file new menu item is caught my eye. You could also just be building
a test things out app and what they say right now is not important.
My thoughts on sending text is opening a file selection dialog and then reading it line by line and sending it
is simpilist. The display received data display area is not a text editor and you do not edit text there , the
single line where you type what you want sent yes, that can also be multi line depending on the control you
use to implemement that feature. I can see stopping serial comm and scrolling back in the receive buffer and
highlighting the text and resending that text. Also paste text into the what I want to send line not the receive
display area. If that line is a multiline editor like the TMemo in Delphi which is what it is in the PST just because
only one line is showing does not mean it cannot hold more that one line.
Sorry if I have miss read what you intend to do but if seems like we are trying to turn the terminal display area into
a text editor and that is the wrong place, if serial data is coming in you will chase it off the top of the window as
new lines of data come in if you try and edit there. Opening a file and adding it line by line to the what I want to send
line or pasting into that line from the clipboard is the way to go.
Done that way the same code that waits for a cr in the edit component to send what the user typed can be used to
send line by line what is in a file or on the clipboard.
Tom
- From the Edit menu
- From the Toolbar
- From a context menu, providing I am a nice guy and give you guys one
@BeauI think you and I are thinking along the same lines.
How many buttons/files are you talking about?
I also think that you and I are thinking along the same lines. I believe I am only going to provide for single line support in the input area, if someone pastes more than one line into the input box, then that is upto them. By no means is this going to be a text editor, however it will have some of the same features as a text editor.
Bruce
This is what I have decided so far.
- Single line input only
- The ability to copy out of or paste into the input area
- The ability to copy out of the output area
- The ability to set font color for both the input and output windows
- The ability to set background color for both the input and output windows
- The ability to send a file line by line or in chunks
- The ability to print the output area
- Allow multiple instances of the same application, which can be achieved through the start menu, the New menu, or the Toolbar.
- Provide open source files
- Search output for specified text
- Due to the fixed height dimension of the input window and the math involved with controling the scrollbar for the input window, there will only be support for a single font size and type
Undecided options- Support for the Parallax font
- Multiple buttons for selective file uploading
- Indicator of high/low patterns for pins
** In response for undecided option #2, I believe the best solution for this option would be a selectively viewable non-docking toolbar, having numerous buttons consecutively numbered, with each button being associated with a file path that could be obtained through a file open dialog box. By having this as a non-docking toolbar, the main application would not appear to be cramped for space.*** In response for undecided option #3, I believe the best solution for this option would be a selectively viewable non-docking toolbar, having numerous simulated LEDs. By having this as a non-docking toolbar, the main application would not appear to be cramped for space.
I wish I would have noticed that sooner
Anyhow here is a similar pic to one of the others, but with everything adjusted properly. There will be additions, but this is what it will resemble.
Bruce
Bruce
After subclassing the CDialogBar class, I was still having problems with design, functionality, and desired characteristics, that is until I wrote the following piece of test code.
BOOL CTerminalInputBar::PreTranslateMessage(MSG* pMsg) { if(pMsg->message) { if(pMsg->wParam == (WPARAM)VK_RETURN) { //Test Communication CRichEditCtrl *pInputRichEditCtrl; pInputRichEditCtrl = (CRichEditCtrl*)GetDlgItem(IDC_TERMINAL_INPUT); pInputRichEditCtrl->SetSel(0, -1); pInputRichEditCtrl->Clear(); CScrollBar *pInputRichEditCtrlScrollBar; pInputRichEditCtrlScrollBar = (CScrollBar*)GetDlgItem(IDC_TERMINAL_INPUT_SCROLLBAR); pInputRichEditCtrlScrollBar->SetScrollRange(0, 100, FALSE); pInputRichEditCtrlScrollBar->SetScrollPos(50, TRUE); //Return nonzero if the message was translated //and should not be dispatched return TRUE; } } return CDialogBar::PreTranslateMessage(pMsg); }With this code I have proved that I am now capable of communicating with and controlling both the CScrollBar and CRichEditCtrl classes embedded within a CReBar class. I must say this is pretty awesome, because I have learned something new about creating applications with the CReBar class object, and communicating with classes embedded within. I like it.
So now I can go forward again. The next major obstacle is to get the external scrollbar to coincide with the amount of text within the rich edit control.
To sum it up, the current design will work
Bruce
Pretty much every terminal I have ever used has input and output in the same window. Think any command line interface.
It is similar to PST. You have an input box that you type into and then press enter, and the results are shown below in the terminal.
Bruce