xsharp.eu • Debugging in Visual Studio - Page 4
Page 4 of 8

Debugging in Visual Studio

Posted: Tue Feb 13, 2018 12:08 pm
by Phil Hepburn
Hi Nick,

Also, for the benefit of others, collapsing (of hiding) 'on the fly' with 'Ctrl +M +H' (h for hide) actually temporarily hides / collapses the section highlighted when the key strokes were made. Seems to be any bunch of lines - to make more screen space etc.

I like this, and use it each and every day - as well as using the standard expand/collapse and now #regions which I copied from your good self a few moons back.

I found that when I stopped hating VS, and decided to embrace it, then colleagues armed me with a few VERY handy tips - and I was away. Loving comes a lot later after much use and productivity.

Although VS is very complex, it can be used in a VERY straight forward way, once we stop worrying about it. Oh! and importantly, know how to get the windows / panes back when we may have closed or removed them by mistake. I have some good suggested 'exercises' on this front/topic.

Regards to all,
Phil.
Wales, UK.

Debugging in Visual Studio

Posted: Tue Feb 13, 2018 12:19 pm
by Phil Hepburn
Hi Wolfgang,

Nicely said, my practical approach and attitude to it as well. Like it or not, we have to move forward and make the best of what we have as software tools.

There are many high powered IT developer guys around the world using VS effectively each day - I try to find out from them the best way to do things VS. Paul Piko helped me a lot in my early days - THANKS Paul.

From my own experience I think the problems come when we try to use VS for real tasks, but before we know how to 'drive' it. We need to spend at least some time finding and testing out the basic skills and knowledge. That was when I really 'took off'.

Also, the silly thing is that we as a Forum have some very knowledgeable and helpful guys in our midst who could help us learn more about using VS - and we don't even have a special Forum area / folder for VS. To my mind that 'speaks volumes' !!!

I even kept away from conference sessions in my seven DevShare events I planned, simply because I thought there were too many 'anti' attendees around.

Cheers, and have a nice day,
Phil.

Debugging in Visual Studio

Posted: Tue Feb 13, 2018 1:58 pm
by Phil Hepburn
Hi guys,

For any would-be navigator guys (within the VS editors) here is a useful small image I just found - while I was trying to learn the 'hot key' / 'nav key' way to move forwards through the editors as well as the way I regularly use, to move backwards through them.

So here it is :-
NavKeysVS_01.jpg
NavKeysVS_01.jpg (43.02 KiB) Viewed 366 times
Remember that the syntax for reading these shortcut key combinations is to take the + sign as meaning 'also with' and NOT the + key itself.

So the forward navigation which I have just tried out successfully, is hold down Ctrl key and also the shift key, and then press the minus sign key. Each press of the ' - ' will jump forward a cursor previous position.

I suggest you VS folks all go and give it a go/work-out, if this is new to you.

Regards,
Phil.

P.S. here is the link :-
https://blogs.msdn.microsoft.com/zainna ... e-forward/

Debugging in Visual Studio

Posted: Tue Feb 13, 2018 2:36 pm
by Chris
Guys,

In my X# apps, I have a lots of .prg files that are 3000-10000 lines long, with countless entities in them :). Honestly, I don't miss the repo even with such a structure, just got used to navigating in a different way and it feels good to me now. Although at first I was indeed missing the repo as well.

Chris

Debugging in Visual Studio

Posted: Tue Feb 13, 2018 2:46 pm
by ic2
Hello Phil,

Thanks for explaining that. That's why I couldn't find it in the MS page., it says Ctrl +- and Ctrl+Shift+-. Note that this does NOT work with the - on the numeric keyboard.

It doesn't help for quickly finding last changed entities but it certainly helps while editing in code.

Dick

Debugging in Visual Studio

Posted: Tue Feb 13, 2018 2:49 pm
by wriedmann
Hi Chris,

my longest VO module has nearly 13.000 lines of handwritten code, and the real "monstrum" in my VO repo is the bBrowser (Control) module with about 37.000 lines of code.

But file based editing makes it difficult to navigate in such sources, if you don't use something to collapse.

Wolfgang

Debugging in Visual Studio

Posted: Tue Feb 13, 2018 2:52 pm
by ic2
Hello Chris,

Honestly, I don't miss the repo even with such a structure, just got used to navigating in a different way and it feels good to me now.

That's the square wheel story. I recognize that from some other steps backward (often technology driven) I've encountered the last few years.

For me a good reason to keep using VO longer, and only use X# if the job can be done better in .Net. Unfortunately that is often not the case. For example: we've tried several different OCR solutions in .Net and none of them work as accurate (and fast) as the VO one based on an old Office version.

I am sure that if the client would 'take it' he would eventually get used to longer waiting times and manually changing unrecognized content. But just letting him work with the VO solution seems a better plan to me.

Dick

Debugging in Visual Studio

Posted: Tue Feb 13, 2018 2:58 pm
by Chris
Hi Wolfgang,
Wolfgang Riedmann wrote: But file based editing makes it difficult to navigate in such sources, if you don't use something to collapse.
Well, since you are using XIDE:

Alt+C opens the classes navigation combobox, you can quickly select class
Alt+G opens the entities navigation combo, to quickly navigate to entity
Alt+Up goes to the previous entity, Alt+Down to the next

I am sure VS has similar keys or you can assign the ones you want.

Additionally I use CTRL+G in XIDE a lot, to quickly navigate. (not to mention the code explorer if you want to use it)

It really has become faster for me to navigate in my file based X# apps, than it ever was navigating in the repo in my VO development days...I did not expect this to be the case, but it turned out to be that way!

Chris

Debugging in Visual Studio

Posted: Tue Feb 13, 2018 3:10 pm
by Chris
Hi Dick,
Dick wrote: That's the square wheel story. I recognize that from some other steps backward (often technology driven) I've encountered the last few years.
Not for me, as I explained to you earlier, it's no square wheel to me, it's a different perfectly working wheel with lots more capabilities and features, just needs to be fitted differently than VO's one.

Trust me, I am the kind of person who if I felt dotNet was slowing me down or making me less productive or anything like that, I would had abandoned it many years ago. I hate smartphones because I cannot put them in my pocket as I can do with my regular 9cm cell phone, so this is what I still use :)

About the OCR tool, yes, if the one you found did not do the job well enough for you, then no point using it, I would also use what works well for me. Not absolutely everything works better in .Net, but most things do IMO. Btw, have you tried other alternatives? I'd be very surprised if nobody has created another good enough solution..

Chris

Debugging in Visual Studio

Posted: Tue Feb 13, 2018 5:18 pm
by ic2
Hi Chris,

Sorry to bother you again with this - a few messages back I gave a sample (to Nick) of how I can quickly find back to different methods I lasted edited and edit those in one vertical split window in VO.

As I know how you experienced VS /.Net could you maybe explain me how you do this efficiently in a file based environment? And even more productive? Note that the 2 methods are in different places in the .prg or .cs.

For me this is really a kind of "show stopper". The only alternative in VS I see is opening a 2nd VS in my 2nd monitor to see the called method, but this has proven to give other problems if I edit in both. And it remains a workaround solving only part of the problem.

About the smartphone: I agree with you too. I mainly use my smartphone only regularly in holidays where it provides navigation, plays some music, can display some documents and provide Wifi from a local SIM to my tablet laptop. And sometimes I use it even for calling or other messaging. At home, everything of this list I can do faster or easier with Pc, fixed line phone, built in car navigation etc.

About OCR: our trainee has tried 5 different OCR solutions, the last one from Syncfusion based on the Google’s Tesseract Optical Character Recognition engine. None of them worked very well and all worked slowly. Maybe if we investigate further we find a solution which actually does work.

Dick