Vb Classic Ide Issues

Here we discuss problems and solutions with VbClassic's Integrated Development Environment (IDE).


Issues

IDE:


Solutions and Discussion

Even the most adamant Visual C++ people claim that the VB IDE is very good and have adopted its features like IntelliSense, etc. With VB6, you can register your DLL and also run another test project within the same session of the IDE without starting another IDE. If you are referring to not being able to recompile an interface while another project has a project reference to it, what would you suggest as an alternative? Perhaps you would rather be able to overwrite type libraries and interfaces that other projects are bound to. Of course, this would cause your project references to be corrupt. Do you like to develop corrupt applications? Simply, uncheck the reference, recompile and then recheck it.


What is wrong with it? It so simple. We like it. Its great. It's now even in VC++. You get a list of the Registered Type Libraries and you click one. Is that too hard for you? Tell us what is wrong with it?''

What's wrong with it is real languages let you just say "include" or "import". I have a newsflash for MS: Programmers like to declare their intent as text. That's what programming languages are for. Who are they trying to help by letting us put some declarations in source, but others in a feature of the IDE? -- PCP

If you're that eager to add additional reference manually, just add them into the .vbp file yourself - there's nothing stopping you (except you need to remember or look up the relevant GUIDs). Not that I'd recommend this approach, of course :-) -- JonKale

It keeps losing references. I keep hoping service packs will fix this, but they don't. The larger the project, the worse this gets. It would also be really nice to be able to navigate the source dependencies, which you can do in other languages by following import/include statements, but which are hidden by the references dialog. What is gained by it?

another PilotError?

Again, if it was PilotError, it was one that a whole bunch of experienced MS** engineers and many hours wasted on MSDN couldn't cure. This project was hardly resource starved, and the engineers on it were very into VB. If it helps at all, I suspect that the corruption of references was usually preceded by an IDE crash, though I'm not certain about that.

Even without stability problems, the traceability issue would still make IDE references inconvenient. Perhaps there are ways around this - if you know of any, please tell - but still VB is one of those tools, like DOS, where the user has to change their way of working to suit the tool, rather than the other way around. -- PM


Project->Add File...->All Files->select the file. If you don't want it treating as executable code, select the Add As Related Document checkbox. Then double-click on it. Easy. Or am I missing something here? -- JonKale


You can avoid this problem by disabling SourceSafe Integration.

Other tools don't require you to disable SCM. Why does VB?

It simply doesn't require SCM. You have to learn the language to prove this true. What does SCM have to do with the language itself?

Okay, I think we're dancing around this one - not one of mine I hasten to add. The problem I experienced was that it was easy for VSS and VB to get out of sync about what was and what was not checked out. If this happened, you ended up fielding a whole lot of modal dialogs while you were trying to fix it. I'm fuzzy on just how this used to occur - perhaps the original contributor of this one will jump in and make it concrete.

Don't check into SS from the VB IDE: It's unreliable. Quit VB and run SS separately. Works much better. I'm told the VSS adaptor for VB has bugs; checkouts work OK, but checkins may or may not work right all the time.

I SecondThat?. I check out in the IDE but always check back in with VSS. Check in vewy vewy cawefuwwy.


Go for it! There are text editors like UltraEdit that recognize VB source. And you can also use Notepad. The source files are ASCII. I can spawn CodeWright from inside VB6 to edit my source code.


No you can't. But you can make changes in the run and save them after. How much code editing are you doing in debug mode? Is this a good practice?

It certainly isn't a good practice in VB. In other languages - Smalltalk for example - it's a very common mode of work to AskTheCode.


We have never seen a need for this but you can do a Control Array or copy and paste the source code in the code window to achieve the same effect. As Enterprise Developers doing mostly Server Side COM, we really don't use Command Buttons. -- AnonymousDonor and Charlie Ferebee

The issue is that VB event handling code is not really connected to the control it services.

JeffGrigg regularly renames controls while refactoring. The names of the event handlers have to be changed, along with all references, or it all breaks. Fortunately, it's trivially easy to do, but the lack of integration within the tool is annoying.

Both renaming of source code when a controls' name is changed, and copying and pasting of components with their associated code are provided by a (free) VB-Addin called MZTools (http://www.mztools.com). It's a 'must have', and solves many of the issues listed on this page. Personally I interact with it as much as I interact with VBs IDE while coding. -- Aaron Cumming


Use the Binary Compatibility option. What you see is the result of using the "No Compatibility" setting.

Begin a COM (or CORBA) project with InterfaceDesign?. Then you freeze the design, and set Binary Compatibility.

We ran with binary compatibility always. I believe the trouble was we were trying to do RefactoringInVisualBasic, so we were changing interfaces on our development machines very regularly indeed. Of course this one isn't a showstopper for doing XP in VB - just an annoyance. I wonder whether a solution would be to only turn on binary compatibility just prior to doing a release? -- PM

When a COM interface is published it is IMMUTABLE. You can't change it.

Set it to Project Compatibility until the interfaces are frozen, then set Binary Compatibility.

Yes, that's just what I was suggesting. We were running with binary compatibility always on because that's what we'd read was standard to do - we should have thought harder. -- PM


CategoryVbClassic


EditText of this page (last edited January 31, 2009) or FindPage with title or text search