Porting legacy PB code to the .NET era might require major refactoring, to get the work done properly. Our code, for instance, has some pre-userobject leftovers, as well as deprecated features such as MDI, PBNI etc. I'm wondering how much help will we get from the VS shell when it comes to refactoring capabilities - breaking long functions into separate ones, finding all callers of a certain function or event etc.
The classic IDE is horrible for such tasks. Has using VS now made them easier?
The answers to your questions are YES for the most part but not as cool as in Visual Studio. The PB IDE is night and day better than it was just not quite up to the full Visual Studio IDE.
PB does have some basic refactoring built in, for example something like a function rename across the entire project can be done easily. Here is the output generated when I renamed a function in one of my projects. And I had one of the files opened, the Visual Studio Shell detected it and asked me to reload the local file.
Replace all "ConnectDB", "DBConnect", Subfolders, Find Results 1, "Entire Solution"
H:\Dev\PBWS\pb_data.pbl\pb_data.sra(42,18):liRtn = gnv_data.DBConnect()
H:\Dev\PBWS\pb_data.pbl\n_data_factory.sru(29,25):public function integer DBConnect ()
H:\Dev\PBWS\pb_data.pbl\n_data_factory.sru(38,14):liRowCount = DBConnect()
H:\Dev\PBWS\pb_data.pbl\n_data_factory.sru(103,25):public function integer DBConnect ();
Total replaced: 4 Matching files: 2 Total files searched: 13
PowerBuilder 12.5.NET does have "Go To --> Definition" ability for jumping to function/class declarations. It isn't as cool as Visual Studio in that the PowerBuilder functions aren't as "open" as the .NET framework so you can't right click on GetItemString function and expect to see the internal declarations.
I haven't seen any impact analysis type features yet, like the ability to see where your functions are being called, but I haven't looked too hard yet.
On a positive note Sybase has incorporated the awesome intellisense / code completion of Visual Studio. It is responsive, accurate, and predictive much like when working in Visual Studio IDE doing C#. The PB.NET features along with nice stuff from Visual Studio Shell make PB development fun to work with again.
Related
I have a VS 2013 solution with one VB.NET ASP.NET project which references several c# class library projects (not DLLs) within the same solution. I made lots of changes to logic within some of the method overloads in one of the c# projects. Since the VB.NET project uses these overloads extensively, I want to see how many places these methods are referenced. I go to the c# project that contains the changes, right-click the overload I want, and select Find All References, but it only shows me the references in the c# projects. However, when I go to one of those methods in the VB.NET project, it finds all the references within the VB.NET project as well as the method declarations in the c# project.
I could do a solution-wide text search for the method name, but this method name is used multiple times because it's overloaded. Therefore, I want to search for a particular overloaded method signature, not the method name.
Is this a known shortcoming of VS 2013? Something else I've also noticed that I've noticed is that selecting Go To Reference from within a VB.NET project on a method that's declared in a c# project will take you to the object browser rather than directly to the method definition in the source project itself.
This is an old problem, there are many bug feedback reports for it on Microsoft's feedback site. The canonical one is probably this one. Quoting Dustin Campbell's response:
The general problem is that C# and Visual Basic do not share any common infrastructure with regard to the symbol tables that are used for features like Find All References, Go to Definition or Rename. So, such features don't work between multiple languages. That said, we are looking at ways to change this in the future, but the work required is very substantial.
Annotating a bit, the C# and VB.NET IDEs look similar at the surface but they are very different under the hood. Part of that is them being supported by distinct groups within Microsoft, a survival strategy for any software company, big groups don't work. But above all history plays a strong role in this, Visual Basic had strong IDE support for a very long time. They did not throw away that work when they moved to VB.NET, not in the least because they had to support all previous IDE features so not to alienate their existing customer base. The C# team got a fresh start without that baggage, they started from scratch. Inevitably the internals between them, like the IntelliSense symbol tables, are drastically different.
Tackling the "common infrastructure" problem was not forgotten, the Roslyn project was the instrumental step. It took a very long time to get finished but it is ready to go today. Integrated into VS2015. Whether it actually solves this problem is something I don't know yet, I will in a couple of months. Maybe somebody that has the RC version can confirm. They did create two versions of Roslyn, one for C# and another for VB.NET. Uh-oh.
I am working on a nodejs project in which all code is written in typescript. It follows a microservice pattern (and each microservice is an independent project) hence lot of projects needs to be opened and debugged at the same time.
I tried webstorm and visual studio (with NTVS) but not satisified with both of them. Webstorm ignores many build errors (very important as those will fail during CI) and not as good as visual studio in intellisense and ease of use. On the other hand, Visualstudio is not as fast as I want. Also I am tied to windows and the filename length problem in node_modules is very frequent and annoying.
Others (atom, VSCode) doesn't have typescript debug support (or am I missing something?).
Can you please share your experience? Also I was wondering which editor google developers might be using to develop angular 2 :)
I have been working on a TypeScript project for 1.5 years now and am quite happy with using Visual Studio because we used .NET for back-end stuffs. For myself I consider the speed as "Ok", it is not that good - but the other stuffs e.g. intellisense is what we really like. I also personally think that as a "son" of Microsoft, TypeScript will get the best support from its "cousin" - Visual Studio.
However if you are a Eclipse person, you may be interested in this TypEcs (http://typecsdev.com/). There was also a post by Steve Fenton talking about TypeScript IDEs you may be interested (https://www.stevefenton.co.uk/Content/Blog/Date/201409/Blog/Which-TypeScript-IDE/), he listed a few of the popular ones with a few sentences of comments, including Atom and the atom-typescript extension.
A bit late to the conversation.
I recently tried VisualStudio 2015, VisualStudio Code 0.9, Atom (with Atom-Typescript package). And quite comfortable with Atom.
Atom-TypeScript uses the latest version of TypeScript so you can use all new features like async/await, string interpolation etc. The package created by community so we don't need to wait for major IDE release to use new TypeScript features.
For debugging couldn't find one. But love to use node-inspector for its light weight. The problem is you need to debug it in javascript version not in typescript version. Not so sure but maybe if you can provide map file you can debug the typescript version? like we have on Google Chrome Inspector.
VSCode can debug in Node. No browser debugging yet.
Not a recommendation, but I suggest you do not buy JetBrains' products (IntelliJ/WebStorm/ReSharper) for TypeScript editing unless you have evaluated them properly.
They reused a lot of their own logic for other languages instead of taking full benefit of the TypeScript language service, which means they behave more like a fancy JavaScript editor that can make some clever guesses as opposed to a robust IDE for a statically typed langauge. (Their type inference is different from the compiler and may fool you into believing an untyped expression (implicit any) is well-typed. Also, all the refactoring are the same as the JS ones, so they do not use or preserve any type information. No type-information-based refactoring (like safe renaming and moving) are available either.)
As for debugging, you may have more milage debugging the generated JS. Not only is it well supported, it also reveals problems that occur in compiler-inserted code. The latter would be otherwise difficult to understand if you're only looking at the TypeScript source. Also, in the generated code, you can actually set break points in single line lambda function bodies.
I too use Visual Studio. I haven't had any problem with its speed; I find everything is as immediate as I expect it too.
However, I haven't been using "TypeScript" projects. I have been using generic "Web" projects with TypeScript files. Plus, I don't use Visual Studio's own building and compilation facilities; I use my own Gulp tasks for my project (including rebuilding, watching for saves, minification, testing, etc), and Task Runner Explorer to manage/run them from inside Visual Studio. I think it's the best of both worlds: the snappiness and features of Visual Studio, and the flexibility of running my own custom tasks independent of platform.
I have to admit I don't do any deep debugging (e.g. breakpoints, stepping) from the IDE. Does VS do that with TypeScript? If I catch an error during execution (in the browser), I always have my source maps indicating where the error is, so I go back to the code, attempt to fix it, save, and reload in the browser.
I am using VSCode to actively debug an angular/node/typescript application. It does work, but you will need to do some setup/configuration. You must tell VSCode how to debug your applications. For instance I have multiple options in my launch.json configuration to debug my gulp scripts, my node server.js file, and the angular/typescript application via chrome using the "Debugger for Chrome" extension installed in VSCode. It is all possible with some configuration. Finally, depending on your exact situation you may need to have and correctly configure the map files for your project from javascript to typescript.
I also had the problem of file paths too long in the node_modules folder in visual studio when opening a project with npm. This is due to Visual Studio trying to download all your packages - incorrectly so I might add. The only way to avoid this for my project was to mark the node_modules folder as a hidden folder in windows (top level only).
The problem: My syntax highlighting and IntelliSense are broken. I have a C++ source file like this:
#include "stdafx.hpp"
#ifdef SOMETHING
do_some_stuff;
#endif
where stdafx.hpp (the precompiled header for the project) includes a .h file that says:
#ifdef DEFINE_SOMETHING
#define SOMETHING
#endif
and DEFINE_SOMETHING is defined in the project properties for the project (under C++ / Preprocessor).
Visual Studio is losing track, and displaying do_some_stuff; (which is actually lots of lines of code) in plain grey - I have neither syntax colouring nor IntelliSense.
The question: How can I either make Visual Studio get this right (unlikely) or switch off the fact that it's greying-out code that it thinks is #ifdef'd out?
(Rearranging the code is not an option - it's a large and complex system whose files are built in various environments, Visual Studio being only one of them. I'm using Visual Studio 2005, but I'd be interested to know whether this is fixed or workaroundable in a later version.)
If someone still interested - to turn off graying out #ifdef:
Go to Tools -> Options
Open Text Editor -> C/C++ -> Formatting
Uncheck Colorize inactive code blocks in a different color
In VS19, it's Tools / Options / Text Editor / C/C++ / View / Inactive Code / Show Inactive Blocks.
Following previous answer of aousov I check my VSCode and found this setting:
C_Cpp: Dim Inactive Regions
Controls whether inactive preprocessor blocks are colored differently than active code. This setting has no effect if IntelliSense is disabled or if using the Default High Contrast theme.
in Extensions / C/C++
This may be related to the version you are using (in my case 1.46.1).
Best,
Geoffroy
The problem you describe is par for the course in VS 2005. It is fixed in Visual Studio 2010 and later due to the completely redesigned Intellisense system. This is not directly applicable to your problem, but here's some info on the underlying architecture: http://blogs.msdn.com/b/vcblog/archive/2009/05/27/rebuilding-intellisense.aspx
There are some things you could try, and some project structure changes that can help minimize the problem's frequency, but whatever you do will be hit or miss, and the problem will eventually resurface again regardless. The only real solution is to use a newer IDE.
You can continue to use the VS 2005 build tools by installing VS 2010 along with Daffodil (http://daffodil.codeplex.com), then build your projects with the v80 platform toolset in VS 2010. This makes the migration fairly straightforward, with no need for any source code changes.
Since #define SOMETHING is defined inside stdafx.hpp, indicating that it's always defined since DEFINE_SOMETHING is defined in project configuration, would it be out of the question to also define SOMETHING explicitly in project configuration?
I used to have similar issues in VS2005 and 2008, and redundant explicit definitions sometimes helped.
I fixed this (in VSCode) by changing C_Cpp.default.intelliSenseMode
"C_Cpp.default.intelliSenseMode": "windows-gcc-x64"
I am building an ARM project on a micro-controller. Its not 64 bit either. But this does parse the directives correctly.
For Science I tried Widows-gcc-ARM and that also correctly lit up the regions that are truly active. I also know for a fact that gcc is setup and configured on my windows machine, and while I have clang and msvc, I dont use them and dont know that they work- so it could be why gcc works better for me.
You can experiment with this setting, but I am fairly certain the resolution resides in this option.
I do not know the equivalent VS option, I am sorry.
Is it possible and if so how, to make Visual Studio highlight dynamic expressions in code?
When I just hovered above some code, visual studio told me it was a dynamic expression. This made me realize I made a mistake in my code and used one dynamic too many. But I also realized that if I had not hovered, a 'huge swath' of dynamic code that was supposed to be static would have escaped.
So I wondered if it is possible to make Visual Studio change the background color of dynamic expressions, so those pieces will be clearly recognizable.
[edit]
With dynamic expressions I mean the use of the dynamic keyword in regular code.
You would need an Extension. You can create your own, but I would suggest getting pre-built ones.
Visual Studio has a lot of extensions lately, because of it's popularity.
There are many options I could suggest, but many are rather buggy, so I would suggest using one of the safer, more well known ones like Resharper (my all time favorite and that of many others as well)
I also like JustCode.
There are so many others available though, and if you want to find them, cruise down the Visual Studio Gallery like Morvader said.
Visual Studio Gallery
EDIT:
2 notes I forgot to mention:
Dynamic Intellisense is included in Resharper
Dynamic Highlighting is included as well. If you want to modify the color from the default light blue you can go to Tools->Options...->Environments->Fonts and Colors->Display items->ReSharper Late Bound Identifier
Also make sure that in Resharper->Options...->Code Inspection->Settings "Enable code analysis" and "Color identifiers" are checked.
I am trying to figure out what the browse information (.sbr files) is used for but find only references how to create it. So what is it for?
Thanks
Dima
Read here (Visual C++ Team Blog: IntelliSense History, Part 1)
Capturing information about a C or C++
program’s structure has been around
for a very long time in Microsoft’s
products. Preceding even Visual C++
1.0, the compiler supported generating program information through .SBR and
.BSC files. (Note: The compiler in
Visual C++ 1.0 was already version 8,
so the command line tools had been
around a while already.) The SBR
files contain reference and definition
information for a single translation
unit that the compiler generates as it
compiles. These SBR files are
combined in a later step using the
BSCMAKE tool to generate a BSC file.
This file can then be used to look at
many different aspects of a program:
reference, definitions, caller-callee
graphs, macros, etc.
.sbr is pretty much Visual Studio's ctags - an index of symbols with backreferences to the source. When available, it's used by "Find Symbol" and other similar tools. It's more accurate than the built-in VS parser, because C++ can be tricky, and the real compiler can do a better job (though that is not quite true in VS2010 anymore).
At one time browse info drove the "Go to definition" engine, but that has been reworked in later version of Visual C++. Some third-party tools still use browse info (can't remember for sure, but I think one of Rational's tools does) to cross-reference code.
I always disable it, to shorten build times.