Here we discuss problems and solutions with VbClassic's Integrated Development Environment (IDE).
Issues
IDE:
Solutions and Discussion
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
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.
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.
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
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