Thread: RE: [GD-Windows] VC++ lag
Brought to you by:
vexxed72
Menu
▾
▴
gamedevlists-windows
|
From: Gareth L. <GL...@cl...> - 2003-06-12 13:05:27
|
Delete your .opt file, normally solves that. It's checking for dependancies and something go screwed up ( I guess ) > -----Original Message----- > From: Pierre Terdiman [mailto:p.t...@wa...] > Sent: 12 June 2003 23:04 > To: gam...@li... > Subject: [GD-Windows] VC++ lag > > > Hi, > > Is there any particular reason why VC++ should lag like hell > before starting > compiling ? The scenario is : > - W2K / VC++ 6 / SP5 / brand new machine > - I press F5 or F7 to compile > - Between 30 and 60 seconds later compilation actually starts > (before, VC++ > just doesn't respond) > > It doesn't happen all the time. This is extremely annoying, > especially when > it stops 1 second after compilation has started, to report a > missing ";" > ....... > > Another question while I'm at it : > > I use a "subst" command to create a virtual drive where my > project lies, say > "Y:". This maps a real location somewhere on the D: drive (at > work), or > somewhere on C: (at home). Using a virtual drive allows me to use some > hardcoded paths in various places. > > Usually, when I select a file in VC++ (the source tree on the > left), it > opens "Y:\SomeDir\SomeFile.cpp", which is what I want. > However, *sometimes* > it decides to open "C:\RealLocation\SomeDir\SomeFile.cpp" > instead, i.e. it > uses the real path. The trouble is, of course, when I use the backuped > project on the other machine, it doesn't find the file > anymore (since it's > now on D:), and the usual message box pops up to say that VC > has been unable > to re-open some of the project files. > > I'd like to know why it sometimes feels like using the real path names > instead of subst'ed ones. > > Pierre > > > > > ------------------------------------------------------- > This SF.NET email is sponsored by: eBay > Great deals on office technology -- on eBay now! Click here: > http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5 > _______________________________________________ > Gamedevlists-windows mailing list > Gam...@li... > https://lists.sourceforge.net/lists/listinfo/gamedevlists-windows > Archives: > http://sourceforge.net/mailarchive/forum.php?forum_id=555 > |
|
From: Neil S. <ne...@st...> - 2003-06-12 13:15:58
|
There is usually still a lag even with no .opt file (checking dependencies as Gareth says), but it's nowhere near as bad as it is when the .opt file gets into that 'treacle' state. On occasion, I've seen it actually take so long that it was faster to quit devstudio, delete the .opt and start again. The .ncb file is another pest. When it gets in a mess, you might get a warning about missing ClassWizard information every time you load the workspace. Deleting it also fixes the problem. - Neil. -----Original Message----- From: gam...@li... [mailto:gam...@li...] On Behalf Of Gareth Lewin Sent: 12 June 2003 14:05 To: gam...@li... Subject: RE: [GD-Windows] VC++ lag Delete your .opt file, normally solves that. It's checking for dependancies and something go screwed up ( I guess ) ________________________________________________________________________ This email has been scanned for all viruses by the MessageLabs Email Security System. For more information on a proactive email security service working around the clock, around the globe, visit http://www.messagelabs.com ________________________________________________________________________ |
|
From: Jon W. <hp...@mi...> - 2003-06-12 16:55:06
|
We just create a non-writable zero-size file with that name,=20 which means we don't have to worry about having to delete it=20 (or spend time writing the info :-) all the time. You do get=20 a warning when you open the workspace, but that's allright. What's worse, though, is that we don't seem able to factor=20 our project into DLLs as fast as we grow the project, so we=20 keep hitting the 64 MB limit for single PDB files :-( It's really quite amazing how Microsoft can develop these=20 tools and they just don't scale well. It's all good as long=20 as your project is some 10,000 line report generator, but=20 for a large-scale commercial system, it's really quite lame.=20 Almost makes me wish for the days of GNU make, VIM and=20 CTags... (which we could do, because we generate .dsp and .dsw files=20 out of an abstract project description file that looks a lot=20 like a make file, anyway) Cheers, / h+ > -----Original Message----- > From: gam...@li... > [mailto:gam...@li...]On Behalf Of > Neil Stewart > Sent: Thursday, June 12, 2003 6:20 AM > To: gam...@li... > Subject: RE: [GD-Windows] VC++ lag >=20 >=20 > There is usually still a lag even with no .opt file (checking > dependencies as Gareth says), but it's nowhere near as bad as it is = when > the .opt file gets into that 'treacle' state. On occasion, I've seen = it > actually take so long that it was faster to quit devstudio, delete the > .opt and start again. >=20 > The .ncb file is another pest. When it gets in a mess, you might get a > warning about missing ClassWizard information every time you load the > workspace. Deleting it also fixes the problem. >=20 > - Neil. >=20 >=20 > -----Original Message----- > From: gam...@li... > [mailto:gam...@li...] On Behalf Of > Gareth Lewin > Sent: 12 June 2003 14:05 > To: gam...@li... > Subject: RE: [GD-Windows] VC++ lag >=20 >=20 > Delete your .opt file, normally solves that. It's checking for > dependancies and something go screwed up ( I guess ) >=20 >=20 >=20 > = ________________________________________________________________________ > This email has been scanned for all viruses by the MessageLabs Email > Security System. For more information on a proactive email security > service working around the clock, around the globe, visit > http://www.messagelabs.com > = ________________________________________________________________________ >=20 >=20 > ------------------------------------------------------- > This SF.NET email is sponsored by: eBay > Great deals on office technology -- on eBay now! Click here: > http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5 > _______________________________________________ > Gamedevlists-windows mailing list > Gam...@li... > https://lists.sourceforge.net/lists/listinfo/gamedevlists-windows > Archives: > http://sourceforge.net/mailarchive/forum.php?forum_id=3D555 >=20 |
|
From: brian s. <pud...@po...> - 2003-06-12 18:05:15
|
That's because for MS's large scale projects they don't use workspaces, and they do use something that looks a whole lot like make. It's called NT Build, and you can get it with the DDK. With an external build utility, VC can just be the debugger and you don't have to worry about its internal dependency checker being slow. We use a makefile-type solution here on a much smaller-scale project, and it works great - I would never go back to workspaces for any real project. --brian Jon Watte wrote: >It's really quite amazing how Microsoft can develop these >tools and they just don't scale well. It's all good as long >as your project is some 10,000 line report generator, but >for a large-scale commercial system, it's really quite lame. >Almost makes me wish for the days of GNU make, VIM and >CTags... > >(which we could do, because we generate .dsp and .dsw files >out of an abstract project description file that looks a lot >like a make file, anyway) > > |
|
From: Neil S. <ne...@st...> - 2003-06-12 13:25:37
|
Actually, thinking about it, isn't it the .ncb that causes both these problems? I haven't used VC6 for a few months now, so I'm not absolutely sure. - Neil. -----Original Message----- From: gam...@li... [mailto:gam...@li...] On Behalf Of Neil Stewart Sent: 12 June 2003 14:20 To: gam...@li... Subject: RE: [GD-Windows] VC++ lag There is usually still a lag even with no .opt file (checking dependencies as Gareth says), but it's nowhere near as bad as it is when the .opt file gets into that 'treacle' state. On occasion, I've seen it actually take so long that it was faster to quit devstudio, delete the .opt and start again. The .ncb file is another pest. When it gets in a mess, you might get a warning about missing ClassWizard information every time you load the workspace. Deleting it also fixes the problem. - Neil. ________________________________________________________________________ This email has been scanned for all viruses by the MessageLabs Email Security System. For more information on a proactive email security service working around the clock, around the globe, visit http://www.messagelabs.com ________________________________________________________________________ |
|
From: Javier A. <ja...@py...> - 2003-06-12 14:07:45
|
The screwed up .opt is definitely guilty for the long delays before compilation. Neil Stewart wrote: > Actually, thinking about it, isn't it the .ncb that causes both these > problems? I haven't used VC6 for a few months now, so I'm not > absolutely sure. Javier Arevalo Pyro Studios |
|
From: Gareth L. <GL...@cl...> - 2003-06-12 16:03:59
|
> > Delete your .opt file, normally solves that. It's checking for > dependancies > > and something go screwed up ( I guess ) > > Sigh.... Unfortunately I'd like to keep that one alive, as it's where > currently open files are stored (I think). I like to keep > some files open > from day to day (the files I'm currently working on). Anyway > I guess I'll > give it a try. Don't delete it every day, just when you have problems :) > >Do you use VisualAssist, or anyother kind of VC++ pluggin ? > > No. Poor you, Visual Assist is teh bawmb > > >Do you have workspaces that contains a lot of subprojects, with the > >mainproject having all other projects considered as > dependancies of the > main > >? > > Yes. > Will be slow. |
|
From: Neil S. <ne...@st...> - 2003-06-12 16:27:56
|
> Poor you, Visual Assist is teh bawmb Especially when combined with Workspace Whiz. :) Actually, Pierre, with Workspace Whiz, you probably wouldn't care about maintaining open files any more, because it lets you find any file very quickly. You have to see it to believe it... - Neil. ________________________________________________________________________ This email has been scanned for all viruses by the MessageLabs Email Security System. For more information on a proactive email security service working around the clock, around the globe, visit http://www.messagelabs.com ________________________________________________________________________ |
|
From: Rich <leg...@xm...> - 2003-06-12 17:01:04
|
In article <E0458FD1573AD511A3A9000102984013794CE6@STEELSERVER>,
"Neil Stewart" <ne...@st...> writes:
> There is usually still a lag even with no .opt file (checking
> dependencies as Gareth says), but it's nowhere near as bad as it is when
> the .opt file gets into that 'treacle' state. On occasion, I've seen it
> actually take so long that it was faster to quit devstudio, delete the
> .opt and start again.
You don't need to quit dev studio, just close the workspace.
In fact, if this is annoying you often (the NCB thing was bugging me
for a while), you can create a macro that:
1) gets the current workspace filename
2) closes the current workspace
3) locates the corresponding .opt/.ncb file
4) deletes the .opt/.ncb file
5) opens the workspace again
I did this for the NCB annoyance and it was the fastest way to deal
with it.
--
"The Direct3D Graphics Pipeline"-- code samples, sample chapter, FAQ:
<http://www.xmission.com/~legalize/book/>
izfree: Open source tools for Windows Installer
<http://izfree.sourceforge.net>
|
|
From: Neil S. <ne...@r0...> - 2003-06-13 01:17:15
|
> > You don't need to quit dev studio, just close the workspace. > When I said close devstudio, I meant kill the process. In some instances, it was taking so long to do anything that it was faster to kill it, delete the .opt and start devstudio again, than wait for it to finish (or even start) building and close the workspace. Besides, when it went funny, it usually took ages to close the workspace as well. > In fact, if this is annoying you often (the NCB thing was bugging me > for a while), you can create a macro that: > This wouldn't have helped much in the cases I was seeing. It sounds as if you were getting slightly different behaviour than I was though, so maybe it affects everyone in different ways, all of them painful. The best solution I found was to switch to VC7, using Joshua Jensen's FastSolutionBuild plug-in. Maybe not the cheapest fix, though. ;) - Neil. |
|
From: Rich <leg...@xm...> - 2003-06-12 17:02:03
|
In article <00bf01c330fb$644146f0$8c00a8c0@Pierre>,
"Pierre Terdiman" <p.t...@wa...> writes:
> Sigh.... Unfortunately I'd like to keep that one alive, as it's where
> currently open files are stored (I think). I like to keep some files open
> from day to day (the files I'm currently working on). Anyway I guess I'll
> give it a try.
You can make a copy of a known good .opt file and then replace the bad
.opt file with the copy when things get hosed.
--
"The Direct3D Graphics Pipeline"-- code samples, sample chapter, FAQ:
<http://www.xmission.com/~legalize/book/>
izfree: Open source tools for Windows Installer
<http://izfree.sourceforge.net>
|
|
From: Rich <leg...@xm...> - 2003-06-12 17:03:07
|
In article <013e01c330fe$d4122050$f40aa8c0@mike>,
"Mickael Pointier" <mpo...@ed...> writes:
> >> Do you have workspaces that contains a lot of subprojects, with the
> >> mainproject having all other projects considered as dependancies of
> >> the main ?
> >
> > Yes.
>
> Ok.
>
> Each time I have a workspace with this kind of situation the first build of
> the complex project after loading visual is always slow. [...]
You can speed it up by unloading projects you know haven't changed and
don't need to be rebuilt. VC6 won't do any timestamp checking for
projects that aren't loaded.
--
"The Direct3D Graphics Pipeline"-- code samples, sample chapter, FAQ:
<http://www.xmission.com/~legalize/book/>
izfree: Open source tools for Windows Installer
<http://izfree.sourceforge.net>
|
|
From: Rich <leg...@xm...> - 2003-06-12 17:09:34
|
In article <HEE...@mi...>,
"Jon Watte" <hp...@mi...> writes:
> It's really quite amazing how Microsoft can develop these=20
> tools and they just don't scale well.
....but VC6 has been deprecated for almost 2 years.
Personally I haven't run into the limits you describe. We used VC6 to
build a large (>50) number of projects and DLLs and didn't have
problems.
--
"The Direct3D Graphics Pipeline"-- code samples, sample chapter, FAQ:
<http://www.xmission.com/~legalize/book/>
izfree: Open source tools for Windows Installer
<http://izfree.sourceforge.net>
|
|
From: Jon W. <hp...@mi...> - 2003-06-12 17:41:23
|
> > It's really quite amazing how Microsoft can develop these=3D20 > > tools and they just don't scale well. >=20 > ....but VC6 has been deprecated for almost 2 years. >=20 > Personally I haven't run into the limits you describe. We used VC6 to > build a large (>50) number of projects and DLLs and didn't have > problems. Ah, to be developing on a product small enough to only need=20 50 projects again :-) Cheers, / h+ |
|
From: Gareth L. <GL...@cl...> - 2003-06-12 17:10:57
|
Since VAssist added "OpenProjectFile" Workspace Whiz became redundant to me. > -----Original Message----- > From: Neil Stewart [mailto:ne...@st...] > Sent: 12 June 2003 17:32 > To: gam...@li... > Subject: RE: [GD-Windows] VC++ lag > > > > > Poor you, Visual Assist is teh bawmb > > Especially when combined with Workspace Whiz. :) > > Actually, Pierre, with Workspace Whiz, you probably wouldn't > care about > maintaining open files any more, because it lets you find any > file very > quickly. You have to see it to believe it... > > - Neil. > > > ______________________________________________________________ > __________ > This email has been scanned for all viruses by the MessageLabs Email > Security System. For more information on a proactive email security > service working around the clock, around the globe, visit > http://www.messagelabs.com > ______________________________________________________________ > __________ > > > ------------------------------------------------------- > This SF.NET email is sponsored by: eBay > Great deals on office technology -- on eBay now! Click here: > http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5 > _______________________________________________ > Gamedevlists-windows mailing list > Gam...@li... > https://lists.sourceforge.net/lists/listinfo/gamedevlists-windows > Archives: > http://sourceforge.net/mailarchive/forum.php?forum_id=555 > |
|
From: Neil S. <ne...@st...> - 2003-06-12 17:22:46
|
Didn't even notice that until you mentioned it. :) Mind you, it's not nearly as good as the WWhiz one. In fact, it's a wee bit cheap-looking, and you can't use it to get at system includes. - Neil. -----Original Message----- From: gam...@li... [mailto:gam...@li...] On Behalf Of Gareth Lewin Sent: 12 June 2003 18:11 To: gam...@li... Subject: RE: [GD-Windows] VC++ lag Since VAssist added "OpenProjectFile" Workspace Whiz became redundant to me. ________________________________________________________________________ This email has been scanned for all viruses by the MessageLabs Email Security System. For more information on a proactive email security service working around the clock, around the globe, visit http://www.messagelabs.com ________________________________________________________________________ |
|
From: Rich <leg...@xm...> - 2003-06-12 19:24:43
|
In article <3EE...@po...>,
brian sharon <pud...@po...> writes:
> We use a makefile-type solution here on a much smaller-scale project,
> and it works great - I would never go back to workspaces for any real
> project.
To each his own. I've used makefiles for decades. I can use them
when I have to, either because workspaces fall short or I need
something really funky that can't be done with custom build steps,
etc.
FWIW, the VC team has committed to making the workspace/solution
approach scale better with less "lag" when compared to a makefile
based approach. They are trying to get to a situation where they are
"eating their own dog food" so to speak. I hear that VS.NET 2003 is
better in this regard, but I haven't tried it yet.
--
"The Direct3D Graphics Pipeline"-- code samples, sample chapter, FAQ:
<http://www.xmission.com/~legalize/book/>
izfree: Open source tools for Windows Installer
<http://izfree.sourceforge.net>
|
|
From: David N. <dno...@mi...> - 2003-06-12 20:05:12
|
If you guys can provide a list things where vs can improve (from its latest version), with arguments such as (X sucks because this, this and that. Blah doesn't work in this situation), I'll be happy to forward your list of petitions to the VS team. David -----Original Message----- From: gam...@li... [mailto:gam...@li...] On Behalf Of brian sharon Sent: Thursday, June 12, 2003 11:04 AM To: gam...@li... Subject: Re: [GD-Windows] VC++ lag That's because for MS's large scale projects they don't use workspaces,=20 and they do use something that looks a whole lot like make. It's called NT Build, and you can get it with the DDK. With an external build=20 utility, VC can just be the debugger and you don't have to worry about=20 its internal dependency checker being slow. We use a makefile-type solution here on a much smaller-scale project,=20 and it works great - I would never go back to workspaces for any real=20 project. --brian Jon Watte wrote: >It's really quite amazing how Microsoft can develop these=20 >tools and they just don't scale well. It's all good as long=20 >as your project is some 10,000 line report generator, but=20 >for a large-scale commercial system, it's really quite lame.=20 >Almost makes me wish for the days of GNU make, VIM and=20 >CTags... > >(which we could do, because we generate .dsp and .dsw files=20 >out of an abstract project description file that looks a lot=20 >like a make file, anyway) > =20 > ------------------------------------------------------- This SF.NET email is sponsored by: eBay Great deals on office technology -- on eBay now! Click here: http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5 _______________________________________________ Gamedevlists-windows mailing list Gam...@li... https://lists.sourceforge.net/lists/listinfo/gamedevlists-windows Archives: http://sourceforge.net/mailarchive/forum.php?forum_id=3D555 |
|
From: Javier A. <ja...@py...> - 2003-06-13 08:37:14
|
David Notario wrote: > If you guys can provide a list things where vs can improve (from its > latest version), with arguments such as (X sucks because this, this > and that. Blah doesn't work in this situation), I'll be happy to > forward your list of petitions to the VS team. IDE interface only issues: - "VC6" keyboard option that actually includes _most_ VC6 keys instead of a random selection. - Faster build dependency checking for projects, the way we KNOW it can be done. - Avoid polluting the Build Output with "whatever - up-to-date, Build Time 0:00" - Single key for "StartUp Project Settings" just like Alt-F7 used to do. 2003 included a "Project Properties" function that was an improvement over the initial VS, but still not good enough. - Project Settings (or Properties, whatever the fashionable name is this week) dialog must include ability to change project (in addition to doing it externally by clicking the Solution Explorer). - Resizeable dialogs for _all_ dialogs (or does someone over there just love scrollbars and annoyingly small listboxes?) - If above can't be fixed (!?!?!), then at least ensure that ALL listboxes have tooltips and both scrollbars: "My Customize | Commands" select the "Macros" category and check the Commands Listbox. In mine, I can only read "Samples.DevStudio6Editor.****" where **** are the first four or five letters of the _actual_ macro function. - Fix assorted bugs with unusual MSDN installations. - Better search engine for the help (this one is not strictly VS.NET). - Smarter XML parser / editing, current structural limitations are absurd. - Filters for all those listboxes that contain dozens of items. - A way to list keyboard assignments. - "StartUp project" selector listbox for the toolbars, just like the build configuration listbox. Javier Arevalo Pyro Studios |
|
From: Jon W. <hp...@mi...> - 2003-06-13 17:57:16
|
My big gripes: * All options must scale enough to support a monolithic 400-project,=20 5,000,000-line solution. This means things like "auto-complete" and "show arguments" as well as=20 "open solution" or "start re-build". It also means no arbitrary limits=20 to number of files in project, number of files in solution, size of=20 object or debug information files, etc. Some of these were made better=20 in VC7, I grant you, but it ain't done yet. * All settings files need to be text-only, using liberal line feeds, so=20 they can be easily stored and managed and diffed in source control,=20 and/or generated from build setup scripts. It would be nice if they were actually documented, even, but moving=20 away from binary settings files is certainly the first step. We can=20 keep reverse engineering the text files for now :-) A few small gripes: * Open Selected doesn't work. If I select an include in a source file, and use "open selected," I=20 expect the file to be found and opened just like the compiler would=20 find and open it when seeing the same include. Usually, I either get=20 an error about "WBCommand not available" (very paraphrased, I don't=20 have it easily available right now) or a "file not found" error. * Is there a key for go-to-next-Find-In-All-Files-match ? I haven't found it. I don't like reaching for the mouse just to=20 navigate my Find results. "Go to next task" does not do it; it only=20 seems to work for compile errors etc. * Allow copying TEXT out of any window. Compiler errors, disassembly,=20 memory dumps, project settings windows, whatever. * Remote serial or IEEE 1394 kernel level debugging, a la WinDbg.=20 (OK, I can dream, can't I? :-) * Re-sizable properties/settings pages, text boxes, lists, etc. I use Large Fonts. I enter lots of options. The dialogs are very=20 small. * Why doesn't IntelliSense work for OpenGL header files? Cheers, / h+ > -----Original Message----- > From: gam...@li... > [mailto:gam...@li...]On Behalf Of > David Notario > Sent: Thursday, June 12, 2003 1:05 PM > To: gam...@li... > Subject: RE: [GD-Windows] VC++ lag >=20 >=20 > If you guys can provide a list things where vs can improve (from its > latest version), with arguments such as (X sucks because this, this = and > that. Blah doesn't work in this situation), I'll be happy to forward > your list of petitions to the VS team. >=20 > David |
|
From: Parveen K. <pk...@al...> - 2003-06-14 19:58:28
|
On Thu, 2003-06-12 at 13:05, David Notario wrote: > If you guys can provide a list things where vs can improve (from its > latest version), with arguments such as (X sucks because this, this and > that. Blah doesn't work in this situation), I'll be happy to forward > your list of petitions to the VS team. Since no one else has mentioned it. How about partial template specialization sometime soon? I can live with most of the quirks of the IDE. |
|
From: Rich <leg...@xm...> - 2003-06-13 01:50:59
|
In article <003601c33149$dbbe47c0$0100a8c0@r0x0rz>,
"Neil Stewart" <ne...@r0...> writes:
> > In fact, if this is annoying you often (the NCB thing was bugging me
> > for a while), you can create a macro that:
>
> This wouldn't have helped much in the cases I was seeing.
I can't say for certain since I didn't experience what you did :-). I
did experience situations where ClassView gets confused after a while.
Deleting the NCB file fixed that, so I used a macro for it. Sometimes
it would corrupt my .opt file and making a backup copy of a known good
one and recopying that over the corrupted one fixed that problem. I
haven't had such difficulties in VS.NET.
--
"The Direct3D Graphics Pipeline"-- code samples, sample chapter, FAQ:
<http://www.xmission.com/~legalize/book/>
izfree: Open source tools for Windows Installer
<http://izfree.sourceforge.net>
|
|
From: Carsten O. <car...@se...> - 2003-06-13 08:47:30
|
I'd like to mention that I reported several bugs of VS.Net without any response. And hey, in VS.Net 2003, none of these bugs was fixed. Please note that although we have many issues with VS.Net, it's still much better than using GCC and EMacs ;-) But it's definately a step back from VC6, which worked much faster and more reliable. I'd switch back to 6 if it wasn't for the better compiler (I know there's a way to use the v7 compiler with the v6 GUI, but that's awkward to me). Fav list: - Properties window sucks, part I Have a workspace with >50 files in it. In Solution Explorer, double click one of the last files in the list so that the project tree item is scrolled out of view. Now scroll up the tree, right click the project tree item (one level below the root solutiom item), select "Properties...". The properties window opens with the settings of the project, then the tree scrolls back to the active (opened) file, therefor the project items goes out of view and the properties window switches to the settings for the file automatically. This is sooo annoying... - Properties window sucks, part II There seems to be no way to use the standard TAB way to step through the single controls of the properties window. - Path case oddness sucks VS seemingly doesn't care at all for the caseness of project paths. We usually change the standard "Debug" and "Release" build paths to "dbg" and "rel" (lowercase). But often they end up being "Dbg" and "Rel". No idea why, it's not reproducible. - Toolbars and shortcuts suck Whenever some Add-In updates its toolbar (namely VAssist), _all_ toolbars are reset to defaults. This is particularily annoying since I drag the few buttons I actually need into the menu bar and disable all other toolbars. Keyboard settings are busted, too. This is much worse that the reset toolbars. - SCM integration sucks VS creates (why at all?) *.vssscc files and checks them out at numerous occasions to write them. But they never actually change, hence the check-out is not needed after all. Btw: we're using Perforce, not VSS. - Bitch build sucks Sorry, we couldn't resist renaming that button ;-). The problem is that the list can be sorted by config, name and so on, but you can't multi-select items. Imagine solutions with 10 sub projects and five configs... - VS is unreliable in batch operation When used through the command line with the /build switch and its siblings, after some time VS doesn't do anything. We see this with our build server that launches VS batch jobs and simply stops working after a day or two without error messages generated. - VS commandline messes with GUI Using VS without the GUI from the shell modifies the MRU project list. Very annoying if you got a 20-project "build all tools and libs from scratch" batch file. This can be workarounded by having one GUI-instance of VS open and closing that one after the batch job since VS doesn't handle settings changes in parallel instances that well anyway. - "Clean" sucks The "Clean" operation invariably does not clean the selected project, but all dependencies as well. Why? - Build events suck Has anyone ever thought about having a _list_ of things to do before build? With the current solution, you have to use a batch file for the one event slot you got. This is soooo DOS-ish ;-) - Renaming configs sucks Sometimes renaming a config overwrites its settings with the Release config's ones. Can't tell the exact circumstances (don't do it that often...). - Help sucks part I Although MSDN is configured as external help, pressing F1 often pops up the internal help viewer as well on the first invocation with the not-so-helpful description of the F1 key... - Help sucks part II There seems to be no way to keep all that VB, C#, WinCE and ATL docs out of my pure VCPP/Win32 way. Especially annoying since pressing F1 on any Win32 API either turns up the ATL, MFC or WinCE doc, but never the "normal" SDK page. I'd like to filter that, but there's no way. - Find in Files sucks It simply doesn't work. The results are sometimes obviously wrong. It's also unclear what "All searcheable items" maps to. A single "All applying include and source paths" might do wonders. Best regards, Carsten Orthbandt Founder + Development Director SEK SpieleEntwicklungsKombinat GmbH http://www.sek-ost.de Wenn ich Visionen habe, gehe ich zum Arzt. - Helmut Schmidt > -----Original Message----- > From: David Notario [mailto:dno...@mi...] > Sent: Thursday, June 12, 2003 10:05 PM > To: gam...@li... > Subject: RE: [GD-Windows] VC++ lag >=20 >=20 > If you guys can provide a list things where vs can improve (from its > latest version), with arguments such as (X sucks because=20 > this, this and > that. Blah doesn't work in this situation), I'll be happy to forward > your list of petitions to the VS team. >=20 > David >=20 >=20 >=20 > -----Original Message----- > From: gam...@li... > [mailto:gam...@li...] On Behalf Of > brian sharon > Sent: Thursday, June 12, 2003 11:04 AM > To: gam...@li... > Subject: Re: [GD-Windows] VC++ lag >=20 > That's because for MS's large scale projects they don't use=20 > workspaces,=20 > and they do use something that looks a whole lot like make. =20 > It's called >=20 > NT Build, and you can get it with the DDK. With an external build=20 > utility, VC can just be the debugger and you don't have to=20 > worry about=20 > its internal dependency checker being slow. >=20 > We use a makefile-type solution here on a much smaller-scale project,=20 > and it works great - I would never go back to workspaces for any real=20 > project. >=20 > --brian >=20 > Jon Watte wrote: >=20 > >It's really quite amazing how Microsoft can develop these=20 > >tools and they just don't scale well. It's all good as long=20 > >as your project is some 10,000 line report generator, but=20 > >for a large-scale commercial system, it's really quite lame.=20 > >Almost makes me wish for the days of GNU make, VIM and=20 > >CTags... > > > >(which we could do, because we generate .dsp and .dsw files=20 > >out of an abstract project description file that looks a lot=20 > >like a make file, anyway) > > =20 > > >=20 >=20 >=20 > ------------------------------------------------------- > This SF.NET email is sponsored by: eBay > Great deals on office technology -- on eBay now! Click here: > http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5 > _______________________________________________ > Gamedevlists-windows mailing list > Gam...@li... > https://lists.sourceforge.net/lists/listinfo/gamedevlists-windows > Archives: > http://sourceforge.net/mailarchive/forum.php?forum_id=3D555 >=20 >=20 > ------------------------------------------------------- > This SF.NET email is sponsored by: eBay > Great deals on office technology -- on eBay now! Click here: > http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5 > _______________________________________________ > Gamedevlists-windows mailing list > Gam...@li... > https://lists.sourceforge.net/lists/listinfo/gamedevlists-windows > Archives: > http://sourceforge.net/mailarchive/forum.php?forum_idU5 >=20 |
|
From: Colin F. <cp...@ea...> - 2003-06-13 09:36:31
|
Okay, I'll add my VC.Net comments:
[1] I guess this will only ever happen to any person
once, but it sure is shocking:
Deleting files from the project deletes the source
files themselves!
Yes, a dialog appears saying something about the items
being removed from the project, but it doesn't say that
files will be deleted.
The first time this happened I was doing a temporary test
that involved compiling a second set of source files in
to my application. When I finished the test, I simply
deleted the items from the project. I was horrified
to discover that the files were deleted! That's like
deleting source code when you change a makefile!
[2] I wish there was a way to build a hierarchy of source
folders in the project that mirrored the hierarchy of
directory on the disk drive.
Doing the "Add files..." thing through the GUI is tedious,
and I'd hate to do all of that GUI work over again when
I invent a new scheme for organizing source directories.
I ended up writing a program to read a hierarchy of
source directories and generate the *.vcproj file.
[3] Why is it that my OWN source files, MFC headers,
C-Runtime headers, Win32 headers, etc, all enjoy
the benefits of Intellisense completion -- but
the OpenGL functions don't show up?
[4] I'd really like to copy the disassembly or memory
windows as TEXT.
--- Colin
cp...@ea...
----- Original Message -----
From: "Carsten Orthbandt" <car...@se...>
To: <gam...@li...>
Sent: Friday, June 13, 2003 1:47 AM
Subject: RE: [GD-Windows] VC++ lag
I'd like to mention that I reported several bugs of VS.Net
without any response. And hey, in VS.Net 2003, none of these
bugs was fixed.
Please note that although we have many issues with VS.Net,
it's still much better than using GCC and EMacs ;-) But it's
definately a step back from VC6, which worked much faster and
more reliable. I'd switch back to 6 if it wasn't for the better
compiler (I know there's a way to use the v7 compiler with the
v6 GUI, but that's awkward to me).
Fav list:
- Properties window sucks, part I
Have a workspace with >50 files in it. In Solution Explorer,
double click one of the last files in the list so that the
project tree item is scrolled out of view. Now scroll up the
tree, right click the project tree item (one level below the
root solutiom item), select "Properties...". The properties
window opens with the settings of the project, then the tree
scrolls back to the active (opened) file, therefor the project
items goes out of view and the properties window switches to
the settings for the file automatically. This is sooo annoying...
- Properties window sucks, part II
There seems to be no way to use the standard TAB way to step
through the single controls of the properties window.
- Path case oddness sucks
VS seemingly doesn't care at all for the caseness of project
paths. We usually change the standard "Debug" and "Release"
build paths to "dbg" and "rel" (lowercase). But often they
end up being "Dbg" and "Rel". No idea why, it's not reproducible.
- Toolbars and shortcuts suck
Whenever some Add-In updates its toolbar (namely VAssist), _all_
toolbars are reset to defaults. This is particularily annoying
since I drag the few buttons I actually need into the menu bar
and disable all other toolbars. Keyboard settings are busted,
too. This is much worse that the reset toolbars.
- SCM integration sucks
VS creates (why at all?) *.vssscc files and checks them out at
numerous occasions to write them. But they never actually change,
hence the check-out is not needed after all. Btw: we're using
Perforce, not VSS.
- Bitch build sucks
Sorry, we couldn't resist renaming that button ;-). The problem
is that the list can be sorted by config, name and so on, but
you can't multi-select items. Imagine solutions with 10 sub
projects and five configs...
- VS is unreliable in batch operation
When used through the command line with the /build switch and
its siblings, after some time VS doesn't do anything. We see
this with our build server that launches VS batch jobs and simply
stops working after a day or two without error messages generated.
- VS commandline messes with GUI
Using VS without the GUI from the shell modifies the MRU project
list. Very annoying if you got a 20-project "build all tools and
libs from scratch" batch file. This can be workarounded by having
one GUI-instance of VS open and closing that one after the batch
job since VS doesn't handle settings changes in parallel instances
that well anyway.
- "Clean" sucks
The "Clean" operation invariably does not clean the selected project,
but all dependencies as well. Why?
- Build events suck
Has anyone ever thought about having a _list_ of things to do before
build? With the current solution, you have to use a batch file for
the one event slot you got. This is soooo DOS-ish ;-)
- Renaming configs sucks
Sometimes renaming a config overwrites its settings with the Release
config's ones. Can't tell the exact circumstances (don't do it that
often...).
- Help sucks part I
Although MSDN is configured as external help, pressing F1 often pops
up the internal help viewer as well on the first invocation with the
not-so-helpful description of the F1 key...
- Help sucks part II
There seems to be no way to keep all that VB, C#, WinCE and ATL docs
out of my pure VCPP/Win32 way. Especially annoying since pressing F1
on any Win32 API either turns up the ATL, MFC or WinCE doc, but never
the "normal" SDK page. I'd like to filter that, but there's no way.
- Find in Files sucks
It simply doesn't work. The results are sometimes obviously wrong.
It's also unclear what "All searcheable items" maps to. A single
"All applying include and source paths" might do wonders.
Best regards,
Carsten Orthbandt
Founder + Development Director
SEK SpieleEntwicklungsKombinat GmbH
http://www.sek-ost.de
Wenn ich Visionen habe, gehe ich zum Arzt. - Helmut Schmidt
> -----Original Message-----
> From: David Notario [mailto:dno...@mi...]
> Sent: Thursday, June 12, 2003 10:05 PM
> To: gam...@li...
> Subject: RE: [GD-Windows] VC++ lag
>
>
> If you guys can provide a list things where vs can improve (from its
> latest version), with arguments such as (X sucks because
> this, this and
> that. Blah doesn't work in this situation), I'll be happy to forward
> your list of petitions to the VS team.
>
> David
>
>
>
> -----Original Message-----
> From: gam...@li...
> [mailto:gam...@li...] On Behalf Of
> brian sharon
> Sent: Thursday, June 12, 2003 11:04 AM
> To: gam...@li...
> Subject: Re: [GD-Windows] VC++ lag
>
> That's because for MS's large scale projects they don't use
> workspaces,
> and they do use something that looks a whole lot like make.
> It's called
>
> NT Build, and you can get it with the DDK. With an external build
> utility, VC can just be the debugger and you don't have to
> worry about
> its internal dependency checker being slow.
>
> We use a makefile-type solution here on a much smaller-scale project,
> and it works great - I would never go back to workspaces for any real
> project.
>
> --brian
>
> Jon Watte wrote:
>
> >It's really quite amazing how Microsoft can develop these
> >tools and they just don't scale well. It's all good as long
> >as your project is some 10,000 line report generator, but
> >for a large-scale commercial system, it's really quite lame.
> >Almost makes me wish for the days of GNU make, VIM and
> >CTags...
> >
> >(which we could do, because we generate .dsp and .dsw files
> >out of an abstract project description file that looks a lot
> >like a make file, anyway)
> >
> >
>
>
>
> -------------------------------------------------------
> This SF.NET email is sponsored by: eBay
> Great deals on office technology -- on eBay now! Click here:
> http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5
> _______________________________________________
> Gamedevlists-windows mailing list
> Gam...@li...
> https://lists.sourceforge.net/lists/listinfo/gamedevlists-windows
> Archives:
> http://sourceforge.net/mailarchive/forum.php?forum_id=555
>
>
> -------------------------------------------------------
> This SF.NET email is sponsored by: eBay
> Great deals on office technology -- on eBay now! Click here:
> http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5
> _______________________________________________
> Gamedevlists-windows mailing list
> Gam...@li...
> https://lists.sourceforge.net/lists/listinfo/gamedevlists-windows
> Archives:
> http://sourceforge.net/mailarchive/forum.php?forum_idU5
>
-------------------------------------------------------
This SF.NET email is sponsored by: eBay
Great deals on office technology -- on eBay now! Click here:
http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5
_______________________________________________
Gamedevlists-windows mailing list
Gam...@li...
https://lists.sourceforge.net/lists/listinfo/gamedevlists-windows
Archives:
http://sourceforge.net/mailarchive/forum.php?forum_idU5
|
|
From: Enno R. <en...@de...> - 2003-06-13 13:18:51
|
I can add a few cents here, too... [1] Intellisense: I'm sick of having to generate .ncb files, and since VC6, I've been using Visual Assist - a great productivity tool, for $79. [2] Keyboard shortcuts: I was so used to doing a "Find in Files" in VC6 and then stepping through the reuslts with F4. Why did they have to take that away? Now I *have* to use the mouse to step through search results, because F4 is exclusive to the compiler output list. [3] Immediate Evaluation: The Shift-F9 evaluation dialog only opens when I'm debugging now. I used it all the time during programming, as a calculator that understood C syntax. It was nice. Now it's no longer usable. [4] .sln files: I'm just upgrading from VS.net to VS.net 2003, and they've changed the format again, and they're incompatible - not upwards, not downwards! Which means that if you're publishing a library with source, you now have to have two sets of .sln files as well as dsw files included. Yikes. On the positive side, dependency checking seems to be much faster, and I like that it opens a lot faster than VC6 for a single .cpp file. Enno |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X