Whilst debugging a crash that was happening every time the project called "QuaZip zip(dstPath);", while debugging in Qt Creator, I found some info on having qmake build an XCode project from a Qt project file! Since I'm familiar with XCode, I was able to figure out that PropellerIDE was calling an older qua zip lib buried in /opt/local/qt5/. Resetting $PATHS to include current qt bin & lib directories got this working.
But there are advantages to having the ability to use the compiler as a library as well. It can then provide functions to the IDE that provide a lot more information about the source code.
True... but there are also advantages to being easily able to swap out backends. For example, it might be nice to be able to compile the Spin code to LMM with spin2cpp, or to use bstc's optimizer.
Can we use the DLL for syntax highlighting and such, but still have the option to call an external program for the actual compilation?
What to do WITH the terminal aspect of Propeller IDE? I know that in SimpleIDE you would use print()/printf() to display in the terminal, but Propeller IDE is different. I remember that JonnyMac had at one time a debug object which used the TV as a terminal, should an idea like that be implemented in Propeller IDE? Should this IDE have a built in debug command, when used it would automatically bring up the terminal and display the contents of the debug command.
The only other way to use the terminal is too implement the FDS object, but isn't that a little overkill for use as a debug tool? Is there a simpler object or way too accomplish this? I know there are quite a few people that want the terminal program to be a stand alone, but even then how would you use that for the best use with the IDE? Just curious as to how people plan too use the terminal feature of Propeller IDE?
Using a terminal as a debug tool is quite common with Spin programmers. The Propeller Tool comes with a serial terminal (Parallax Serial Terminal) and the standard libraries that ship with it (and presumably will be bundled with PropellerIDE) contain the Parallax Serial Terminal object which is used quite often for basic debugging and interfacing to a user. I believe there are also debug oriented variations of the PST object. Don't fear, it will get used and if it also shows up as a standalone Terminal/Loader, it will be used even more!
I remember that JonnyMac had at one time a debug object which used the TV as a terminal, should an idea like that be implemented in Propeller IDE?
No, I didn't. I have always used a terminal window for debugging. Others have used TV and VGA output, but not me -- those objects consume too many resources.
Sorry JonnyMac, maybe I was remembering the Debug to LCD, and it became TV in my mind. So, the question still remains if a form of debug should be part of the IDE or do we just still rely on FDS.spin as the preferred method for using the terminal for debug?
So, the question still remains if a form of debug should be part of the IDE or do we just still rely on FDS.spin as the preferred method for using the terminal for debug?
As the Propeller doesn't have any special debugging hooks built in, serial debugging seems the most logical/practical solution. Even those specialty programs that spy on the Propeller are communicating to the application through a serial link.
Since Terminal was mentioned, It should be noted that the SimpleIDE terminal has been added to the project. The terminal is supposed to support the PST movement commands. One issue left is that the baud-rate is not persistent yet.
Regarding the PST movement features, I've been searching for spin code used to test them but can't find anything at the moment. The test code for SimpleIDE is written in C. If anyone has some PST movement command test code, please post it here.
There was also an issue on Mac with propeller load failing after adding the blinky COG status window. Please test loading on all platforms and let me know if there is any issue.
One thing that the IDE is having trouble with at the moment is parsing a huge file for the method browser. This is most annoying at startup, and is a good reason for me to go ahead and look at adding a tree drop down from the file name. That means that the IDE will startup without the list of functions, and the user will get to click the file name to see the methods. There are other options in this idea to consider, but I'll save that for another time.
Since Terminal was mentioned, It should be noted that the SimpleIDE terminal has been added to the project. The terminal is supposed to support the PST movement commands. One issue left is that the baud-rate is not persistent yet.
Regarding the PST movement features, I've been searching for spin code used to test them but can't find anything at the moment. The test code for SimpleIDE is written in C. If anyone has some PST movement command test code, please post it here.
There was also an issue on Mac with propeller load failing after adding the blinky COG status window. Please test loading on all platforms and let me know if there is any issue.
One thing that the IDE is having trouble with at the moment is parsing a huge file for the method browser. This is most annoying at startup, and is a good reason for me to go ahead and look at adding a tree drop down from the file name. That means that the IDE will startup without the list of functions, and the user will get to click the file name to see the methods. There are other options in this idea to consider, but I'll save that for another time.
Coolio! I can rebuild and test on my Mac this afternoon.
Windows 7 box.
Below is a quick and dirty, just too see what if anything is working. Positioning (X value) of the char "A" is not working, and that was the same problem back some time ago when I tried it with SimpleIDE. The term.Tx(13) is not acting like a real carriage return, but a new line. Later on I will try some more things, but I did notice that a pause is no longer needed for the terminal catch up.
Ray
'' terminal.spin
CON
_clkmode = xtal1 + pll16x
_xinfreq = 5_000_000
rxPin = 31
txPin = 30
mode = 0
baudrate = 115200
OBJ
misc : "tools" ''This contains waitms which not needed.
term : "FullDuplexSerial"
PUB Start
term.Start(rxPin, txPin, mode, baudrate)
main
'' Main
PUB main
term.Tx(13)
term.str(string("This is a line."))
term.Tx(13)
term.Tx(14) ''cursor X
term.Tx(10)
term.Tx(15) ''cursor Y
term.Tx(10)
term.Tx("A")
Windows 7 box.
Below is a quick and dirty, just too see what if anything is working. Positioning (X value) of the char "A" is not working, and that was the same problem back some time ago when I tried it with SimpleIDE.
The term.Tx(13) is not acting like a real carriage return, but a new line. Later on I will try some more things, but I did notice that a pause is no longer needed for the terminal catch up.
Unfortunately, this is a problem caused by interpreting what 10 and 13 means. Windows and Linux (or Unix) interpret these things differently. Hardcoding them is a mistake for multi-os use, but windows only use, it's perfectly fine We can't complain much about this mistake as Spin fans any more than Apple fans can complain about that silly, though historical, global application menu bar on the Mac.
As it is, "Spinny" is "Windowy" and we just just have to live with it.
So, there is a couple of more problems. To make the individual cursor moves you have to lead with Y, then X. So, that makes (2)-Position cursor X,Y completely useless. When you want too move to position 0, it does not work, because when you use Tx(0), it clears the screen.
I briefly tested the cursor up and down, that seems to work, also (11)-Clear to end of line, seems to work. The other problem I ran into is maybe something to do with Qt Create, it seems like there is a program size limit. The test program that I did had maybe 40 lines of code, and it did not run all of the code lines.
So, there is a couple of more problems. To make the individual cursor moves you have to lead with Y, then X. So, that makes (2)-Position cursor X,Y completely useless. When you want too move to position 0, it does not work, because when you use Tx(0), it clears the screen.
I briefly tested the cursor up and down, that seems to work, also (11)-Clear to end of line, seems to work. The other problem I ran into is maybe something to do with Qt Create, it seems like there is a program size limit. The test program that I did had maybe 40 lines of code, and it did not run all of the code lines.
Ray
Ray, please provide an updated file demonstrating issues as you find them. It's much easier to fix things when they can be reproduced. The second paragraph has an interesting statement that I have no idea how to reproduce unless you provide code.
Now this q&d snippet, sometimes it runs completely and sometimes it doesn't, if you keep hitting the run in terminal consistently. There is also a problem with cursor right cursor left. What I was expecting is the cursor too move around the letter "A". Hope this helps.
Ray
'' terminal.spin
CON
_clkmode = xtal1 + pll16x
_xinfreq = 5_000_000
rxPin = 31
txPin = 30
mode = 0
baudrate = 115200
OBJ
misc : "tools"
term : "FullDuplexSerial"
PUB Start
term.Start(rxPin, txPin, mode, baudrate)
main
'' Main
PUB main
term.Tx(13)
term.str(string("This is a line."))
term.Tx(10)
term.Tx(15) ''Y
term.Tx(1)
term.Tx(14) ''X
term.Tx(7)
term.Tx(11) ''Clear to end of line
term.Tx(15) ''Y
term.Tx(9)
term.Tx(14) ''X
term.Tx(5)
term.Tx("A")
'' term.Tx(15) ''Y
'' term.Tx(9)
'' term.Tx()
'' misc.waitms(1000)
term.Tx(5) ''cursor up
misc.waitms(1000)
term.Tx(6) ''cursor down
term.Tx(6) ''cursor down
misc.waitms(1000)
term.Tx(5) ''cursor up
misc.waitms(1000)
term.Tx(3) ''cursor left
misc.waitms(1000)
term.Tx(4) ''cursor right
term.Tx(4) ''cursor right
misc.waitms(1000)
It fails to do the Position(x,y) and Char(console#PC) correctly at several points in the code. (Failure is noted in the Terminal during testing and within the spin source code)
The "project" (I know, the P-word is not normally to be used in PropellerIDE, but it helps to explain my test "suite") includes 2 .spin files but also uses the Parallax Serial Terminal object. I set the Preferences Libraries directory to where I have placed PST and leave the testPropIDEPause.spin file in the same directory as the main .spin (testPropIDE.spin) file. This is to test the use of objects that are local as well as in a specified directory of libs.
BTW: When testing is complete, the Activity Board pins 26 & 27 LEDs will flash...
Two other issues about the terminal implementation:
The Terminal window starts out kinda small. Could the default be A) larger and saved if the user changes the window size?
The "Propeller Programming OK" dialog sometimes appears in front of the terminal window and remains there for several seconds after text is starting to display
I'm currently working on bringing Find & Replace into PropellerIDE. Taking the current Find & Replace from SimpleIDE, I'm thinking about using a drop-down dialog at the top of the editor box in place of the SimpleIDE Find & Replace dialog box.
My thoughts:
The dialog gets in the way of the editor and always needs to be moved out of the way by the user. New method should not hinder editing view while search/replace is under way.
The dialog only allows clicking on arrows buttons to search forward or backward. Allow Cntl/Cmd keys (Cntl-G Cntl-SHIFT-G AND Cmd-G & Cmd-SHIFT-G for Mac OS X) for searching forward and backward.
Heres a few mockups of a roll-down/pop-up panel for Find & Replace:
Layout and Usage
Find alone:
Find & Replace:
Let me know what you think about these solutions. Probably, just the Find & Replace could b used as a unit (no need for just the Find panel).
Debian 64-bit box.
The latest clone has a complie error, can not find "Terminal2.h". In Terminal2.cpp I changed #include "Terminal2.h" too #include "terminal2.h" , and that sort of allowed it too compile. Not sure what other problems that might of created.
The terminal.spin example that I showed, in the previous post, seems too work the same way as it does in the Windows 7 box, only the last twelve lines of code are being implemented. This problem seems to be more consistent now. The Propeller Programming OK window seems too hover way too long in the Debian box also.
I tried the properties window for a compiler type, the Files of type: shows Spin Compiler (openspin.* openspin), but the listing of the files is still blank.
Debian 64-bit box.
The latest clone has a complie error, can not find "Terminal2.h". In Terminal2.cpp I changed #include "Terminal2.h" too #include "terminal2.h" , and that sort of allowed it too compile. Not sure what other problems that might of created.
Sorry about that. Your fix was correct. I've pushed a change to the repository.
I tried the properties window for a compiler type, the Files of type: shows Spin Compiler (openspin.* openspin), but the listing of the files is still blank.
Hmm, I had no problems with this. Regardless, I made a small change that lets you choose openspin*
Now this q&d snippet, sometimes it runs completely and sometimes it doesn't, if you keep hitting the run in terminal consistently. There is also a problem with cursor right cursor left. What I was expecting is the cursor too move around the letter "A". Hope this helps.
Ray, your positioning code is wrong. You have to send the command first and then the argument. I.E.
term.Tx(15) ' Y position command
term.Tx(10) ' line number
It's actually better to use PST "Parallax Serial Terminal" for these kinds of things because it encapsulates the sequences correctly.
Fix your program and re-test. If you have further problems, let me know.
It fails to do the Position(x,y) and Char(console#PC) correctly at several points in the code. (Failure is noted in the Terminal during testing and within the spin source code)
Thanks Dennis. It's a good test suite program. I like the spelling correction bit
Two other issues about the terminal implementation:
The Terminal window starts out kinda small. Could the default be A) larger and saved if the user changes the window size?
The "Propeller Programming OK" dialog sometimes appears in front of the terminal window and remains there for several seconds after text is starting to display
dgately
The terminal window now starts a bit bigger. Please remove the .plist and restart after pull/update, build to see the results.
The "Propeller Programming OK" dialog "on time" has been reduced.
I'm currently working on bringing Find & Replace into PropellerIDE. Taking the current Find & Replace from SimpleIDE, I'm thinking about using a drop-down dialog at the top of the editor box in place of the SimpleIDE Find & Replace dialog box.
I like these ideas a lot. Find is one command, Replace is another command, ... then one could have the more adventurous Refactor feature as a separate command
If we don't hear any objections from the Spinny Forumista Faithful crowd soon, I'd say you have Carte Blanche.
Here's another test of cursor movement in the terminal... (Part of an overall PropellerIDE test suite)
...
It fails to do the Position(x,y) and Char(console#PC) correctly at several points in the code. (Failure is noted in the Terminal during testing and within the spin source code)
Dennis, while you certainly found a bug ... I agree that position(x,y) and Char(console#PC) were misbehaving, the expected output of U,X,D is a little off.
Snippet showing your expectation:
'' test cursor to x,y then move up, down
'' should print something like:
''
'' U
'' X
'' D
''
'' at col 15
console.Char(console#PC)
console.Char(15)
console.Char(4)
console.Str(string("X")) '' FAILS TO GO TO THE X POSITION!!!
pauseLib.Pause(200)
console.Char(console#MU) '' move the cursor up & print 'U'
console.Str(string("U"))
pauseLib.Pause(200)
console.Char(console#MD) '' move the cursor down 2 & print 'D'
console.Char(console#MD)
The problem is that move up and move down both should move from the last cursor column.
That is, the result of your code should be this. The Parallax Serial Terminal also behaves this way.
Yes, my intention was to move the cursor up 1, then back one, type a "U" then down 2, then back one, type "D" to align the text vertically, but when I realized that Position(x,y) was broken, I left out the aligning backward moves to spare some confusion until a fix was in-hand :thumb:
Yes, my intention was to move the cursor up 1, then back one, type a "U" then down 2, then back one, type "D" to align the text vertically, but when I realized that Position(x,y) was broken, I left out the aligning backward moves to spare some confusion until a fix was in-hand :thumb:
I'll add back the other moves to the test code...
Thanks
dgately
Ok thanks for explaining.
Yes, fix should be in hand now. I've also updated the windows console which only needed that silly LFCR/CRLF swap. As it turns out, I had a bad PST.spin on my computer causing me all kinds of grief.
Guess what?
I don't have anything to do now except eat dog-food
Send me diffs you have for the zip thing? I'd bet find/replace is more rewarding right now.
Actually there is the error line highlighting thing, but I don't want to interfere with Roy.
Send me diffs you have for the zip thing? I'd bet find/replace is more rewarding right now.
A little more testing today, then I'll send the zip diffs to you. It's working, but I also want to add-in the new progress dialog as it processes the zip.
I've got "phase 1" of background highlighting functioning locally. I just need to do a bit of cleanup before I commit it (maybe tonight?).
I call it phase 1 because right now the colors are hard coded, and there are some minor issues, like the last line doesn't highlight the whole line if there isn't a newline on it. There's probably even more issues I haven't run into yet.
I'll need to add the colors to the settings dialog someplace.
JonnyMac,
Yeah, that's one of the things I really like about PropTool, and a big part of why I signed up to do it for PropellerIDE. One difference between what I have now and what PropTool does, is that I'm not changing anything about the text colors themselves. I'm only changing the background color. In PropTool, the text colors for things like comments adjust to a shade of the background color they are on. Eventually, I'll try to get that working as well, but likely only for comments and not anything else.
Comments
Here's XCode building and debugging PropellerIDE!
Whilst debugging a crash that was happening every time the project called "QuaZip zip(dstPath);", while debugging in Qt Creator, I found some info on having qmake build an XCode project from a Qt project file! Since I'm familiar with XCode, I was able to figure out that PropellerIDE was calling an older qua zip lib buried in /opt/local/qt5/. Resetting $PATHS to include current qt bin & lib directories got this working.
Notes on Qt & XCode:
https://qt-project.org/doc/qt-5.0/qtdoc/qmake-platform-notes.html
Look for: "Creating and Moving Xcode Projects" and specifically:
As you were...
dgately
Can we use the DLL for syntax highlighting and such, but still have the option to call an external program for the actual compilation?
Eric
The only other way to use the terminal is too implement the FDS object, but isn't that a little overkill for use as a debug tool? Is there a simpler object or way too accomplish this? I know there are quite a few people that want the terminal program to be a stand alone, but even then how would you use that for the best use with the IDE? Just curious as to how people plan too use the terminal feature of Propeller IDE?
Ray
Using a terminal as a debug tool is quite common with Spin programmers. The Propeller Tool comes with a serial terminal (Parallax Serial Terminal) and the standard libraries that ship with it (and presumably will be bundled with PropellerIDE) contain the Parallax Serial Terminal object which is used quite often for basic debugging and interfacing to a user. I believe there are also debug oriented variations of the PST object. Don't fear, it will get used and if it also shows up as a standalone Terminal/Loader, it will be used even more!
No, I didn't. I have always used a terminal window for debugging. Others have used TV and VGA output, but not me -- those objects consume too many resources.
Ray
As the Propeller doesn't have any special debugging hooks built in, serial debugging seems the most logical/practical solution. Even those specialty programs that spy on the Propeller are communicating to the application through a serial link.
Regarding the PST movement features, I've been searching for spin code used to test them but can't find anything at the moment. The test code for SimpleIDE is written in C. If anyone has some PST movement command test code, please post it here.
There was also an issue on Mac with propeller load failing after adding the blinky COG status window. Please test loading on all platforms and let me know if there is any issue.
One thing that the IDE is having trouble with at the moment is parsing a huge file for the method browser. This is most annoying at startup, and is a good reason for me to go ahead and look at adding a tree drop down from the file name. That means that the IDE will startup without the list of functions, and the user will get to click the file name to see the methods. There are other options in this idea to consider, but I'll save that for another time.
Coolio! I can rebuild and test on my Mac this afternoon.
Thanks!
Below is a quick and dirty, just too see what if anything is working. Positioning (X value) of the char "A" is not working, and that was the same problem back some time ago when I tried it with SimpleIDE. The term.Tx(13) is not acting like a real carriage return, but a new line. Later on I will try some more things, but I did notice that a pause is no longer needed for the terminal catch up.
Ray
'' terminal.spin CON _clkmode = xtal1 + pll16x _xinfreq = 5_000_000 rxPin = 31 txPin = 30 mode = 0 baudrate = 115200 OBJ misc : "tools" ''This contains waitms which not needed. term : "FullDuplexSerial" PUB Start term.Start(rxPin, txPin, mode, baudrate) main '' Main PUB main term.Tx(13) term.str(string("This is a line.")) term.Tx(13) term.Tx(14) ''cursor X term.Tx(10) term.Tx(15) ''cursor Y term.Tx(10) term.Tx("A")Hmm. Wish I had known about that before today!
Unfortunately, this is a problem caused by interpreting what 10 and 13 means. Windows and Linux (or Unix) interpret these things differently. Hardcoding them is a mistake for multi-os use, but windows only use, it's perfectly fine
As it is, "Spinny" is "Windowy" and we just just have to live with it.
I briefly tested the cursor up and down, that seems to work, also (11)-Clear to end of line, seems to work. The other problem I ran into is maybe something to do with Qt Create, it seems like there is a program size limit. The test program that I did had maybe 40 lines of code, and it did not run all of the code lines.
Ray
Ray, please provide an updated file demonstrating issues as you find them. It's much easier to fix things when they can be reproduced. The second paragraph has an interesting statement that I have no idea how to reproduce unless you provide code.
Ray
'' terminal.spin CON _clkmode = xtal1 + pll16x _xinfreq = 5_000_000 rxPin = 31 txPin = 30 mode = 0 baudrate = 115200 OBJ misc : "tools" term : "FullDuplexSerial" PUB Start term.Start(rxPin, txPin, mode, baudrate) main '' Main PUB main term.Tx(13) term.str(string("This is a line.")) term.Tx(10) term.Tx(15) ''Y term.Tx(1) term.Tx(14) ''X term.Tx(7) term.Tx(11) ''Clear to end of line term.Tx(15) ''Y term.Tx(9) term.Tx(14) ''X term.Tx(5) term.Tx("A") '' term.Tx(15) ''Y '' term.Tx(9) '' term.Tx() '' misc.waitms(1000) term.Tx(5) ''cursor up misc.waitms(1000) term.Tx(6) ''cursor down term.Tx(6) ''cursor down misc.waitms(1000) term.Tx(5) ''cursor up misc.waitms(1000) term.Tx(3) ''cursor left misc.waitms(1000) term.Tx(4) ''cursor right term.Tx(4) ''cursor right misc.waitms(1000)tools.spintestPropIDE.spin
testPropIDEPause.spin
It fails to do the Position(x,y) and Char(console#PC) correctly at several points in the code. (Failure is noted in the Terminal during testing and within the spin source code)
The "project" (I know, the P-word is not normally to be used in PropellerIDE, but it helps to explain my test "suite") includes 2 .spin files but also uses the Parallax Serial Terminal object. I set the Preferences Libraries directory to where I have placed PST and leave the testPropIDEPause.spin file in the same directory as the main .spin (testPropIDE.spin) file. This is to test the use of objects that are local as well as in a specified directory of libs.
BTW: When testing is complete, the Activity Board pins 26 & 27 LEDs will flash...
Two other issues about the terminal implementation:
- The Terminal window starts out kinda small. Could the default be A) larger and
saved if the user changes the window size?
- The "Propeller Programming OK" dialog sometimes appears in front of the terminal window and remains there for several seconds after text is starting to display
dgatelyMy thoughts:
- The dialog gets in the way of the editor and always needs to be moved out of the way by the user. New method should not hinder editing view while search/replace is under way.
- The dialog only allows clicking on arrows buttons to search forward or backward. Allow Cntl/Cmd keys (Cntl-G Cntl-SHIFT-G AND Cmd-G & Cmd-SHIFT-G for Mac OS X) for searching forward and backward.
Heres a few mockups of a roll-down/pop-up panel for Find & Replace:Layout and Usage
Find alone:
Find & Replace:
Let me know what you think about these solutions. Probably, just the Find & Replace could b used as a unit (no need for just the Find panel).
Thanks,
dgately
Turns out that it is an issue with the parallax2.ttf font. The old parallax.ttf font and the new parallax2-bold.ttf font don't have the problem.
I did get a chance to improve the performance of loading complicated Spin files. That is worth a new pull/upgrade and build.
I'll look at these other posts in the morning.
The latest clone has a complie error, can not find "Terminal2.h". In Terminal2.cpp I changed #include "Terminal2.h" too #include "terminal2.h" , and that sort of allowed it too compile. Not sure what other problems that might of created.
The terminal.spin example that I showed, in the previous post, seems too work the same way as it does in the Windows 7 box, only the last twelve lines of code are being implemented. This problem seems to be more consistent now. The Propeller Programming OK window seems too hover way too long in the Debian box also.
I tried the properties window for a compiler type, the Files of type: shows Spin Compiler (openspin.* openspin), but the listing of the files is still blank.
Ray
Sorry about that. Your fix was correct. I've pushed a change to the repository.
Hmm, I had no problems with this. Regardless, I made a small change that lets you choose openspin*
Ray, your positioning code is wrong. You have to send the command first and then the argument. I.E.
Fix your program and re-test. If you have further problems, let me know.
Thanks Dennis. It's a good test suite program. I like the spelling correction bit
The terminal window now starts a bit bigger. Please remove the .plist and restart after pull/update, build to see the results.
The "Propeller Programming OK" dialog "on time" has been reduced.
I like these ideas a lot. Find is one command, Replace is another command, ... then one could have the more adventurous Refactor feature as a separate command
If we don't hear any objections from the Spinny Forumista Faithful crowd soon, I'd say you have Carte Blanche.
Carte Blanche? Oh boy, look out!
Thanks!
Dennis, while you certainly found a bug ... I agree that position(x,y) and Char(console#PC) were misbehaving, the expected output of U,X,D is a little off.
Snippet showing your expectation:
'' test cursor to x,y then move up, down '' should print something like: '' '' U '' X '' D '' '' at col 15 console.Char(console#PC) console.Char(15) console.Char(4) console.Str(string("X")) '' FAILS TO GO TO THE X POSITION!!! pauseLib.Pause(200) console.Char(console#MU) '' move the cursor up & print 'U' console.Str(string("U")) pauseLib.Pause(200) console.Char(console#MD) '' move the cursor down 2 & print 'D' console.Char(console#MD)That is, the result of your code should be this. The Parallax Serial Terminal also behaves this way.
Yes, my intention was to move the cursor up 1, then back one, type a "U" then down 2, then back one, type "D" to align the text vertically, but when I realized that Position(x,y) was broken, I left out the aligning backward moves to spare some confusion until a fix was in-hand :thumb:
I'll add back the other moves to the test code...
Thanks
dgately
Ok
Yes, fix should be in hand now. I've also updated the windows console which only needed that silly LFCR/CRLF swap. As it turns out, I had a bad PST.spin on my computer causing me all kinds of grief.
Guess what?
I don't have anything to do now except eat dog-food
Send me diffs you have for the zip thing? I'd bet find/replace is more rewarding right now.
Actually there is the error line highlighting thing, but I don't want to interfere with Roy.
A little more testing today, then I'll send the zip diffs to you. It's working, but I also want to add-in the new progress dialog as it processes the zip.
dgately
I call it phase 1 because right now the colors are hard coded, and there are some minor issues, like the last line doesn't highlight the whole line if there isn't a newline on it. There's probably even more issues I haven't run into yet.
I'll need to add the colors to the settings dialog someplace.
Yeah, that's one of the things I really like about PropTool, and a big part of why I signed up to do it for PropellerIDE. One difference between what I have now and what PropTool does, is that I'm not changing anything about the text colors themselves. I'm only changing the background color. In PropTool, the text colors for things like comments adjust to a shade of the background color they are on. Eventually, I'll try to get that working as well, but likely only for comments and not anything else.