Myopia, or why I can't C#
-
Another small rant, two-for-one. 1) Debugging console applications with parameters is painful. I need to test against all the possible combinations of arguments, can't do it properly though, need to pass through the debug options... which are persistent. And the console does not stay open (yes the checkbox is unchecked, also ignored by VS). And the breakpoint after the parsing moves the focus to the VS window hiding the Command prompt. Every test is a clickity-clickity-typety-clickity-clickity-clickity-clickity-clak. :elephant: you Microsoft. 2) Structures in watch window do not stay expanded. Add other clickity-clickity-claks to a simple test. Basically the best way to test this behavior is inserting test code and debug prints, as we used to do when we had to chisel bits one by one onto EEPROMS with tiny hammers and a lot of patience. Told you it was a rant.
GCS/GE d--(d) s-/+ a C+++ U+++ P-- L+@ E-- W+++ N+ o+ K- w+++ O? M-- V? PS+ PE Y+ PGP t+ 5? X R+++ tv-- b+(+++) DI+++ D++ G e++ h--- r+++ y+++* Weapons extension: ma- k++ F+2 X The shortest horror story: On Error Resume Next
Rename Main(...) to Main2(...) Insert a Main() routine and make it call Main2 with your test cases.
Check out my IoT graphics library here: https://honeythecodewitch.com/gfx And my IoT UI/User Experience library here: https://honeythecodewitch.com/uix
-
Another small rant, two-for-one. 1) Debugging console applications with parameters is painful. I need to test against all the possible combinations of arguments, can't do it properly though, need to pass through the debug options... which are persistent. And the console does not stay open (yes the checkbox is unchecked, also ignored by VS). And the breakpoint after the parsing moves the focus to the VS window hiding the Command prompt. Every test is a clickity-clickity-typety-clickity-clickity-clickity-clickity-clak. :elephant: you Microsoft. 2) Structures in watch window do not stay expanded. Add other clickity-clickity-claks to a simple test. Basically the best way to test this behavior is inserting test code and debug prints, as we used to do when we had to chisel bits one by one onto EEPROMS with tiny hammers and a lot of patience. Told you it was a rant.
GCS/GE d--(d) s-/+ a C+++ U+++ P-- L+@ E-- W+++ N+ o+ K- w+++ O? M-- V? PS+ PE Y+ PGP t+ 5? X R+++ tv-- b+(+++) DI+++ D++ G e++ h--- r+++ y+++* Weapons extension: ma- k++ F+2 X The shortest horror story: On Error Resume Next
Time to move to WinDbg.
-
Another small rant, two-for-one. 1) Debugging console applications with parameters is painful. I need to test against all the possible combinations of arguments, can't do it properly though, need to pass through the debug options... which are persistent. And the console does not stay open (yes the checkbox is unchecked, also ignored by VS). And the breakpoint after the parsing moves the focus to the VS window hiding the Command prompt. Every test is a clickity-clickity-typety-clickity-clickity-clickity-clickity-clak. :elephant: you Microsoft. 2) Structures in watch window do not stay expanded. Add other clickity-clickity-claks to a simple test. Basically the best way to test this behavior is inserting test code and debug prints, as we used to do when we had to chisel bits one by one onto EEPROMS with tiny hammers and a lot of patience. Told you it was a rant.
GCS/GE d--(d) s-/+ a C+++ U+++ P-- L+@ E-- W+++ N+ o+ K- w+++ O? M-- V? PS+ PE Y+ PGP t+ 5? X R+++ tv-- b+(+++) DI+++ D++ G e++ h--- r+++ y+++* Weapons extension: ma- k++ F+2 X The shortest horror story: On Error Resume Next
den2k88 wrote:
And the breakpoint after the parsing moves the focus to the VS window hiding the Command prompt.
Well at least that one's easy to fix, get another monitor and reshuffle your windows around so they don't overlap. It's really nice to have an unobscured view of the IDE open on one monitor, then a browser / console / Explorer windows on another, alongside a bunch of debug windows (locals / watch windows / output window / etc). I typically RDP into my dev VM using a 4K monitor and a 1080p one, and that's my sweet spot. Although *sometimes* I could use a third. [Edit] Also - everything you pointed out in your message has to do with the editor - not language limitations and the like. So, it's a bit unfair to blame C# for any of this. I wonder if VS Code behaves better under the circumstances you describe...or third-party editors?
-
den2k88 wrote:
And the breakpoint after the parsing moves the focus to the VS window hiding the Command prompt.
Well at least that one's easy to fix, get another monitor and reshuffle your windows around so they don't overlap. It's really nice to have an unobscured view of the IDE open on one monitor, then a browser / console / Explorer windows on another, alongside a bunch of debug windows (locals / watch windows / output window / etc). I typically RDP into my dev VM using a 4K monitor and a 1080p one, and that's my sweet spot. Although *sometimes* I could use a third. [Edit] Also - everything you pointed out in your message has to do with the editor - not language limitations and the like. So, it's a bit unfair to blame C# for any of this. I wonder if VS Code behaves better under the circumstances you describe...or third-party editors?
dandy72 wrote:
Well at least that one's easy to fix, get another monitor
No space, on my lab desk (the only place where I can debug) I have the specimen cage, and very large power supply (it has to provide up to 170 Amperes at 60V). I have barely enough space to cram the closed laptop between the power supply and the base of the monitor, especially because I also have a fixed drawer cabinet that forces the ergonomic position only barely where the monitor is. Plus the laptop has a single HDMI port anyway and the docking station is available only in the office desk, not le lab one.
GCS/GE d--(d) s-/+ a C+++ U+++ P-- L+@ E-- W+++ N+ o+ K- w+++ O? M-- V? PS+ PE Y+ PGP t+ 5? X R+++ tv-- b+(+++) DI+++ D++ G e++ h--- r+++ y+++* Weapons extension: ma- k++ F+2 X The shortest horror story: On Error Resume Next
-
They wouldn't.
GCS/GE d--(d) s-/+ a C+++ U+++ P-- L+@ E-- W+++ N+ o+ K- w+++ O? M-- V? PS+ PE Y+ PGP t+ 5? X R+++ tv-- b+(+++) DI+++ D++ G e++ h--- r+++ y+++* Weapons extension: ma- k++ F+2 X The shortest horror story: On Error Resume Next
-
Rename Main(...) to Main2(...) Insert a Main() routine and make it call Main2 with your test cases.
Check out my IoT graphics library here: https://honeythecodewitch.com/gfx And my IoT UI/User Experience library here: https://honeythecodewitch.com/uix
Obviously, but it's not something I like to do because what's being tested and validated is Main2 and not Main. It did happen that seemingly harmless test code broke or unbroke some behavior in the test subject so I try to avoid it as much as possible.
GCS/GE d--(d) s-/+ a C+++ U+++ P-- L+@ E-- W+++ N+ o+ K- w+++ O? M-- V? PS+ PE Y+ PGP t+ 5? X R+++ tv-- b+(+++) DI+++ D++ G e++ h--- r+++ y+++* Weapons extension: ma- k++ F+2 X The shortest horror story: On Error Resume Next
-
Time to move to WinDbg.
If only I could install anything (I managed to install VS before they took away that privilege).
GCS/GE d--(d) s-/+ a C+++ U+++ P-- L+@ E-- W+++ N+ o+ K- w+++ O? M-- V? PS+ PE Y+ PGP t+ 5? X R+++ tv-- b+(+++) DI+++ D++ G e++ h--- r+++ y+++* Weapons extension: ma- k++ F+2 X The shortest horror story: On Error Resume Next
-
I like your thread subject :thumbsup: :laugh:
Thank you, frustration brings out the comedian in me :D
GCS/GE d--(d) s-/+ a C+++ U+++ P-- L+@ E-- W+++ N+ o+ K- w+++ O? M-- V? PS+ PE Y+ PGP t+ 5? X R+++ tv-- b+(+++) DI+++ D++ G e++ h--- r+++ y+++* Weapons extension: ma- k++ F+2 X The shortest horror story: On Error Resume Next
-
In this particular case it takes the same amount of code to visually inspect the relevant data structures + the test code + the validation code + the debug of the unit test. Considering that the user interface will not have any upgrade (it is to be inserted in an automated tool) the overhead is way too much for the scope of the project - I did terminate the whole software less than 2 hours after ranting. My gripe was not with the process I was using but by the fact that debugging a console application should naturally allow an easy way to pass arguments to said application. Also IT has to justify their paychecks so they :elephant: the group policies weekly, this week they messed up a the VS developer console (we don't use VS in house, we develop for ARM microcontrollers and our legit tools are uVision and Understand).
GCS/GE d--(d) s-/+ a C+++ U+++ P-- L+@ E-- W+++ N+ o+ K- w+++ O? M-- V? PS+ PE Y+ PGP t+ 5? X R+++ tv-- b+(+++) DI+++ D++ G e++ h--- r+++ y+++* Weapons extension: ma- k++ F+2 X The shortest horror story: On Error Resume Next
-
Obviously, but it's not something I like to do because what's being tested and validated is Main2 and not Main. It did happen that seemingly harmless test code broke or unbroke some behavior in the test subject so I try to avoid it as much as possible.
GCS/GE d--(d) s-/+ a C+++ U+++ P-- L+@ E-- W+++ N+ o+ K- w+++ O? M-- V? PS+ PE Y+ PGP t+ 5? X R+++ tv-- b+(+++) DI+++ D++ G e++ h--- r+++ y+++* Weapons extension: ma- k++ F+2 X The shortest horror story: On Error Resume Next
Another option is to set the startup object in the project settings. That way you can have two mains, and call the second from the first. It doesn't entirely solve your problem, but it's an option.
Check out my IoT graphics library here: https://honeythecodewitch.com/gfx And my IoT UI/User Experience library here: https://honeythecodewitch.com/uix
-
dandy72 wrote:
Well at least that one's easy to fix, get another monitor
No space, on my lab desk (the only place where I can debug) I have the specimen cage, and very large power supply (it has to provide up to 170 Amperes at 60V). I have barely enough space to cram the closed laptop between the power supply and the base of the monitor, especially because I also have a fixed drawer cabinet that forces the ergonomic position only barely where the monitor is. Plus the laptop has a single HDMI port anyway and the docking station is available only in the office desk, not le lab one.
GCS/GE d--(d) s-/+ a C+++ U+++ P-- L+@ E-- W+++ N+ o+ K- w+++ O? M-- V? PS+ PE Y+ PGP t+ 5? X R+++ tv-- b+(+++) DI+++ D++ G e++ h--- r+++ y+++* Weapons extension: ma- k++ F+2 X The shortest horror story: On Error Resume Next
den2k88 wrote:
Plus the laptop has a single HDMI port anyway and the docking station is available only in the office desk, not le lab one.
I was gonna say, there's USB to HDMI adapters, but I see you have bigger (physical) problems to deal with. I can sympathize. My desk is L-shaped; 5-feet long on the shorter end, and 8-feet long on the other. I couldn't find a spot to put a standard 8.5" x 11" sheet of paper to lay flat to write on.
-
Another small rant, two-for-one. 1) Debugging console applications with parameters is painful. I need to test against all the possible combinations of arguments, can't do it properly though, need to pass through the debug options... which are persistent. And the console does not stay open (yes the checkbox is unchecked, also ignored by VS). And the breakpoint after the parsing moves the focus to the VS window hiding the Command prompt. Every test is a clickity-clickity-typety-clickity-clickity-clickity-clickity-clak. :elephant: you Microsoft. 2) Structures in watch window do not stay expanded. Add other clickity-clickity-claks to a simple test. Basically the best way to test this behavior is inserting test code and debug prints, as we used to do when we had to chisel bits one by one onto EEPROMS with tiny hammers and a lot of patience. Told you it was a rant.
GCS/GE d--(d) s-/+ a C+++ U+++ P-- L+@ E-- W+++ N+ o+ K- w+++ O? M-- V? PS+ PE Y+ PGP t+ 5? X R+++ tv-- b+(+++) DI+++ D++ G e++ h--- r+++ y+++* Weapons extension: ma- k++ F+2 X The shortest horror story: On Error Resume Next
den2k88 wrote:
And the console does not stay open (yes the checkbox is unchecked, also ignored by VS).
You can run a command line tool in a Process. And then feed what ever you want to the command line and then collect the output. So build a testing harness. Alternatively I used 'AutoIt' to test console apps some years ago.
-
In this particular case it takes the same amount of code to visually inspect the relevant data structures + the test code + the validation code + the debug of the unit test. Considering that the user interface will not have any upgrade (it is to be inserted in an automated tool) the overhead is way too much for the scope of the project - I did terminate the whole software less than 2 hours after ranting. My gripe was not with the process I was using but by the fact that debugging a console application should naturally allow an easy way to pass arguments to said application. Also IT has to justify their paychecks so they :elephant: the group policies weekly, this week they messed up a the VS developer console (we don't use VS in house, we develop for ARM microcontrollers and our legit tools are uVision and Understand).
GCS/GE d--(d) s-/+ a C+++ U+++ P-- L+@ E-- W+++ N+ o+ K- w+++ O? M-- V? PS+ PE Y+ PGP t+ 5? X R+++ tv-- b+(+++) DI+++ D++ G e++ h--- r+++ y+++* Weapons extension: ma- k++ F+2 X The shortest horror story: On Error Resume Next
I have a general gripe with Visual Studio where you need a separate project per main(). I tend to code each entry point as a separate class in a DLL project with a myMain(). I have one Console app that just calls into the correct class. This also allows you to UnitTest the separate classes.