Well that was very nice and informative, thank you so much for your time.
The licensed edit control that you referrred to, would you be referring to the main edit control of the Propeller Tool (main window where everything is typed)?
If so, why would you license it instead of taking a day or two to create a real nice one that would be proprietary to Parallax?
Well that was very nice and informative, thank you so much for your time.
The licensed edit control that you referrred to, would you be referring to the main edit control of the Propeller Tool (main window where everything is typed)?
If so, why would you license it instead of taking a day or two to create a real nice one that would be proprietary to Parallax?
Bruce
Hey Bruce,
You're dealing with the business stiff, so you'll need to grant me some freedom on my explanation of the technical side of things.
Way far back - when we started the Windows version of the BASIC Stamp IDE - we licensed Dream Company's "Dream Edit" and "Dream Memo" controls, with source code. This license allows us to use the components and update the source code as we desire. But it doesn't let us release the source to the public as it is (or was) owned and controlled by Dream Company. We've heavily edited the code along the way and now this licensed edit control has made its way into the Propeller Tool.
Around 2005, Altium Limited purchased Dream Company and absorbed their IP (not sure of the legal arrangement here - Dream Company may be a division of Altium today).
The objective is that we obtain written confirmation from Altium that they do own the IP in question, that they agree to let Parallax release modified versions as source, and that we will update the source to include any legal references.
Again, I think we have Altium's support to make this happen. Internally our team is fired up to let the Prop Tool loose in open-source format.
But your question was "why" didn't we take a day or two to create a real nice control that would be proprietary to Parallax? We initially started to use this edit control because it saved us some time in developing our own in exchange for whatever we paid for it. The edit control is the set of objects that we built the text entering and display around. I'm not sure we could have written this in a few days on our own. I've never seen anything take a few days. Further, there was little "open source" activity going on, or at least it wasn't on our radar more than ten years ago, so there was little thought given to future issues regarding open-source (let alone multi-platform/OS compatibility).
I have not had a chance to thoroughly look at this, because I am currently preoccupied, but from the pics, this open source edit control looks pretty nice.
Excellent news Ken, and thanks to the community members helping out in this area.
I appreciate all the "pro" level comments, and would like to add that no matter how the changes go, please give significant review to the default tool workflow. That needs to be simple, like it is now, with the options there for those that grow to want / need them.
The barrier for entry on Propeller is very low in terms of what one has to know to get stuff happening. Let's keep that differentiator in play.
Hi folks,
As Ken said above I am working on the port of Chip's Spin/PASM compiler from assembler to C/C++. Here's some info about my progress, and plans.
There is about 7800 lines of x86 assembly code, and I have processed about 2300 lines of it into C/C++. I'm tackling this is a mostly bottom up way, converting the lowest level routines that are used all over the code first, and working upwards. Basically I take the assembler and do an almost literal translation, and then I go over it and reduce it, if possible, to simpler C/C++ code that achieves the task. The end result may not be the ideal C/C++ code that could be written to do the compilation, but it should produce the same results as the asm code given the same inputs.
Once that phase is completed, it should be able to be used in place of the assembler code in the Prop Tool. Also, I will end up with a C/C++ port of most of the code in Propellent.dll, since I need it for testing the C/C++ version of the compiler (as I don't have the Delphi compiler). So, it's likely that a C/C++ variant of Propellent.dll will be made.
After that is working, my hope is to add many of the features that have been requested from users (myself included) and that Parallax wants. High up on that list for me are things like, a preprocessor pass, dead code elimination, and so on.
There are some details that I will likely run into that we'll have to discuss when I get to them. Such as some details about the floating point constants and expression handling. I'm sure there are other things as well.
The C/C++ code I am producing is basically C++ minus templates and the STL. I also am using standard C library stuff (stdlib, stdio, etc.) instead of the C++ equivalents. I chose this path because I wanted to use some C++ features, but I wanted the code to be mostly readable by someone that is only familiar with C. In any case, the end result code will be fairly easy to convert to straight C or to use more of C++ features as desired by anyone who chooses to work with it.
I am using Visual Studio 2008 to do the porting work, but I also plan to make sure the results compile with gnu C++.
If you have any other questions, feel free to ask, I'll do my best to answer.
I would like to add something about those links I provided. I noticed at the bottom of the page that the author stated:
Do not publish any part of this code or article on other websites.
But I bet he probably wouldn't mind if asked nicely.
For the rest of you at PropLand, this is the start of a decent editor, it is written in Visual Studio C++. With a call to LoadLibrary, to import the Propellent functions, an ambitious person could present us with a new editor in short order.
Phil will get a bit cranky with this multi-faceted approach, ...
The mother of a good friend of mine always told him when he was a kid, "Just do something, even if it's wrong." Far from being cranky, I'm very hopeful. Doing three things is way better than doing nothing, and I'm confident that at least one of them will be right! (This also happens to be my approach to gardening. I'm a terrible gardener and don't really care at all for grubbing in the dirt. When I plant something, it's really up to the plant whether it grows or dies. So I'll plant several things, knowing the odds are pretty fair that one of them will survive.)
Seriously, given the talent being brought to bear, I'm looking forward to success across the board! Thanks for giving the Propeller dev tool chain the attention it deserves -- and for lightening the burden of my despair! With Parallax's backing and firm guidance, I'm confident that the dialect splintering I expressed a fear of will not occur.
Dream Memo that goes back aways. I have a Delphi 7 version of it which I think was the last release before Dream dissappeared. As far as I know it did not do Unicode which must have been one of Parallax mods to the code to allow the Unicode Font drawing chars for drawing circuits in comments.
@Ken I am a big fan of Delphi and still use it now that I am retired and have not seen any mention of Dream components since the 2001 time frame. The company is gone and I am surprised someone owns it, I believe Dream was an eastern Europe company.
I understand where your coming from Delphi and custom components, when they work and the vendor lives at least as long as your product all is great as you leverage the knowledge and time in writing the thing yourself, assuming you could even do that in the first place. However in writing several in house applications using Delphi most of the time things did not work as advertised and I spend many hours becoming a close email buddy with the component vendor getting it to work at all and several times when you single step into the trouble area you realize no one at the component vendor must have ever tested this as it never could have worked.
You leverage their problems as well as the good . With that said my two cents is it is still better to have an application written using tools native to each platform rather than the write once runs everywhere method. I have never seen that work very well, usually ends up write once to some called standard which is not and runs poorly everywhere is the result.
I am not real knowledgeable on open source but to me would a company want to bet the company on something written using software everyone has there hands in. Could you imagine Toyota saying Senator we do not know who made those mods to the Open Source Lib we used for the accellerator code.
A custom application makes more sense for selling your products to companys because you have control of it and they will trust it . Course another way to put it I guess is an in house app supplied by a vendor and written by someone who has no idea what he is doing is better because at least they know who to blame. LOL.
The first step is really to have a grammar that describes spin...
I was going to suggest this here as well. Having a formal definition of Spin's syntax is one way to keep a multi-pronged attack focused on a single language.
I was going to suggest this here as well. Having a formal definition of Spin's syntax is one way to keep a multi-pronged attack focused on a single language.
-Phil
I am glad that things are changing for the better and love the Spin's syntax. But, this one I would love too see is Bit Addressing and know there is a way to do it and was shown in these forums. It is just idea to be tossed out their and know it may not change.
I have Brad's Spin Tool with PropBasic and like it has well. By having both compilers it aloud me to do write the same app a different way.
I addition to my other ongoing tasks, I have decided to create a new Spin editor, and I started on it this morning. I will probably work on it just a little everyday, so I am unsure of when it will be complete. As it stands, I will be almost in the same boat as Parallax with their Edit control, because I will be using an open source edit control that has some stipulations about posting the code to websites other than codeguru.com. So at this point, I am uncertain just how open my source code will be. However, I will attempt to contact the author of the Edit control and try to obtain his permission to post it here at Parallax along with my code.
I notice you said Visual C++. While I laud your initiative, I hope this does not imply that your editor will depend upon an installation of Microsoft's .NET framework on the user's computer.
Nah... I would not do that. It will be just be an exe file, but perhaps it might require Propellent.dll or the Propeller Tool to be installed on the target computer. I have to explore and review the Propellent documentation to see whether I can statically link to Propellent, or if Parallax requires it to remain seperate from the executable. If I can statically link than it should just be the installation of an exe.
Ken and Roy: A big thankyou I do know Parallax have a lot of work on their plate and are taking the prop seriously for commercial use, while not forgetting the hobby market. From this perspective we will all benefit. Way to go guys
1. All functions should be capable of being multi-line without "{}", and only being dependant upon that the first parameter start with a "(" and end with a ")", with any secondary function lines being indented, irregardless of how many lines it takes to write the function. This will provides for neater code. Suggested by Bruce
2. All lines should maintain state. Spaces, indents, and tabs, should be maintained on a line by line basis. Suggested by Bruce
3. Programming Communication Port Definition Statements. Suggested by Jonathan
4. Integrated debugging pane. Suggested by Andrewsi
5. Toolbar button for indenting or opposite of large blocks of code. Suggested by Andrewsi
6. Balloon window parameter listing for declared methods. In other words, after a method has been declared, if you call the function, as you type, it shows the missing parameters. Suggested by Bruce
7. Balloon warning if an array is referenced outside of its declared size. Suggested by Duane Degn
These are some great suggestions. I'm currently writing and IDE for Catalina and I'd like to add these as well. Plus there are some others that I have working that could be useful too.
PhiPi said
I notice you said Visual C++. While I laud your initiative, I hope this does not imply that your editor will depend upon an installation of Microsoft's .NET framework on the user's computer.
I'm writing using functions for a richtextbox, which is code common to C/VB/Java and is in the .net framework. But .net is bloatware, and even starting up the .net editor takes several minutes. So any suggestions for other platforms would be most useful.
One thing that the .net framework has are a whole lot of things in the IDE that make code writing so much easier. So to add to the list above:
* Collapse/Expand groups of text (ie you can shrink down functions once you know they work)
* Syntax color highlighting, comments in green, keywords in blue, quotes in red etc. Plus or minus backcolor too.
* Antocompletion of not just the program keywords, but also variable names that have been used in the program.
* Automatching of capitalisations, eg declare a variable MyVariable, then later on type myvariable and it changes to MyVariable
* Dropdown menus for anything that comes after a . (period) (I think this is the same as #6 above)
* Something that replicates the little arrows in the proptool that group things together (BST does not have this).
* Wavy lines under code with incorrect syntax
* Code help when the mouse is placed over keywords
* Turn on/off hidden characters (like in Word), so you can see spaces, tabs, linefeeds and carriage returns.
Can a richtextbox do all these things? I'm not sure but there are some clues after spending a little time searching Google. Can other code platforms do this too?
Shows the unit to interface with propellent.dll and some code calling it.
dll's do not link into your exe file, you use the dll and include it with your exe file.
I did not try the compile function in the dll but will give it a go. Something simple like a memo control and load a file and compile it.
I have a Delphi app that uses the dll to find a prop and download the code to it, that experiment worked.
A rich edit contol can accomplish everything that a standard edit can do and more. I notice that you added some things that should be added to the list. There are some very good ideas there, and I will add them soon. I am a bit of an old timer (not too old) but I learned and have stuck with Visual Studio C++ 6.0. It is a little antiquated, but I am certain that it is highly capable of creating an outstanding editor. But it would appear that the edit control and any supporting objects, would be the key to a nice editor. I have some nice source code which is a good start, but now I question if I should use it or create one from scratch. The source code I have, the guy used a common edit control and view and did paints. And now that you mention it, I am beginning to think that a rich edit control is better suited for the job. I will have to take a peek into rich edit and get back with you.
8. Error (preferred) or warning if the case (upper/lower) of a symbol-in-use disagrees with its case where it's defined. Spin might be case-independent, but it should at least be case-consistent.
How about auto-case correction, instead of an error or warning, that way you can just type without worrying about capitalization, and when it matches a symbol it auto corrects to be case consistent. Good suggestion.
Having been forced to program in the hideous PL/C in college, I'm not in favor of auto-anything. I'd rather simply be informed that something is amiss so I can fix it myself, rather than depending upon the IDE or compiler to fix my errors. Besides, I may type a symbol's usage before I define it in a DAT section.
In order to help all of us understand where these requests lie in the scope of all Propeller Tool improvements, I will review our internal list and see that the requests from this thread are incorporated into our list (either as accepted, under consideration, etc.). When I'm done I'll post the whole document on this thread. At least then it will be clear that the various requests are being tracked by Parallax and that your efforts amount to more than a forum post. I won't get involved in discussions about priorities since all of us have different viewpoints on what is most important. Last time I reviewed our list of Propeller Tool improvements it showed priority, so at least you'll be able to have some idea about what we're focusing on.
Okay, you have your error, but the error will be an undefined if the case does not match. However, auto correction will probably be a user choice option as part of the software.
Thank you for your post. You caught me talking out my rear. You are correct, it is a dll not a lib. Perhaps since Ken is being so nice to us, maybe he can get us a propellent lib file
My project will definitely be a MFC application, and I am going to run with CRichEditView and CRichEditCtrl, and create it from bare bones source. However, I can clearly see that I will have to brush up on the C++ since it has been a while. It is a good thing for me that I kept an enormous amount of documentation, examples, and samples.
Yeah! I think that's a fine feature, so long as it's a option. Sometimes those features get in the way, other times they rock. Could make a lot of sense. If this does get done, there is "best guess" and there is "multiple guess" options that could be done. If "multiple guess" is in the feature, please allow keyboard arrow keys and enter to select from the likely choices. In the past, I've seen that feature on applications and really liked it that way. When it's mouse only, the user has to change input contexts to complete something, and that gets tiresome quickly. If it's single guess, just pressing enter to advance past that input mode on successful guess is good. Multiple guess might make sense here for those people trying to remember instructions.
You guys just keep adding to the complexity of it and it might not ever get done While keyboard accelorators are nice, it all takes time to set up. If this keeps going, I will definitely need some volunteers to assist.
Comments
Well that was very nice and informative, thank you so much for your time.
The licensed edit control that you referrred to, would you be referring to the main edit control of the Propeller Tool (main window where everything is typed)?
If so, why would you license it instead of taking a day or two to create a real nice one that would be proprietary to Parallax?
Bruce
Hey Bruce,
You're dealing with the business stiff, so you'll need to grant me some freedom on my explanation of the technical side of things.
Way far back - when we started the Windows version of the BASIC Stamp IDE - we licensed Dream Company's "Dream Edit" and "Dream Memo" controls, with source code. This license allows us to use the components and update the source code as we desire. But it doesn't let us release the source to the public as it is (or was) owned and controlled by Dream Company. We've heavily edited the code along the way and now this licensed edit control has made its way into the Propeller Tool.
Around 2005, Altium Limited purchased Dream Company and absorbed their IP (not sure of the legal arrangement here - Dream Company may be a division of Altium today).
The objective is that we obtain written confirmation from Altium that they do own the IP in question, that they agree to let Parallax release modified versions as source, and that we will update the source to include any legal references.
Again, I think we have Altium's support to make this happen. Internally our team is fired up to let the Prop Tool loose in open-source format.
But your question was "why" didn't we take a day or two to create a real nice control that would be proprietary to Parallax? We initially started to use this edit control because it saved us some time in developing our own in exchange for whatever we paid for it. The edit control is the set of objects that we built the text entering and display around. I'm not sure we could have written this in a few days on our own. I've never seen anything take a few days. Further, there was little "open source" activity going on, or at least it wasn't on our radar more than ten years ago, so there was little thought given to future issues regarding open-source (let alone multi-platform/OS compatibility).
Any questions I can answer, I shall.
Ken Gracey
Parallax Inc.
I have not had a chance to thoroughly look at this, because I am currently preoccupied, but from the pics, this open source edit control looks pretty nice.
http://www.codeguru.com/cpp/controls/editctrl/editors/article.php/c509/Syntax-coloring-text-editor.htm
Of course it could use enhancements, which are mentioned.
And here is a link to a page where someone made modifications.
http://www.codeguru.com/cpp/controls/editctrl/editors/article.php/c485/Enhancements-to-Andrei-Stcherbatchenkos-Syntax-coloring-text-editor.htm
With something like this as a starting point, you could end up with a nice edit control. There are more out there, if this doesn't suit you.
Bruce
I appreciate all the "pro" level comments, and would like to add that no matter how the changes go, please give significant review to the default tool workflow. That needs to be simple, like it is now, with the options there for those that grow to want / need them.
The barrier for entry on Propeller is very low in terms of what one has to know to get stuff happening. Let's keep that differentiator in play.
As Ken said above I am working on the port of Chip's Spin/PASM compiler from assembler to C/C++. Here's some info about my progress, and plans.
There is about 7800 lines of x86 assembly code, and I have processed about 2300 lines of it into C/C++. I'm tackling this is a mostly bottom up way, converting the lowest level routines that are used all over the code first, and working upwards. Basically I take the assembler and do an almost literal translation, and then I go over it and reduce it, if possible, to simpler C/C++ code that achieves the task. The end result may not be the ideal C/C++ code that could be written to do the compilation, but it should produce the same results as the asm code given the same inputs.
Once that phase is completed, it should be able to be used in place of the assembler code in the Prop Tool. Also, I will end up with a C/C++ port of most of the code in Propellent.dll, since I need it for testing the C/C++ version of the compiler (as I don't have the Delphi compiler). So, it's likely that a C/C++ variant of Propellent.dll will be made.
After that is working, my hope is to add many of the features that have been requested from users (myself included) and that Parallax wants. High up on that list for me are things like, a preprocessor pass, dead code elimination, and so on.
There are some details that I will likely run into that we'll have to discuss when I get to them. Such as some details about the floating point constants and expression handling. I'm sure there are other things as well.
The C/C++ code I am producing is basically C++ minus templates and the STL. I also am using standard C library stuff (stdlib, stdio, etc.) instead of the C++ equivalents. I chose this path because I wanted to use some C++ features, but I wanted the code to be mostly readable by someone that is only familiar with C. In any case, the end result code will be fairly easy to convert to straight C or to use more of C++ features as desired by anyone who chooses to work with it.
I am using Visual Studio 2008 to do the porting work, but I also plan to make sure the results compile with gnu C++.
If you have any other questions, feel free to ask, I'll do my best to answer.
Thanks for the effort that you are putting forth. Sounds like a lot of work and I wish you well.
Bruce
I would like to add something about those links I provided. I noticed at the bottom of the page that the author stated:
But I bet he probably wouldn't mind if asked nicely.
For the rest of you at PropLand, this is the start of a decent editor, it is written in Visual Studio C++. With a call to LoadLibrary, to import the Propellent functions, an ambitious person could present us with a new editor in short order.
Bruce
Seriously, given the talent being brought to bear, I'm looking forward to success across the board! Thanks for giving the Propeller dev tool chain the attention it deserves -- and for lightening the burden of my despair!
-Phil
@Ken I am a big fan of Delphi and still use it now that I am retired and have not seen any mention of Dream components since the 2001 time frame. The company is gone and I am surprised someone owns it, I believe Dream was an eastern Europe company.
I understand where your coming from Delphi and custom components, when they work and the vendor lives at least as long as your product all is great as you leverage the knowledge and time in writing the thing yourself, assuming you could even do that in the first place. However in writing several in house applications using Delphi most of the time things did not work as advertised and I spend many hours becoming a close email buddy with the component vendor getting it to work at all and several times when you single step into the trouble area you realize no one at the component vendor must have ever tested this as it never could have worked.
You leverage their problems as well as the good . With that said my two cents is it is still better to have an application written using tools native to each platform rather than the write once runs everywhere method. I have never seen that work very well, usually ends up write once to some called standard which is not and runs poorly everywhere is the result.
I am not real knowledgeable on open source but to me would a company want to bet the company on something written using software everyone has there hands in. Could you imagine Toyota saying Senator we do not know who made those mods to the Open Source Lib we used for the accellerator code.
A custom application makes more sense for selling your products to companys because you have control of it and they will trust it . Course another way to put it I guess is an in house app supplied by a vendor and written by someone who has no idea what he is doing is better because at least they know who to blame. LOL.
Tom
-Phil
I have Brad's Spin Tool with PropBasic and like it has well. By having both compilers it aloud me to do write the same app a different way.
I addition to my other ongoing tasks, I have decided to create a new Spin editor, and I started on it this morning. I will probably work on it just a little everyday, so I am unsure of when it will be complete. As it stands, I will be almost in the same boat as Parallax with their Edit control, because I will be using an open source edit control that has some stipulations about posting the code to websites other than codeguru.com. So at this point, I am uncertain just how open my source code will be. However, I will attempt to contact the author of the Edit control and try to obtain his permission to post it here at Parallax along with my code.
I will keep you updated.
Bruce
I notice you said Visual C++. While I laud your initiative, I hope this does not imply that your editor will depend upon an installation of Microsoft's .NET framework on the user's computer.
-Phil
Nah... I would not do that. It will be just be an exe file, but perhaps it might require Propellent.dll or the Propeller Tool to be installed on the target computer. I have to explore and review the Propellent documentation to see whether I can statically link to Propellent, or if Parallax requires it to remain seperate from the executable. If I can statically link than it should just be the installation of an exe.
Bruce
These are some great suggestions. I'm currently writing and IDE for Catalina and I'd like to add these as well. Plus there are some others that I have working that could be useful too.
PhiPi said
I'm writing using functions for a richtextbox, which is code common to C/VB/Java and is in the .net framework. But .net is bloatware, and even starting up the .net editor takes several minutes. So any suggestions for other platforms would be most useful.
One thing that the .net framework has are a whole lot of things in the IDE that make code writing so much easier. So to add to the list above:
* Collapse/Expand groups of text (ie you can shrink down functions once you know they work)
* Syntax color highlighting, comments in green, keywords in blue, quotes in red etc. Plus or minus backcolor too.
* Antocompletion of not just the program keywords, but also variable names that have been used in the program.
* Automatching of capitalisations, eg declare a variable MyVariable, then later on type myvariable and it changes to MyVariable
* Dropdown menus for anything that comes after a . (period) (I think this is the same as #6 above)
* Something that replicates the little arrows in the proptool that group things together (BST does not have this).
* Wavy lines under code with incorrect syntax
* Code help when the mouse is placed over keywords
* Turn on/off hidden characters (like in Word), so you can see spaces, tabs, linefeeds and carriage returns.
Can a richtextbox do all these things? I'm not sure but there are some clues after spending a little time searching Google. Can other code platforms do this too?
You may already know this but I will post just in case not.
I have been tinkering a bit with propellent.dll using Delphi and posted about it
on Chris Savage's site
http://www.savagecircuits.com/forums/showthread.php?338-Using-Propellent.dll-in-your-PC-User-Interface-for-your-Prop-Application
Shows the unit to interface with propellent.dll and some code calling it.
dll's do not link into your exe file, you use the dll and include it with your exe file.
I did not try the compile function in the dll but will give it a go. Something simple like a memo control and load a file and compile it.
I have a Delphi app that uses the dll to find a prop and download the code to it, that experiment worked.
Tom
A rich edit contol can accomplish everything that a standard edit can do and more. I notice that you added some things that should be added to the list. There are some very good ideas there, and I will add them soon. I am a bit of an old timer (not too old) but I learned and have stuck with Visual Studio C++ 6.0. It is a little antiquated, but I am certain that it is highly capable of creating an outstanding editor. But it would appear that the edit control and any supporting objects, would be the key to a nice editor. I have some nice source code which is a good start, but now I question if I should use it or create one from scratch. The source code I have, the guy used a common edit control and view and did paints. And now that you mention it, I am beginning to think that a rich edit control is better suited for the job. I will have to take a peek into rich edit and get back with you.
Thanks For Your Post
Bruce
8. Error (preferred) or warning if the case (upper/lower) of a symbol-in-use disagrees with its case where it's defined. Spin might be case-independent, but it should at least be case-consistent.
-Phil
How about auto-case correction, instead of an error or warning, that way you can just type without worrying about capitalization, and when it matches a symbol it auto corrects to be case consistent. Good suggestion.
Bruce
-Phil
In order to help all of us understand where these requests lie in the scope of all Propeller Tool improvements, I will review our internal list and see that the requests from this thread are incorporated into our list (either as accepted, under consideration, etc.). When I'm done I'll post the whole document on this thread. At least then it will be clear that the various requests are being tracked by Parallax and that your efforts amount to more than a forum post. I won't get involved in discussions about priorities since all of us have different viewpoints on what is most important. Last time I reviewed our list of Propeller Tool improvements it showed priority, so at least you'll be able to have some idea about what we're focusing on.
I need a week, however.
Ken Gracey
Parallax Inc.
I can relate to that.
Okay, you have your error, but the error will be an undefined if the case does not match. However, auto correction will probably be a user choice option as part of the software.
Bruce
Thank you for your post. You caught me talking out my rear. You are correct, it is a dll not a lib. Perhaps since Ken is being so nice to us, maybe he can get us a propellent lib file
Bruce
My project will definitely be a MFC application, and I am going to run with CRichEditView and CRichEditCtrl, and create it from bare bones source. However, I can clearly see that I will have to brush up on the C++ since it has been a while. It is a good thing for me that I kept an enormous amount of documentation, examples, and samples.
Bruce
Yeah! I think that's a fine feature, so long as it's a option. Sometimes those features get in the way, other times they rock. Could make a lot of sense. If this does get done, there is "best guess" and there is "multiple guess" options that could be done. If "multiple guess" is in the feature, please allow keyboard arrow keys and enter to select from the likely choices. In the past, I've seen that feature on applications and really liked it that way. When it's mouse only, the user has to change input contexts to complete something, and that gets tiresome quickly. If it's single guess, just pressing enter to advance past that input mode on successful guess is good. Multiple guess might make sense here for those people trying to remember instructions.
Bruce