Problem solved! Beau can now have his very own toolbar for multiple file support A mouse over on the numbered toolbar buttons now provide file names for the individual buttons.
How was it accomplished? I am glad you asked Bruce's custom brew....
BOOL CMainFrame::OnToolTipNotify(UINT id, NMHDR* pNMHDR, LRESULT* pResult )
{
TCHAR szToolTipText[MAX_PATH] = _T("");
//Initialize the TOOLTIPTEXT structure.
TOOLTIPTEXT *pTTip = (TOOLTIPTEXT *)pNMHDR;
// idFrom contains the resource identifier for the toolbars buttons.
UINT ResourceID = pNMHDR->idFrom;
//The toolbar buttons needed have resource ID's between 32791 and 32799.
if(ResourceID > 32790 && ResourceID < 32800)
{
switch(ResourceID)
{
case IDC_RUN1:
// Set the tooltip text for button #1.
lstrcpy(szToolTipText, m_strFileTitle1);
pTTip->lpszText = szToolTipText;
break;
case IDC_RUN2:
// Set the tooltip text for button #2.
lstrcpy(szToolTipText, m_strFileTitle2);
pTTip->lpszText = szToolTipText;
break;
case IDC_RUN3:
// Set the tooltip text for button #3.
lstrcpy(szToolTipText, m_strFileTitle3);
pTTip->lpszText = szToolTipText;
break;
case IDC_RUN4:
// Set the tooltip text for button #4.
lstrcpy(szToolTipText, m_strFileTitle4);
pTTip->lpszText = szToolTipText;
break;
case IDC_RUN5:
// Set the tooltip text for button #5.
lstrcpy(szToolTipText, m_strFileTitle5);
pTTip->lpszText = szToolTipText;
break;
case IDC_RUN6:
// Set the tooltip text for button #6.
lstrcpy(szToolTipText, m_strFileTitle6);
pTTip->lpszText = szToolTipText;
break;
case IDC_RUN7:
// Set the tooltip text for button #7.
lstrcpy(szToolTipText, m_strFileTitle7);
pTTip->lpszText = szToolTipText;
break;
case IDC_RUN8:
// Set the tooltip text for button #8.
lstrcpy(szToolTipText, m_strFileTitle8);
pTTip->lpszText = szToolTipText;
break;
case IDC_RUN9:
// Set the tooltip text for button #9.
lstrcpy(szToolTipText, m_strFileTitle9);
pTTip->lpszText = szToolTipText;
break;
}
return TRUE;
}
return FALSE;
}
This code is similar to some other code on the net, but this is also unique, because it specifically deals with toolbar buttons. It took some experimenting to find the right combination.
Before I finish the topic of the multi-file support toolbar and the function up above which provides the file names on mouse over, I would also like to document some additional code which has been added to that function. Status bar updates have also been added to this function, to reflect the file name supported by each button.
BOOL CMainFrame::OnToolTipNotify(UINT id, NMHDR* pNMHDR, LRESULT* pResult )
{
//Initialize the TOOLTIPTEXT structure.
TOOLTIPTEXT *pTTip = (TOOLTIPTEXT *)pNMHDR;
// idFrom contains the resource identifier for the toolbars buttons.
UINT ResourceID = pNMHDR->idFrom;
//The toolbar buttons needed have resource ID's between 32791 and 32799.
if(ResourceID > 32790 && ResourceID < 32800)
{
TCHAR szToolTipText[MAX_PATH] = _T("");
CString strStatusBarText;
strStatusBarText = "Run File: ";
switch(ResourceID)
{
case IDC_RUN1:
if(m_strFileTitle1 != "")
{
// Set the tooltip text for button #1.
lstrcpy(szToolTipText, m_strFileTitle1);
pTTip->lpszText = szToolTipText;
//Also update status bar
strStatusBarText += m_strFileTitle1;
m_wndStatusBar.SetPaneText(0, strStatusBarText, TRUE);
}
break;
case IDC_RUN2:
if(m_strFileTitle2 != "")
{
// Set the tooltip text for button #2.
lstrcpy(szToolTipText, m_strFileTitle2);
pTTip->lpszText = szToolTipText;
//Also update status bar
strStatusBarText += m_strFileTitle2;
m_wndStatusBar.SetPaneText(0, strStatusBarText, TRUE);
}
break;
case IDC_RUN3:
if(m_strFileTitle3 != "")
{
// Set the tooltip text for button #3.
lstrcpy(szToolTipText, m_strFileTitle3);
pTTip->lpszText = szToolTipText;
//Also update status bar
strStatusBarText += m_strFileTitle3;
m_wndStatusBar.SetPaneText(0, strStatusBarText, TRUE);
}
break;
case IDC_RUN4:
if(m_strFileTitle4 != "")
{
// Set the tooltip text for button #4.
lstrcpy(szToolTipText, m_strFileTitle4);
pTTip->lpszText = szToolTipText;
//Also update status bar
strStatusBarText += m_strFileTitle4;
m_wndStatusBar.SetPaneText(0, strStatusBarText, TRUE);
}
break;
case IDC_RUN5:
if(m_strFileTitle5 != "")
{
// Set the tooltip text for button #5.
lstrcpy(szToolTipText, m_strFileTitle5);
pTTip->lpszText = szToolTipText;
//Also update status bar
strStatusBarText += m_strFileTitle5;
m_wndStatusBar.SetPaneText(0, strStatusBarText, TRUE);
}
break;
case IDC_RUN6:
if(m_strFileTitle6 != "")
{
// Set the tooltip text for button #6.
lstrcpy(szToolTipText, m_strFileTitle6);
pTTip->lpszText = szToolTipText;
//Also update status bar
strStatusBarText += m_strFileTitle6;
m_wndStatusBar.SetPaneText(0, strStatusBarText, TRUE);
}
break;
case IDC_RUN7:
if(m_strFileTitle7 != "")
{
// Set the tooltip text for button #7.
lstrcpy(szToolTipText, m_strFileTitle7);
pTTip->lpszText = szToolTipText;
//Also update status bar
strStatusBarText += m_strFileTitle7;
m_wndStatusBar.SetPaneText(0, strStatusBarText, TRUE);
}
break;
case IDC_RUN8:
if(m_strFileTitle8 != "")
{
// Set the tooltip text for button #8.
lstrcpy(szToolTipText, m_strFileTitle8);
pTTip->lpszText = szToolTipText;
//Also update status bar
strStatusBarText += m_strFileTitle8;
m_wndStatusBar.SetPaneText(0, strStatusBarText, TRUE);
}
break;
case IDC_RUN9:
if(m_strFileTitle9 != "")
{
// Set the tooltip text for button #9.
lstrcpy(szToolTipText, m_strFileTitle9);
pTTip->lpszText = szToolTipText;
//Also update status bar
strStatusBarText += m_strFileTitle9;
m_wndStatusBar.SetPaneText(0, strStatusBarText, TRUE);
}
break;
}
return TRUE;
}
return FALSE;
}
EDIT: The previous code in this post has been changed to show some new changes
Since this thread has received a fair amount of input, I thought some of you might like to get a sneak preview of the actual GUI, so I am now providing a semi-functional program that will give you the look and feel of PropCom. You won't be able to perform any serial communication with it just yet, but you can give the GUI a test drive and provide feedback from your experience.
Please remember, there is still quite a bit of work that needs to be done.
Perhaps I jumped the gun yesterday by uploading a sneak peak preview program, because there really was not much to see and it has come a long way since then.
This is just an update to let you know that it won't be long and you folks will have a new serial terminal. I estimate that it should be done in another couple of days.
I apologize for for not getting this done, but it is not far from being done, perhaps a day or two programming. There is a lot that has been done on this project. Between handling my patent application, trying to get my business off the ground, and developing new products, there is very little free time on my hands. Until I get the time to finish it, just in case someone my find it useful, here are the project files. You will need at least Visual Studio C++ 6.0 to compile the source files. In fact, it would only take a minute or two to make it capable of serial communication. Anyhow, if there are any questions, I will try to answer them in a timely fashion.
Thanks a lot, Bruce! According to the screenshot you made a while ago the part you prepared would perfectly fit. Now I have to check the sources and learn alot ... never used C++ in the windows context.
Hopefully the Visual C++ Express is enought to make the code run.
Did not see some licensing information so far, so do you allow usage for non-profit projects.
Just some more words about what I plan to do:
I think a propeller is not made to work as a server. On the other hand I'd like to spread propellers here and there in my house. Some might be spinnerets, some directly attached to a PC via serial. Some maybe with a simple EIB ( European Installation Bus ) ... bluetooth ... RF????
But everything they should send/receive are simple messages for example containing sensor data and commands. To allow having a nice web-interface I simply plan to use an XAMPP propably with JQuery for some nice controls like sliders and stuff.
The software I started with will simply connect to all the propellers. Currently I started with directly attached propellers which are connected via serial interface. Later other interfaces should follow. The other end of the software behaves like a server waiting for requests coming from the PHP of XAMPP.
The serial classes were written by Ramon De Klien. According to the place of origination, http://www.codeproject.com/KB/system/serial.aspx, he places no licensing restrictions on the code. He just wants his name to remain in the copyright notice and he wants any changes to his original code to be marked. His files consist of: Serial.h, Serial.cpp, SerialEx.h, SerialEx.cpp, SerialWnd.h, SerialWnd.cpp, and SerialMFC.h. If you really want to understand his code and what I have done, I suggest you read his article and download the original sample project at the link provided above.
The LED class was written by Monte Variakojis, of course he wants his name to remain in the copyright, and he doesn't want anyone profiting monetarily from this class. And here is the place of origination for that code: http://www.codeguru.com/Cpp/controls/controls/article.php/c2351.
FileServices.h and cpp is a mixture of my code and snippets I picked up here and there. Don't underestimate these files, they are very powerful. I threw them in the mix, just to give you guys some powerful code. (Notice the icon data structures in there ) These files will allow anyone to create their own distributal exe files. With these files a person can write resources from the exe (including exe(s)) to a destination, these files also allow the creation of program and internet shortcuts, as well as handling a bunch of other things such as file paths. It is one of my favorite source code files. I hope you enjoy it.
All the remaining code was written by me, which basically makes and wires the GUI. You can do whatever you want with my code, I place no restriction on it whatsoever. All I ask is to please leave the name PropCom reserved for me for when I finish this project.
Andreas, I really suggest reading the original serial article from the link above. It will help greatly in the comprehension of the source code and my project.
Did Visual C++ Express work for you? If not, Ebay has several Visual C++ 6.0 Standard Edition(s) available at very reasonable prices that will work perfectly for those project files.
I also have an extra Standard Edition laying around. I bought the Standard Edition when I started programming in C++, but then I needed the features of the Professional Editon, so I had to buy that one also. Of course I use the Professional Editon and now the Standard Edition is nothing more than glorified dust collector.
Please keep me updated, because I can foresee a lot of potential uses for those serial files, and I would like to hear about someone putting them to good use.
Nope ... did not work so far. VC++ express told me that it has to convert the project, but nothing happened after confirming.
To be honest I don't like coding with VC so far. I am so much used to code completion from Java. And I also doubt that I like the windows only approach. Something like the Qt or wxWidgets library sounds good to me either. Let's see ....
Hmmmm..... All I can say is this.... It is not the easiest programming environment to learn and get the hang of, but once you get a grasp on it, you have a very powerful tool at your fingertips.
I am sure I lost a lot of hair during my learning process of VC++, but I must say, I am glad that I know it now.
Actually, this project would be a very good place to start, instead of starting from scratch. If you change your mind and pick up a copy of Visual C++ 6.0, perhaps I can occassionally help. I know it is outdated software, but it is a good starting point and now reasonably priced.
Just exactly what did you see in one of the pics that interested you?
I thought I read or have seen something like a multi-tab interface which allows to connect to multiple propellers. Did not see it in the .exe you packed into the zip-file, but I think it won't be to hard to add that.
But also the rest would fit pretty good. As I said it will be a piece of software like a messaging server. On a TCP port it will wait for connections coming from web-servers (XAMPP) and on the other end it will have one or more connections to propellers. Some connected via TCP (a spinneret), or connected directly via serial interface ... or bluetooth or RF ....
This functionallity itself does not need any GUI, but I like the idea to have one for easier setup and for having an eye on what the webservers and propellers talk about. So the difference to a terminal is simply that there is no user (only for debug purposes) talking with the propeller and the data send from the propeller has to be displayed AND buffered.
The protocol would be an easy one which allows to send commands to the propellers and read data like sonsor values from the propellers. Let's call it the Propocol(tm) ;o)
It was originally my intention to make PropCom a multiple document interface and that is why it had the tabs. However, I decided to make it a single document interface instead, which eliminated the tabs. If you are going to have more than one comm line, I imagine it is going to get a little complicated. That project in it's current state is no where near being able to do that.
I understand that the GUI is unnecessary, but I think if I would try to do something like that, I think I would go back to the multiple document interface, and at which point, I would start a new thread to monitor each connection. With each tab representing a different document (connection) and thread.
@MagIO2, if you don't have an adverse reaction to .NET, here's an open source serial project I built for logging debug info from the Propeller. I use it a lot it for Spinneret development to log headers and such. It's Mono compatible too. Wiring up a TCP listener would be fairly straight forward.
I got a little sidetracked from my LDI project and I have been doing a little PERL programming, which eventually landed me back to this old thread.
The PERL script, which is already working perfectly, writes a numerical value to a text file, on one of my websites. I need to retrieve this value from the website and get it transferred to a Propeller board.
Of course the project set forth in this thread is way over-blown for what I actually need to do, but the necessary code is in this project. I suppose one day I should finish this project, because it really would not take that much to complete it.
After thinking about this for a bit, I have come to the conclusion that it would probably be much easier to just finish this project, then to slice it and dice to come up with something a little leaner and meaner.
Once it is finished, then I could just add a little code for my special needs, and I would have the benefit of having a nice serial program. However, I will have to do a lot of reviewing of this thread and the existing code to get a grasp on what I was doing and where I was at in the project. After I little review of this thread, I see I was estimating about two days to complete it, but after letting it set for seven years, it will most likely take two weeks at this point
Beyond any doubt, my C++ and MFC skills are getting rusty in my old age. As they say, "If you don't use it, you lose it".
For several hours, I was completely lost during my review of the old programming, because it just did not make any sense to me. I could not find any handler for the property sheet used to configure the port settings. To my amazement, I finally found it in the main frame window code, which is starting to make sense to me now
Within the main frame window code, I found a little comment that I left behind so many years ago, which states:
//////////////////////////////////
// This needs additional work to reflect actual port state
DUH! Hmmmm.... I guess I will have to put on my thinking cap Now where did I put that darn thing
What a f'ed up source who wrote this stuff, - hmm - myself.
What the hell I was thinking, then. And here we come to the main problem of commenting source.
At the time you write it, it is perfectly clear to you what things are doing and why. Even in FORTH.
But years later you can just follow the WHAT by looking at the code, but the WHY needs to be explained in the comments.
Except COBOL, there the source usually says it all. It is mostly readable like plain English.
And going away from COBOL I had to learn that C/C# and stuff like that is NOT self documenting at all.
The last decades I spend rewriting code already written. In case of COBOL quite easy, you seldom have to change the source because of changes in the compilers.
Windows programming on the other hand needs constant changes, new Net Framework every 1 or 2 years, new server version, new client versions, a constant struggle.
Some 10 years ago I started rewriting some software made by myself in 1997 using VS basic 6.0 and access 97. Now 10 years later I am still rewriting the code, now finally running on Windows 2016 servers. Half of my time I spend just keep stuff running, new development slows down.
Sometimes I think I should rewrite the whole Backend in COBOL and just use VS for the user interfaces...
What a f'ed up source who wrote this stuff, - hmm - myself.
What the hell I was thinking, then. And here we come to the main problem of commenting source.
Back then, when it was all still fresh in my mind, I should have finished the darn thing, because I am certain that I knew everything that had to be done.
Looking at it now, I added so much stuff, building the GUI, and a lot of it needs some work here and there, to get those portions working.
I guess I will just have to pick it apart and get one thing working at a time.
As far as my previous comment:
Within the main frame window code, I found a little comment that I left behind so many years ago, which states:
It appears that I need to add quite a few more member variables, just to get the values out of the property sheet and pages, and update the status of the port being used and the configuration.
And I "DEFINITELY" did not provide myself with a enough comments
Upon being rudely woken up at 3:00AM this morning, I decided to toy around with this program a bit more. Just out of curiosity, I commented out most of the Update Command Handlers, and to my joy, most of my GUI is back to being fully functional, which makes me VERY HAPPY
For some odd reason, these Update Command Handlers are not working properly when the property sheet and pages are updated. Maybe that is why I took a break from this program so many years ago. Oh well, time to get to the bottom of it now.
Comments
Problem solved! Beau can now have his very own toolbar for multiple file support
How was it accomplished? I am glad you asked
BOOL CMainFrame::OnToolTipNotify(UINT id, NMHDR* pNMHDR, LRESULT* pResult ) { TCHAR szToolTipText[MAX_PATH] = _T(""); //Initialize the TOOLTIPTEXT structure. TOOLTIPTEXT *pTTip = (TOOLTIPTEXT *)pNMHDR; // idFrom contains the resource identifier for the toolbars buttons. UINT ResourceID = pNMHDR->idFrom; //The toolbar buttons needed have resource ID's between 32791 and 32799. if(ResourceID > 32790 && ResourceID < 32800) { switch(ResourceID) { case IDC_RUN1: // Set the tooltip text for button #1. lstrcpy(szToolTipText, m_strFileTitle1); pTTip->lpszText = szToolTipText; break; case IDC_RUN2: // Set the tooltip text for button #2. lstrcpy(szToolTipText, m_strFileTitle2); pTTip->lpszText = szToolTipText; break; case IDC_RUN3: // Set the tooltip text for button #3. lstrcpy(szToolTipText, m_strFileTitle3); pTTip->lpszText = szToolTipText; break; case IDC_RUN4: // Set the tooltip text for button #4. lstrcpy(szToolTipText, m_strFileTitle4); pTTip->lpszText = szToolTipText; break; case IDC_RUN5: // Set the tooltip text for button #5. lstrcpy(szToolTipText, m_strFileTitle5); pTTip->lpszText = szToolTipText; break; case IDC_RUN6: // Set the tooltip text for button #6. lstrcpy(szToolTipText, m_strFileTitle6); pTTip->lpszText = szToolTipText; break; case IDC_RUN7: // Set the tooltip text for button #7. lstrcpy(szToolTipText, m_strFileTitle7); pTTip->lpszText = szToolTipText; break; case IDC_RUN8: // Set the tooltip text for button #8. lstrcpy(szToolTipText, m_strFileTitle8); pTTip->lpszText = szToolTipText; break; case IDC_RUN9: // Set the tooltip text for button #9. lstrcpy(szToolTipText, m_strFileTitle9); pTTip->lpszText = szToolTipText; break; } return TRUE; } return FALSE; }This code is similar to some other code on the net, but this is also unique, because it specifically deals with toolbar buttons. It took some experimenting to find the right combination.
BOOL CMainFrame::OnToolTipNotify(UINT id, NMHDR* pNMHDR, LRESULT* pResult ) { //Initialize the TOOLTIPTEXT structure. TOOLTIPTEXT *pTTip = (TOOLTIPTEXT *)pNMHDR; // idFrom contains the resource identifier for the toolbars buttons. UINT ResourceID = pNMHDR->idFrom; //The toolbar buttons needed have resource ID's between 32791 and 32799. if(ResourceID > 32790 && ResourceID < 32800) { TCHAR szToolTipText[MAX_PATH] = _T(""); CString strStatusBarText; strStatusBarText = "Run File: "; switch(ResourceID) { case IDC_RUN1: if(m_strFileTitle1 != "") { // Set the tooltip text for button #1. lstrcpy(szToolTipText, m_strFileTitle1); pTTip->lpszText = szToolTipText; //Also update status bar strStatusBarText += m_strFileTitle1; m_wndStatusBar.SetPaneText(0, strStatusBarText, TRUE); } break; case IDC_RUN2: if(m_strFileTitle2 != "") { // Set the tooltip text for button #2. lstrcpy(szToolTipText, m_strFileTitle2); pTTip->lpszText = szToolTipText; //Also update status bar strStatusBarText += m_strFileTitle2; m_wndStatusBar.SetPaneText(0, strStatusBarText, TRUE); } break; case IDC_RUN3: if(m_strFileTitle3 != "") { // Set the tooltip text for button #3. lstrcpy(szToolTipText, m_strFileTitle3); pTTip->lpszText = szToolTipText; //Also update status bar strStatusBarText += m_strFileTitle3; m_wndStatusBar.SetPaneText(0, strStatusBarText, TRUE); } break; case IDC_RUN4: if(m_strFileTitle4 != "") { // Set the tooltip text for button #4. lstrcpy(szToolTipText, m_strFileTitle4); pTTip->lpszText = szToolTipText; //Also update status bar strStatusBarText += m_strFileTitle4; m_wndStatusBar.SetPaneText(0, strStatusBarText, TRUE); } break; case IDC_RUN5: if(m_strFileTitle5 != "") { // Set the tooltip text for button #5. lstrcpy(szToolTipText, m_strFileTitle5); pTTip->lpszText = szToolTipText; //Also update status bar strStatusBarText += m_strFileTitle5; m_wndStatusBar.SetPaneText(0, strStatusBarText, TRUE); } break; case IDC_RUN6: if(m_strFileTitle6 != "") { // Set the tooltip text for button #6. lstrcpy(szToolTipText, m_strFileTitle6); pTTip->lpszText = szToolTipText; //Also update status bar strStatusBarText += m_strFileTitle6; m_wndStatusBar.SetPaneText(0, strStatusBarText, TRUE); } break; case IDC_RUN7: if(m_strFileTitle7 != "") { // Set the tooltip text for button #7. lstrcpy(szToolTipText, m_strFileTitle7); pTTip->lpszText = szToolTipText; //Also update status bar strStatusBarText += m_strFileTitle7; m_wndStatusBar.SetPaneText(0, strStatusBarText, TRUE); } break; case IDC_RUN8: if(m_strFileTitle8 != "") { // Set the tooltip text for button #8. lstrcpy(szToolTipText, m_strFileTitle8); pTTip->lpszText = szToolTipText; //Also update status bar strStatusBarText += m_strFileTitle8; m_wndStatusBar.SetPaneText(0, strStatusBarText, TRUE); } break; case IDC_RUN9: if(m_strFileTitle9 != "") { // Set the tooltip text for button #9. lstrcpy(szToolTipText, m_strFileTitle9); pTTip->lpszText = szToolTipText; //Also update status bar strStatusBarText += m_strFileTitle9; m_wndStatusBar.SetPaneText(0, strStatusBarText, TRUE); } break; } return TRUE; } return FALSE; }EDIT: The previous code in this post has been changed to show some new changes
Since this thread has received a fair amount of input, I thought some of you might like to get a sneak preview of the actual GUI, so I am now providing a semi-functional program that will give you the look and feel of PropCom. You won't be able to perform any serial communication with it just yet, but you can give the GUI a test drive and provide feedback from your experience.
Please remember, there is still quite a bit of work that needs to be done.
Bruce
Perhaps I jumped the gun yesterday by uploading a sneak peak preview program, because there really was not much to see and it has come a long way since then.
This is just an update to let you know that it won't be long and you folks will have a new serial terminal. I estimate that it should be done in another couple of days.
Bruce
What about a sniffer tool or a virtual port?
Take a look at this site: http://www.virtualserialport.com/products/
Luc
http://forums.parallax.com/showthread.php?134738-Simple-.NET-Serial-Terminal
I apologize for for not getting this done, but it is not far from being done, perhaps a day or two programming. There is a lot that has been done on this project. Between handling my patent application, trying to get my business off the ground, and developing new products, there is very little free time on my hands. Until I get the time to finish it, just in case someone my find it useful, here are the project files. You will need at least Visual Studio C++ 6.0 to compile the source files. In fact, it would only take a minute or two to make it capable of serial communication. Anyhow, if there are any questions, I will try to answer them in a timely fashion.
Additionally, I am going to get my patent.
Bruce
C.W.
Hopefully the Visual C++ Express is enought to make the code run.
Did not see some licensing information so far, so do you allow usage for non-profit projects.
Just some more words about what I plan to do:
I think a propeller is not made to work as a server. On the other hand I'd like to spread propellers here and there in my house. Some might be spinnerets, some directly attached to a PC via serial. Some maybe with a simple EIB ( European Installation Bus ) ... bluetooth ... RF????
But everything they should send/receive are simple messages for example containing sensor data and commands. To allow having a nice web-interface I simply plan to use an XAMPP propably with JQuery for some nice controls like sliders and stuff.
The software I started with will simply connect to all the propellers. Currently I started with directly attached propellers which are connected via serial interface. Later other interfaces should follow. The other end of the software behaves like a server waiting for requests coming from the PHP of XAMPP.
The serial classes were written by Ramon De Klien. According to the place of origination, http://www.codeproject.com/KB/system/serial.aspx, he places no licensing restrictions on the code. He just wants his name to remain in the copyright notice and he wants any changes to his original code to be marked. His files consist of: Serial.h, Serial.cpp, SerialEx.h, SerialEx.cpp, SerialWnd.h, SerialWnd.cpp, and SerialMFC.h. If you really want to understand his code and what I have done, I suggest you read his article and download the original sample project at the link provided above.
The LED class was written by Monte Variakojis, of course he wants his name to remain in the copyright, and he doesn't want anyone profiting monetarily from this class. And here is the place of origination for that code: http://www.codeguru.com/Cpp/controls/controls/article.php/c2351.
FileServices.h and cpp is a mixture of my code and snippets I picked up here and there. Don't underestimate these files, they are very powerful. I threw them in the mix, just to give you guys some powerful code. (Notice the icon data structures in there
All the remaining code was written by me, which basically makes and wires the GUI. You can do whatever you want with my code, I place no restriction on it whatsoever. All I ask is to please leave the name PropCom reserved for me for when I finish this project.
Andreas, I really suggest reading the original serial article from the link above. It will help greatly in the comprehension of the source code and my project.
Bruce
Did Visual C++ Express work for you? If not, Ebay has several Visual C++ 6.0 Standard Edition(s) available at very reasonable prices that will work perfectly for those project files.
I also have an extra Standard Edition laying around. I bought the Standard Edition when I started programming in C++, but then I needed the features of the Professional Editon, so I had to buy that one also. Of course I use the Professional Editon and now the Standard Edition is nothing more than glorified dust collector.
Please keep me updated, because I can foresee a lot of potential uses for those serial files, and I would like to hear about someone putting them to good use.
Bruce
To be honest I don't like coding with VC so far. I am so much used to code completion from Java. And I also doubt that I like the windows only approach. Something like the Qt or wxWidgets library sounds good to me either. Let's see ....
Hmmmm..... All I can say is this.... It is not the easiest programming environment to learn and get the hang of, but once you get a grasp on it, you have a very powerful tool at your fingertips.
I am sure I lost a lot of hair during my learning process of VC++, but I must say, I am glad that I know it now.
Actually, this project would be a very good place to start, instead of starting from scratch. If you change your mind and pick up a copy of Visual C++ 6.0, perhaps I can occassionally help. I know it is outdated software, but it is a good starting point and now reasonably priced.
Just exactly what did you see in one of the pics that interested you?
Bruce
But also the rest would fit pretty good. As I said it will be a piece of software like a messaging server. On a TCP port it will wait for connections coming from web-servers (XAMPP) and on the other end it will have one or more connections to propellers. Some connected via TCP (a spinneret), or connected directly via serial interface ... or bluetooth or RF ....
This functionallity itself does not need any GUI, but I like the idea to have one for easier setup and for having an eye on what the webservers and propellers talk about. So the difference to a terminal is simply that there is no user (only for debug purposes) talking with the propeller and the data send from the propeller has to be displayed AND buffered.
The protocol would be an easy one which allows to send commands to the propellers and read data like sonsor values from the propellers. Let's call it the Propocol(tm) ;o)
It was originally my intention to make PropCom a multiple document interface and that is why it had the tabs. However, I decided to make it a single document interface instead, which eliminated the tabs. If you are going to have more than one comm line, I imagine it is going to get a little complicated. That project in it's current state is no where near being able to do that.
I understand that the GUI is unnecessary, but I think if I would try to do something like that, I think I would go back to the multiple document interface, and at which point, I would start a new thread to monitor each connection. With each tab representing a different document (connection) and thread.
Bruce
www.agaverobotics.com\SerialPortDemo.zip
The PERL script, which is already working perfectly, writes a numerical value to a text file, on one of my websites. I need to retrieve this value from the website and get it transferred to a Propeller board.
Of course the project set forth in this thread is way over-blown for what I actually need to do, but the necessary code is in this project. I suppose one day I should finish this project, because it really would not take that much to complete it.
Once it is finished, then I could just add a little code for my special needs, and I would have the benefit of having a nice serial program. However, I will have to do a lot of reviewing of this thread and the existing code to get a grasp on what I was doing and where I was at in the project. After I little review of this thread, I see I was estimating about two days to complete it, but after letting it set for seven years, it will most likely take two weeks at this point
For several hours, I was completely lost during my review of the old programming, because it just did not make any sense to me. I could not find any handler for the property sheet used to configure the port settings. To my amazement, I finally found it in the main frame window code, which is starting to make sense to me now
Within the main frame window code, I found a little comment that I left behind so many years ago, which states:
DUH! Hmmmm.... I guess I will have to put on my thinking cap
What the hell I was thinking, then. And here we come to the main problem of commenting source.
At the time you write it, it is perfectly clear to you what things are doing and why. Even in FORTH.
But years later you can just follow the WHAT by looking at the code, but the WHY needs to be explained in the comments.
Except COBOL, there the source usually says it all. It is mostly readable like plain English.
And going away from COBOL I had to learn that C/C# and stuff like that is NOT self documenting at all.
The last decades I spend rewriting code already written. In case of COBOL quite easy, you seldom have to change the source because of changes in the compilers.
Windows programming on the other hand needs constant changes, new Net Framework every 1 or 2 years, new server version, new client versions, a constant struggle.
Some 10 years ago I started rewriting some software made by myself in 1997 using VS basic 6.0 and access 97. Now 10 years later I am still rewriting the code, now finally running on Windows 2016 servers. Half of my time I spend just keep stuff running, new development slows down.
Sometimes I think I should rewrite the whole Backend in COBOL and just use VS for the user interfaces...
Enjoy!
Mike
Back then, when it was all still fresh in my mind, I should have finished the darn thing, because I am certain that I knew everything that had to be done.
Looking at it now, I added so much stuff, building the GUI, and a lot of it needs some work here and there, to get those portions working.
I guess I will just have to pick it apart and get one thing working at a time.
As far as my previous comment:
It appears that I need to add quite a few more member variables, just to get the values out of the property sheet and pages, and update the status of the port being used and the configuration.
And I "DEFINITELY" did not provide myself with a enough comments
For some odd reason, these Update Command Handlers are not working properly when the property sheet and pages are updated. Maybe that is why I took a break from this program so many years ago. Oh well, time to get to the bottom of it now.