Debugging in Visual Studio

[ic2]

Hi Phil,

You write "enjoy driving".
I hope you enjoy waiting as much - you will often have to do it, and you get very looooong breaks, after trying to find a charging station. That is, if you haven't crashed because you were trying to get your windscreen wipers on which may be hidden 3 submenu's from your current view on Tesla's touchscreen.

I would love to drive a non petrol car too but only when I can drive a 1000 km and then recharge in half an hour at most. As this may be technically impossible, my waiting may result in a hydrogen car from which I can wave to the electrical car owners while driving past the charging stations were they have to spend the next hour.

Dick

[ic2]

Hello Wolfgang,

I fully agree with 1) - we do the same. To my own surprise, 2 doesn't seem to matter - when I replaced my Vulcan created WPF screen with a VO screen again because when it was displayed Sven's toolbar stopped displaying text+icons for some unknown reason, nobody reacted negative. Instead I got one reaction saying they liked the new screen better....
And about 3 - with XIDE it's partly a different story - but for Winforms applications.
Dick

[wriedmann]

Hi Dick,

And about 3 - with XIDE it's partly a different story - but for Winforms applications.

As you know, I have opted for code-based WPF screens because I feel there is much less code and more oversight over my code.
But yes, sometimes I'm missing a sort of an graphical editor....

Wolfgang

[ic2]

Hello Chris,

With the knowledge you gave me today, and as soon as I have finished converting Vulcan to X#, and re-installed VS 2017 (Set Next statement is not in VS 2015 and getting VS 2017 to work is a challenge but let's assume for a moment it works) you may be right for C#, but not -yet- for Vulcan compatible code. The most important thing in a debugger IMO is the ability to run some code to see the result of some actions on a variable. In the immediate window I can not issue Vulcan/X# commands. In VO I can issue VO commands and it works. Without X#/Vulcan code working in the immediate window there's no way I can gain productivity. I have tried it a few times, entering all kind of case combinations and finally gave up, stopped my code and programmed temporary windows to show me results. In VO I would have had this result 10 minutes earlier....

But it's great to hear it's on the ToDo list. I thought it was not possible to implement it.

I agree with you that you eventually get used to everything. If new cars will come with square wheels everyone will forget how much more comfortable the round wheels were unless they still own such a car. VO's repo obviously being the round wheels.

Maybe this is (partly) a solution to my problem https://vlasovstudio.com/task-canvas/. I'll check that out. Phil may think I oppose everything new but this isn't the case; I oppose everything making my life harder and unfortunately this is too often the case with new technologies. I am now working with VS since VS 2010 so it's not new but my feeling towards it is unfortunately unchanged- it is always a relief to go back to my VO programming.

Dick

[Chris]

Hi Dick,

SetNextStatement has been available at least since VS2010, even VS2008 or previous probably, if it's not visible then you probably need to tell VS to show it. Or it is hidden in a submenu or something . about the X# syntax in evaluation, yes, I absolutely agree, this is important to be implemented.

Regarding getting used to things, you may know that I, like you, absolutely hate and never do that, just for the sake of doing it. For example I completely refuse to use some things in newer windows versions the way MS "wants" us to, so first thing I do is to install the Classic Explorer and stuff like that, which make things work again in an intuitive and practical way (IMO) and not the way MS tells us they and we should work.

So when I am suggesting that you will be used to the .Net way of doing things, I don't mean that you will learn to live with it, but I think you will find that it is in many (not all) ways better than what you use now. For your analogy, I would describe VO as a very good tire designed to handle speeds upto 320 km/h (200mph for our imperial friends ) in dry conditions without issue. On the other hand, .Net possibly is a tire that can handle upto 250 km/h, but can also handle wet roads, snow, ice, extreme heat, allows 3rd parties to easily further enhance its characteristics etc. And it lasts much longer

Chris

[NickFriend]

Hello Chris,
Maybe this is (partly) a solution to my problem https://vlasovstudio.com/task-canvas/. I'll check that out. Phil may think I oppose everything new but this isn't the case; I oppose everything making my life harder and unfortunately this is too often the case with new technologies. I am now working with VS since VS 2010 so it's not new but my feeling towards it is unfortunately unchanged- it is always a relief to go back to my VO programming.

This looks like a terrible idea, as all it's doing is encouraging you to try and work against the way projects are structured in VS, and so prolong your agony of adapting. If you need to edit several different files, just open them all up and spread them around over a couple of monitors since you can easily drag windows out of the VS shell (unlike with VO).

To be honest it seems to me that the only reason you can't progress with VS is because you're not actually willing to spend the time to learn how to use it. All your suffering with debugging would have been avoided by 30 seconds looking at the Debug menu so that you could choose "Start Debugging" instead of "Start without Debugging". VS is a large complex program which needs to be learnt to be able to take advantage of it.

Nick

[Phil Hepburn]

So would you have an electric car fitted to your nice new shiny tyre ?

P.

[Chris]

Hi Phil,

So would you have an electric car fitted to your nice new shiny tyre ?

If it doesn't have the big disadvantages Dick mentioned, then absolutely yes!

Chris

[ic2]

I learned a lot today - indeed the command is in the right mouse menu. I can imagine this to be handy. And I think your "tire" comparison is brilliant and true - there might actually be a point where the sum of VS features outweigh the sum of VO features for me but with me relying on navigating through last changed/programmed entities and the intensive use of Ctrl X for debugging, at this moment I prefer the 'speed tires'.

I just installed the above mentioned plug in and it does allow me to edit 1 entity in a separate window - you see that changes are simultaneously done in the main window. It's $ 49 which I think is reasonable. Let's see if it also could offer accessing latest changes. If so, and with X# command working in the immediate window, I will have a good incentive to move to X#+VS.

Dick

Dick

[ic2]

Hello Nick,

I think you misunderstand this. I am not talking about opening multiple files. I am talking about opening just one entity without the chance to accidentally change (read: delete) code of a next method, which happened to me in VS more than once. And find back quickly what I was editing last. You can't in VS. Or can you? If so: how?

Now Nick, just look objectively at the organization of code in VO, where you see a sortable list of entities (sortable on last changed, creation time, type and more) compared to a prg/cs in VS with all code randomly dropped somewhere. Unless you spend a lot of time with half baked "solutions" like regions or manually moving code - which is a lot easier from a VO browser anyway.

So I don't have an agony of adapting, but an agony of being forced to work with less efficient tools.

Finally, no doubt I am not aware of certain VS options which could be useful. But of course I know the difference of Start Debugging and Start without debugging. Only in VO you don't need to make that choice to allow efficient debugging of run time errors (as long as Debug is on, that is). So I never realized that in VS you have to.

Dick