IDE Issues
in [MFC]
|
From: Hector Santos on 4 Mar 2010 05:10 David Ching wrote: > "Joseph M. Newcomer" <newcomer(a)flounder.com> wrote in message > news:efuso5d4o4g6sed51o39hvq5ef71l93op5(a)4ax.com... >> Actually, the file menu doesn't give full information, either. >> > > BTW, the Start Page gives the full path in the status bar at the bottom > as you mouse over the project name in the start page. Right, after noticing this it did make the IDE a little more bearable. Sometimes what I use to do is was "search" for the file name and get the search report to see what file is being including or used. -- HLS
From: David Ching on 4 Mar 2010 14:05 "Hector Santos" <sant9442(a)nospam.gmail.com> wrote in message news:e80ssL4uKHA.4908(a)TK2MSFTNGP06.phx.gbl... >> BTW, the Start Page gives the full path in the status bar at the bottom >> as you mouse over the project name in the start page. > > Right, after noticing this it did make the IDE a little more bearable. > > Sometimes what I use to do is was "search" for the file name and get the > search report to see what file is being including or used. > More fun: how do you know the full path of a source file that is open in the VS editor? Hover over the tab and it gives it to you! (The full path is not visible in the Solution Explorer or even in the file Properties). -- David
From: Hector Santos on 4 Mar 2010 14:22 David Ching wrote: > "Hector Santos" <sant9442(a)nospam.gmail.com> wrote in message > news:e80ssL4uKHA.4908(a)TK2MSFTNGP06.phx.gbl... >>> BTW, the Start Page gives the full path in the status bar at the >>> bottom as you mouse over the project name in the start page. >> >> Right, after noticing this it did make the IDE a little more bearable. >> >> Sometimes what I use to do is was "search" for the file name and get >> the search report to see what file is being including or used. >> > > More fun: how do you know the full path of a source file that is open > in the VS editor? Hover over the tab and it gives it to you! (The full > path is not visible in the Solution Explorer or even in the file > Properties). It wish it would show the FQFN "tip style" when you hover a #include <|"xxxxxxxxx.h"|> line. :) Sometimes I have to right click open it to see, then hover over the edit window tab get the FQFN. In all honesty, I had this idea once for VS IDE that it would be nice to have a summary output like a pre-MAKE display of: - The files in the project, - dependencies display. Or just for project summary reports. We do a make run in our IDE which helps create the similar popup like the VS IDE where it shows you a popup with a short list of files, projects that need to be recompiled. Pretty sweet recursive source code parsing function. :) How about a Print, Print Preview feature for Solution Explorer? Personally, the build report is useless 80% of the time. It should show date, time, size information to catalog this report. -- HLS -- HLS
From: Joseph M. Newcomer on 4 Mar 2010 17:06 See below... On Thu, 04 Mar 2010 14:22:19 -0500, Hector Santos <sant9442(a)nospam.gmail.com> wrote: >David Ching wrote: > >> "Hector Santos" <sant9442(a)nospam.gmail.com> wrote in message >> news:e80ssL4uKHA.4908(a)TK2MSFTNGP06.phx.gbl... >>>> BTW, the Start Page gives the full path in the status bar at the >>>> bottom as you mouse over the project name in the start page. >>> >>> Right, after noticing this it did make the IDE a little more bearable. >>> >>> Sometimes what I use to do is was "search" for the file name and get >>> the search report to see what file is being including or used. >>> >> >> More fun: how do you know the full path of a source file that is open >> in the VS editor? Hover over the tab and it gives it to you! (The full >> path is not visible in the Solution Explorer or even in the file >> Properties). > > >It wish it would show the FQFN "tip style" when you hover a > > #include <|"xxxxxxxxx.h"|> > >line. :) > >Sometimes I have to right click open it to see, then hover over the >edit window tab get the FQFN. > >In all honesty, I had this idea once for VS IDE that it would be nice >to have a summary output like a pre-MAKE display of: > > - The files in the project, > - dependencies display. > >Or just for project summary reports. **** It is really sad that the compiler and IDE really DO have all the information needed for this kind of report, but there is nothing that uses it. The silly readme.txt file contains nothing worthwhile. When I get confronted with 100KSLOC from some client project I'm supposed to fix, enhance, or rewrite, doing this part of the reverse engineering is one of the difficult tasks. And it doesn't have to be. (Note that you can enable a feature that dumps out a #include sequence during compilation, but then you have to turn it off again; having a Build>Report Structure menu item would be so much easier, and wouldn't have to involve a full rebuild. **** > >We do a make run in our IDE which helps create the similar popup like >the VS IDE where it shows you a popup with a short list of files, >projects that need to be recompiled. Pretty sweet recursive source >code parsing function. :) > >How about a Print, Print Preview feature for Solution Explorer? > >Personally, the build report is useless 80% of the time. It should >show date, time, size information to catalog this report. **** I have found that the build report is useless 99% of the time. And WHY IS is it that after 20 years we STILL do not have an auto-increment-build-number capability? The version # (including the current build #) should be in that report! joe **** > >-- >HLS Joseph M. Newcomer [MVP] email: newcomer(a)flounder.com Web: http://www.flounder.com MVP Tips: http://www.flounder.com/mvp_tips.htm
From: Hector Santos on 4 Mar 2010 17:45
Joseph M. Newcomer wrote: >> In all honesty, I had this idea once for VS IDE that it would be nice >> to have a summary output like a pre-MAKE display of: >> >> - The files in the project, >> - dependencies display. >> >> Or just for project summary reports. > **** > It is really sad that the compiler and IDE really DO have all the information needed for > this kind of report, but there is nothing that uses it. The silly readme.txt file > contains nothing worthwhile. Yes, now that is 100% worthless. But its like phishing mail - every once in awhile I will open it up to see if there anything intelligent finally added in there. I guess its meant for us to write something. :) On a related note, what we have in all our project folders are files with the file name format: build#.NEW, e.g.; 4533.new Each developer writes his notes using a legend: - NEW: A new feature was added. - FIX: A fix was performed to an existing feature. - ENH: Enhancement to a existence feature. The enhancement may be a result of a fix to the existing feature or a simple cleanup. - CHG: Change to an existence feature behavior. This might be result or imply an enhancement or a fix. But overall, it is considered a simple change in behavior concept to an existing feature. - DOC: Documentation item. A new or existing undocumented item is now documented or expanded. Then our build process collects all of these project\build#.NEW files and makes Addendum Update help pages like so from our last release: http://www.winserver.com/public/aup/aup453-3.htm I personally go thru them to create a marketing announcement for sales. Of course, I need to be selective of whats said there highlighting the NEW, ENH and consolidating the FIX items. Important, critical fixes are ethically and safely mentioned. :) I've use the above legend for my product notes since my first shareware product in 84. > When I get confronted with 100KSLOC from some client project I'm supposed to fix, enhance, > or rewrite, doing this part of the reverse engineering is one of the difficult tasks. And > it doesn't have to be. (Note that you can enable a feature that dumps out a #include > sequence during compilation, but then you have to turn it off again; having a Build>Report > Structure menu item would be so much easier, and wouldn't have to involve a full rebuild. Yes, I am aware of the pre-processor compiler dump of the includes (if that is what you are referring to). It is a freaking mess with redundancy. Passing it thru a filter helps. >> How about a Print, Print Preview feature for Solution Explorer? >> >> Personally, the build report is useless 80% of the time. It should >> show date, time, size information to catalog this report. > I have found that the build report is useless 99% of the time. Ok, since we just archive the build reports after each release build, and hardly ever use it (maybe once), I will say its useless 99% time too. :) > And WHY IS is it that after 20 years we STILL do not have an auto-increment-build-number > capability? The version # (including the current build #) should be in that report! I suspect because its really a highly personal thing for development. It could be optional (OFF by default) and possibly offer a hook into using a compiled C/C++ DLL and/or VB macro script or something to customize it. We could not use a simple auto-increment since it would totally break down our version/framework control/support. But if customizable, I would consider it for sure. -- HLS |