Here we discuss problems and solutions with VbClassic's Integrated Development Environment (IDE). ---- '''Issues''' '''IDE:''' * Possibly the world's worst IDE. Having to close and re-open your project just to unregister DLLs is ... there aren't words. * The references dialog. What were they thinking?!? * No I '''do not''' want to search for my project in Source Safe. * How do I open an arbitrary text file? Why do I have to ask? * Cannot even support copy and paste operations of code added to a command button or other object. Try this little trick: Add a button, add code to the click event. Copy and paste the button. Look MA: No Code. Now delete the old button, double click on the form Look MA: Your old code is still there. * I don't want to use your !@#$% text editor. I want to use mine. The VC++ IDE has no problem with that - why does VB? * It won't let you save changes that you make while debugging. When it crashes (see below) you lose all of your changes -- Thanks. * The system changes the capitalization of all your variables when you change their declaration. This is real cute ... when it's stable and does not insist on the wrong capitalization permanently. ---- '''Solutions and Discussion''' * Possibly the world's worst IDE. Having to close and re-open your project just to unregister DLLs is ... there aren't words. ''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.'' ---- * The references dialog. What were they thinking?!? ''What is wrong with it? It so simple. We like it. It''s 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 ---- * How do I open an arbitrary text file? Why do I have to ask? ''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'' ---- * No I '''do not''' want to search for my project in Source Safe. ''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.'' ---- * I don't want to use your !@#$% text editor. I want to use mine. The VC++ IDE has no problem with that - why does VB? ''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.'' ---- * It won't let you save changes that you make while debugging. When it crashes (see above), you lose all of your changes. Thanks. ''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. ---- * Cannot even support copy and paste operations of code added to a command button or other object. Try this little trick: Add a button, add code to the click event. Copy and paste the button. Look MA: No Code. Now delete the old button, double click on the form Look MA: Your old code is still there. ''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 ---- * It fills the registry full of junk GUIDs that you have to muck out one by one with RegEdit. ''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