Hi Dick,
Ah, yes, the Sort Entity by date changed feature...this indeed was handy also for me to have in VO and I haven't found a good enough alternative (apart from having multiple backups of my code which can be compared externally to find when something specific was changed). Yes, I agree, this is one of the advantages of the VO repo.
Chris
Debugging in Visual Studio
Debugging in Visual Studio
Chris Pyrgas
XSharp Development Team
chris(at)xsharp.eu
XSharp Development Team
chris(at)xsharp.eu
-
NickFriend
- Posts: 248
- Joined: Fri Oct 14, 2016 7:09 am
Debugging in Visual Studio
Hi Dick,
I strongly suspect the problem may be with the way you structure your code. Seriously, I've been working for several years with VS on a daily basis (as in all day every day), and as you know with a fairly large solution, and I have no problems with handling the code base.
I think the clues are down to organisation of the code. Contrary to what you say there is NOTHING random about how the source code is presented in VS. It is presented exactly as you choose to organise it. You can structure the code in files, within the files you can expand/collapse code by namespace, class, region, method, property, loops etc. These are in no way half-baked. The only thing that maybe would be useful very occasionally is the last modified option, and there is an add-on for that, AutoHistory I think it's called (which does other stuff as well) - I used it for a while, but it was so infrequent that when I upgraded to VS2017 I never bothered installing it.
If your code is not very well encapsulated (with lots of dependencies between methods and classes), or if your methods are too long, then I can see that you will have problems because you'll need to have lots of entities open at once to understand what's going on.... but the problem is not with the tool, it's with the code. Methods should be short, self-contained and have a clearly defined purpose. If you do that, you simply don't need to open lots of things at once.
Anyway, we can go round in circles with this ad infintum... I hate the VO IDE now, you hate VS, what are we going to do!
Nick
I strongly suspect the problem may be with the way you structure your code. Seriously, I've been working for several years with VS on a daily basis (as in all day every day), and as you know with a fairly large solution, and I have no problems with handling the code base.
I think the clues are down to organisation of the code. Contrary to what you say there is NOTHING random about how the source code is presented in VS. It is presented exactly as you choose to organise it. You can structure the code in files, within the files you can expand/collapse code by namespace, class, region, method, property, loops etc. These are in no way half-baked. The only thing that maybe would be useful very occasionally is the last modified option, and there is an add-on for that, AutoHistory I think it's called (which does other stuff as well) - I used it for a while, but it was so infrequent that when I upgraded to VS2017 I never bothered installing it.
If your code is not very well encapsulated (with lots of dependencies between methods and classes), or if your methods are too long, then I can see that you will have problems because you'll need to have lots of entities open at once to understand what's going on.... but the problem is not with the tool, it's with the code. Methods should be short, self-contained and have a clearly defined purpose. If you do that, you simply don't need to open lots of things at once.
Anyway, we can go round in circles with this ad infintum... I hate the VO IDE now, you hate VS, what are we going to do!
Nick
-
Phil Hepburn
- Posts: 743
- Joined: Sun Sep 11, 2016 2:16 pm
Debugging in Visual Studio
Dick,
I have told you on numerous occasions it id 'Ctrl' + - (minus sign)
This way you can step backwards (multiple times) to where you were last editing - this works both within the file as well as across any file, code or script. I use it all the time.
AND - I have definitely told you this before.
Regards,
Phil.
I have told you on numerous occasions it id 'Ctrl' + - (minus sign)
This way you can step backwards (multiple times) to where you were last editing - this works both within the file as well as across any file, code or script. I use it all the time.
AND - I have definitely told you this before.
Regards,
Phil.
Debugging in Visual Studio
Hello Phil,
I have told you on numerous occasions it id 'Ctrl' + - (minus sign)
First, this is not what I meant. I'll explain. A client posts an issue that something doesn't work. In VO, I click the AEF/MEF where it goes wrong and sort on Date last changed. In most cases I'm at the 'suspicious code' in a few seconds. Also, it is very useful if I am programming at something, to quickly see the couple of methods involved in these changes to continue working on them. I've seen no comparable way to achieve that in VS.
Nick is referring to AutoHistory, but there you only see the whole .prg/.cs which was last changed, not which method. By double clicking on it you can see differences but that's comparable to VOPP. Great but not a quick way to just see which method was last changed.
Second, what you mention could be very useful while editing but Ctrl + work. It doesn't do anything. I use the Ctrl key and the plus from the numeric keyboard and also tried from the upper rows of keys which requires Ctrl Shift + to get a plus (and not a =). But Ctrl - works. Strange, because
1) Ctrl + is mentioned in https://msdn.microsoft.com/en-us/library/da5kh0wa.aspx but I can't find Crtl -.
2) Ctrl + is Edit/Navigate and I found I have not reassigned Ctrl +.
Dick
I have told you on numerous occasions it id 'Ctrl' + - (minus sign)
First, this is not what I meant. I'll explain. A client posts an issue that something doesn't work. In VO, I click the AEF/MEF where it goes wrong and sort on Date last changed. In most cases I'm at the 'suspicious code' in a few seconds. Also, it is very useful if I am programming at something, to quickly see the couple of methods involved in these changes to continue working on them. I've seen no comparable way to achieve that in VS.
Nick is referring to AutoHistory, but there you only see the whole .prg/.cs which was last changed, not which method. By double clicking on it you can see differences but that's comparable to VOPP. Great but not a quick way to just see which method was last changed.
Second, what you mention could be very useful while editing but Ctrl + work. It doesn't do anything. I use the Ctrl key and the plus from the numeric keyboard and also tried from the upper rows of keys which requires Ctrl Shift + to get a plus (and not a =). But Ctrl - works. Strange, because
1) Ctrl + is mentioned in https://msdn.microsoft.com/en-us/library/da5kh0wa.aspx but I can't find Crtl -.
2) Ctrl + is Edit/Navigate and I found I have not reassigned Ctrl +.
Dick
Debugging in Visual Studio
Hello Nick,
I learned a lot from you on the Devshare's and seen your code but that's what makes me wonder even more how people could like the code organization in VS better than in VO. You write:
I think the clues are down to organisation of the code. Contrary to what you say there is NOTHING random about how the source code is presented in VS. It is presented exactly as you choose to organise it.
Sure, you can move and shift code and add regions, but that's all manual work about which you don;'t have to bother at all in VO - that's why I call it half baked in VS. I don't think most methods I programmed are too long and I think there are no 'impossible' dependencies.
So maybe you can explain, see also my reply to Phil: how do you quickly locate the last 3-4 methods you've been working on? If you have a lot of short methods, you will have a .cs file with many methods, which makes localizing a few -probably scattered around that file- of them even harder I'd say. Or do you store every single method in a separate file and use Windows Explorer to see what you changed last?
And second question: Suppose you have written method A which also performs task B. This task can also be used by the completely different methods C and D (hiding in a different region for example, but within the same .cs program file). So I write a separate method B in a region called 'general functions' for example. Still, all in the same .cs file.
Now in VO, I can open just method A and B, regardless of their physical location in the program. I locate them with one click sorting on Date last changed. With another click I can divide the screen in 2 vertical halves, seeing the complete code of the calling method left and the called method in which I want to make some changes, in the right pane. After I've done that, again just one click is sufficient to close the second pane again.
Now, how do you do the same (finding, the editing of 2 different located methods, quick vertical split/unsplit) in VS?
I think the closest way to achieve this is writing on a piece of paper the name(s) of the method(s), opening it and editing the second one in the Peek Definition window, which is horizontal. VS does not have a quick (=one key) way to split/unsplit windows. The Window/Split option splits horizontally which is not the most logical way to split in the era of 4K 16x9 monitors. VO allows splitting horizontal/vertical, both and unsplitting with the same shortcuts or icons.
I would be very happy to publicly write here that I missed some important VS options because then I can do my VS work far more efficient and maybe actually start to like VS as well. Like the fact that I need to always start in Debug mode to quickly debug exceptions. So please enlighten me on this: how do you do this with (about) the same effort/number of steps?
Dick
I learned a lot from you on the Devshare's and seen your code but that's what makes me wonder even more how people could like the code organization in VS better than in VO. You write:
I think the clues are down to organisation of the code. Contrary to what you say there is NOTHING random about how the source code is presented in VS. It is presented exactly as you choose to organise it.
Sure, you can move and shift code and add regions, but that's all manual work about which you don;'t have to bother at all in VO - that's why I call it half baked in VS. I don't think most methods I programmed are too long and I think there are no 'impossible' dependencies.
So maybe you can explain, see also my reply to Phil: how do you quickly locate the last 3-4 methods you've been working on? If you have a lot of short methods, you will have a .cs file with many methods, which makes localizing a few -probably scattered around that file- of them even harder I'd say. Or do you store every single method in a separate file and use Windows Explorer to see what you changed last?
And second question: Suppose you have written method A which also performs task B. This task can also be used by the completely different methods C and D (hiding in a different region for example, but within the same .cs program file). So I write a separate method B in a region called 'general functions' for example. Still, all in the same .cs file.
Now in VO, I can open just method A and B, regardless of their physical location in the program. I locate them with one click sorting on Date last changed. With another click I can divide the screen in 2 vertical halves, seeing the complete code of the calling method left and the called method in which I want to make some changes, in the right pane. After I've done that, again just one click is sufficient to close the second pane again.
Now, how do you do the same (finding, the editing of 2 different located methods, quick vertical split/unsplit) in VS?
I think the closest way to achieve this is writing on a piece of paper the name(s) of the method(s), opening it and editing the second one in the Peek Definition window, which is horizontal. VS does not have a quick (=one key) way to split/unsplit windows. The Window/Split option splits horizontally which is not the most logical way to split in the era of 4K 16x9 monitors. VO allows splitting horizontal/vertical, both and unsplitting with the same shortcuts or icons.
I would be very happy to publicly write here that I missed some important VS options because then I can do my VS work far more efficient and maybe actually start to like VS as well. Like the fact that I need to always start in Debug mode to quickly debug exceptions. So please enlighten me on this: how do you do this with (about) the same effort/number of steps?
Dick
-
Phil Hepburn
- Posts: 743
- Joined: Sun Sep 11, 2016 2:16 pm
Debugging in Visual Studio
Sorry - it was my poor way of typing it - bad syntax.
Try holding down the Ctrl key and then pressing the minus key. (Minus for going backwards.) Each press takes you back an editing 'position' step. To all places where the cursor was moved.
I will check this now (these things become automatic) - it is a great help to me, every day.
YES - it took me from code behind in X#, to C# in another project, and to XAML script in a WPF window / form. Anywhere in the solution where the cursor has been / rested.
The best I can suggest for file based stuff is the regular use of the source control (SC) perhaps. I use it a lot for saving but USUALLY never need to return to it and search through the versions etc..
I was there in London when Brian asked the whole bunch of attendees at possibly the 2005 event of DevFest, if guys wanted a Repository or would like to "go with the flow" and use the MS file based system. No more than one hand was raised. So file editing we have, and by a huge majority.
However, you can easily go back to the full code version before you screwed up your customers app code using SC. Do you 'commit' very often, or in a planned and organised way ?
You need to ask others more proficient than me about SC use.
Good Luck,
Phil.
Try holding down the Ctrl key and then pressing the minus key. (Minus for going backwards.) Each press takes you back an editing 'position' step. To all places where the cursor was moved.
I will check this now (these things become automatic) - it is a great help to me, every day.
YES - it took me from code behind in X#, to C# in another project, and to XAML script in a WPF window / form. Anywhere in the solution where the cursor has been / rested.
The best I can suggest for file based stuff is the regular use of the source control (SC) perhaps. I use it a lot for saving but USUALLY never need to return to it and search through the versions etc..
I was there in London when Brian asked the whole bunch of attendees at possibly the 2005 event of DevFest, if guys wanted a Repository or would like to "go with the flow" and use the MS file based system. No more than one hand was raised. So file editing we have, and by a huge majority.
However, you can easily go back to the full code version before you screwed up your customers app code using SC. Do you 'commit' very often, or in a planned and organised way ?
You need to ask others more proficient than me about SC use.
Good Luck,
Phil.
-
NickFriend
- Posts: 248
- Joined: Fri Oct 14, 2016 7:09 am
Debugging in Visual Studio
Hi Dick,
Like I said, you like the VO IDE, I like VS...
I see nothing wrong with the VS window splitting, you don't even need to go to the menu or click anything, just drag the splitter.
Classes, methods and files - a) I can't imagine many situations where a method had multiple uses and even if it did, it should be self-contained so you only need to be aware of its parameters (via Intellisense) so why do you need to have it open in front of you? and b) I keep each class in a separate file, I rarely have more than 10-15 methods in a class, and a lot of those will be short (say <30 lines). Each class is divided into standardised regions so I know exactly where any given method or property will be.
If I do edit several things in a file, then simply glancing at the scroll bar shows you immediately where changes were made (obviously you lose this once the file has closed). For heavens sake you can't even expand/collapse code in the VO editor, whereas you can do it at multiple levels in VS (including user defined with regions).
Anyway, it's not my job to make you like VS, so good luck!
Nick
Like I said, you like the VO IDE, I like VS...
I see nothing wrong with the VS window splitting, you don't even need to go to the menu or click anything, just drag the splitter.
Classes, methods and files - a) I can't imagine many situations where a method had multiple uses and even if it did, it should be self-contained so you only need to be aware of its parameters (via Intellisense) so why do you need to have it open in front of you? and b) I keep each class in a separate file, I rarely have more than 10-15 methods in a class, and a lot of those will be short (say <30 lines). Each class is divided into standardised regions so I know exactly where any given method or property will be.
If I do edit several things in a file, then simply glancing at the scroll bar shows you immediately where changes were made (obviously you lose this once the file has closed). For heavens sake you can't even expand/collapse code in the VO editor, whereas you can do it at multiple levels in VS (including user defined with regions).
Anyway, it's not my job to make you like VS, so good luck!
Nick
Debugging in Visual Studio
Hello Nick,
I see nothing wrong with the VS window splitting, you don't even need to go to the menu or click anything, just drag the splitter.
The splitter splits an edit window and the window where the solution (and more) show. I want to vertically split the edit screen. I can use view/split; then I get a splitter in the editor but this is horizontal, not vertical.
I know how I can do it:
1 Alt + W, N (=Window menu, New Window)
2 Alt + W, V (=Window, New vertical tab group
3 Drag the splitter.
But in VO it's one click instead of 4 key strokes + a mouse drag.
I can't imagine many situations where a method had multiple uses and even if it did, it should be self-contained so you only need to be aware of its parameters (via Intellisense) so why do you need to have it open in front of you? a
That's quite clear. I have my Photo program and at the end of a method doing something I rebuild the browser. Then some other methods basically have the rebuilding same code so I separate the rebuilding code into a method. While programming it, it is very useful to keep one eye on the code where it is called from while program some changes to make it 'general'. VO allows me to do that, VS does not.
you immediately where changes were made (obviously you lose this once the file has closed).
Right. That's the whole point. You lose that info after closing it.
Anyway, it's not my job to make you like VS, so good luck!
I think I'm mainly surprised where your level of VS satisfaction comes from. Could be because I miss the advantages but I think hat what I consider most important for efficient coding, you do not and/or are used to the less objectively efficient methods.
Thanks anyway for your explanations. And for the good luck
.
Dick
I see nothing wrong with the VS window splitting, you don't even need to go to the menu or click anything, just drag the splitter.
The splitter splits an edit window and the window where the solution (and more) show. I want to vertically split the edit screen. I can use view/split; then I get a splitter in the editor but this is horizontal, not vertical.
I know how I can do it:
1 Alt + W, N (=Window menu, New Window)
2 Alt + W, V (=Window, New vertical tab group
3 Drag the splitter.
But in VO it's one click instead of 4 key strokes + a mouse drag.
I can't imagine many situations where a method had multiple uses and even if it did, it should be self-contained so you only need to be aware of its parameters (via Intellisense) so why do you need to have it open in front of you? a
That's quite clear. I have my Photo program and at the end of a method doing something I rebuild the browser. Then some other methods basically have the rebuilding same code so I separate the rebuilding code into a method. While programming it, it is very useful to keep one eye on the code where it is called from while program some changes to make it 'general'. VO allows me to do that, VS does not.
you immediately where changes were made (obviously you lose this once the file has closed).
Right. That's the whole point. You lose that info after closing it.
Anyway, it's not my job to make you like VS, so good luck!
I think I'm mainly surprised where your level of VS satisfaction comes from. Could be because I miss the advantages but I think hat what I consider most important for efficient coding, you do not and/or are used to the less objectively efficient methods.
Thanks anyway for your explanations. And for the good luck
.Dick
Debugging in Visual Studio
Hello Phil,
I was there in London when Brian asked the whole bunch of attendees at possibly the 2005 event of DevFest, if guys wanted a Repository or would like to "go with the flow" and use the MS file based system. No more than one hand was raised. So file editing we have, and by a huge majority.
I think this can be (partly) explained by the problems most users had with the repository before 2005 (the year when we still had VO 2.7b1). I wonder how people would have voted when they had 2.8 SP4, and saw how a file based system works compared to a repo.
However, you can easily go back to the full code version before you screwed up your customers app code using SC. Do you 'commit' very often, or in a planned and organised way ?
You're right, source control could be a (more time consuming) work around to find last changes. I must confess I stopped using SC completely. After trying the several systems a few years ago, only one worked more or less and this required 2 products to be installed (Tortoise and something else) and manual committing. Then I lost the last changes trying to check what the program did with an older version (I suspect I should have committed before trying that, but the program didn't warn for that). From time to time it also told me that my code was out of sync (which was not true, but it was a known bug which they never repaired completely so it regularly took me an hour to go through a bag of tricks to repair it).
I ended up committing only once in a while and after reinstalling my Pc I didn't bother to reinstall that crappy stuff.
Which SC are you using Phil, and does this work well?
Dick
I was there in London when Brian asked the whole bunch of attendees at possibly the 2005 event of DevFest, if guys wanted a Repository or would like to "go with the flow" and use the MS file based system. No more than one hand was raised. So file editing we have, and by a huge majority.
I think this can be (partly) explained by the problems most users had with the repository before 2005 (the year when we still had VO 2.7b1). I wonder how people would have voted when they had 2.8 SP4, and saw how a file based system works compared to a repo.
However, you can easily go back to the full code version before you screwed up your customers app code using SC. Do you 'commit' very often, or in a planned and organised way ?
You're right, source control could be a (more time consuming) work around to find last changes. I must confess I stopped using SC completely. After trying the several systems a few years ago, only one worked more or less and this required 2 products to be installed (Tortoise and something else) and manual committing. Then I lost the last changes trying to check what the program did with an older version (I suspect I should have committed before trying that, but the program didn't warn for that). From time to time it also told me that my code was out of sync (which was not true, but it was a known bug which they never repaired completely so it regularly took me an hour to go through a bag of tricks to repair it).
I ended up committing only once in a while and after reinstalling my Pc I didn't bother to reinstall that crappy stuff.
Which SC are you using Phil, and does this work well?
Dick
Debugging in Visual Studio
Hi Dick,
maybe I can add my 2 cents as non-VS fan: Visual Objects was years ahead with his repository based development, and unfortunately these times are over and we are back to the file based approach of the other development languages.
For the file based approach that now is common to nearly all development tools we must change: in VO it was no problem to have modules with 100s of entities, and we could edit them one per one, and see the changes entity-wise.
With file based development the only solution to this seems to be a SCC.
And we need to change: smaller files with less entities.
In the change, we can now structure our code better, using subdirectories (physically) and namespaces (logically).
Times have changed, and we have to adopt, and cannot turn back, unfortunately.
Wolfgang
maybe I can add my 2 cents as non-VS fan: Visual Objects was years ahead with his repository based development, and unfortunately these times are over and we are back to the file based approach of the other development languages.
For the file based approach that now is common to nearly all development tools we must change: in VO it was no problem to have modules with 100s of entities, and we could edit them one per one, and see the changes entity-wise.
With file based development the only solution to this seems to be a SCC.
And we need to change: smaller files with less entities.
In the change, we can now structure our code better, using subdirectories (physically) and namespaces (logically).
Times have changed, and we have to adopt, and cannot turn back, unfortunately.
Wolfgang
Wolfgang Riedmann
Meran, South Tyrol, Italy
wolfgang@riedmann.it
https://www.riedmann.it - https://docs.xsharp.it
Meran, South Tyrol, Italy
wolfgang@riedmann.it
https://www.riedmann.it - https://docs.xsharp.it