PropTool Bug Report
hippy
Posts: 1,981
Is this the place to report PropTool bugs, or is there somewhere else / someone who should be notified directly ?
Version 1.05.5 - Win XP SP2
Minor / Cosmetic
Project Explorer, top display ( Object / File Tree ). When using a white-on-black Windows system color scheme, the text defaults to black ( giving black-on-black ) and is therefore 'invisible'.
In all other tree views and elsewhere, the chosen color scheme is handled okay. It's unfortunate that this is the most important part of the Project Explorer.
I have a visual impairment which is why I run with the white-on-black scheme. The PropTool handles the unusual scheme far better than other applications I could mention - well done, Parallax.
Version 1.05.5 - Win XP SP2
Minor / Cosmetic
Project Explorer, top display ( Object / File Tree ). When using a white-on-black Windows system color scheme, the text defaults to black ( giving black-on-black ) and is therefore 'invisible'.
In all other tree views and elsewhere, the chosen color scheme is handled okay. It's unfortunate that this is the most important part of the Project Explorer.
I have a visual impairment which is why I run with the white-on-black scheme. The PropTool handles the unusual scheme far better than other applications I could mention - well done, Parallax.
Comments
I think its been mentioned before but I'm going to mention it again in the hopes that it gets some attention.
The basic problem is the auto port scanning "feature" that occurs every time the tool tries to communicate with the propeller. I think the original assumption was that any port that windows enumerates is safe to try to open. But this is NOT the case because there are many "Virtual Com Port" drivers that do not respond friendly when they are opened but not valid. Right now on my system I have 3 actual Com Ports and 20+ virtual ones. Bluetooth drivers, TCP/IP redirect drivers and various debugging drivers all create ports that are enumerated along with the actual physical ports.
As far as I can tell there is no windows API call that can differentiate between these virtual ports and the real ones. Nor does there need to be. Its actually a bit odd to try to just open every port and see if something is out there. Don't get me wrong most of the time I like the feature and its useful not to have to worry about what port it is on. But it leads to a system lockup (sometimes requiring a hard power reset!) that while not directly the PropTool's fault (I can make it happen with other programs if I try too) it is definitely avoidable.
My suggestion is to allow us to disable the auto scan and select a single port to be used to connect to the propeller.
As it is I can't even use the Propeller Tool without first disabling ports that I don't want it to enumerate. This has worked for me for a while so I didn't say anything because I know you're all really busy. But now I'm working on a project that requires both the propeller and one of my virtual ports at the same time! I have no way around it and I'm dead in the water until this is fixed.
I don't care how this is accomplished for now. Menu options, config file, registry settings, whatever is easiest (and fastest), but it is really really needed.
Also while I'm begging, I'd really like for the compiled binary image to be dumped to the hard drive every time it is generated (F8, F10,F11) Again I don't need anything fancy, it can overwrite the same file over and over again. Use the top object filename with the .binary extension or some generic filename. There have been many many times I wanted this feature.
Thanks,
Chad
It is a bit odd to just go searching for a serial port.
Just my 10 bits worth.
Doug