Visual C++ 6 support issue

I have a huge VC++ 6 MFC application (exe and dlls).  How long will VC++ 6 MFC be supported  by Microsoft....i.e. how long do I have before my application becomes unsupported and must be converted/rewritten to use .Net and/or MFC7?
0
anonymous (74717)
5/13/2004 8:56:09 PM
vc.mfc 33608 articles. 0 followers. Follow

58 Replies
966 Views

Similar Articles

[PageSpeed] 8

It is a good question. A lot of us wonder the same thing. Bottom line: until VS6 actually
stops running, we consider VS7 only as a last-ditch solution. Since effecitively it hasn't
been supported in years (SP6 came as a surprise to most of us), it is not something we've
been overly concerned with. The real pain is fhe difficulty people have in getting VS6,
the last decent development environment Microsoft delivered. I have on client that went to
VS7 because there was no way to get VS6, then a few weeks later ranted at me for three
solid hours about how VS7 was unusable. The worst part about the rant was that I could
only agree with them on nearly every point. Their project is one of the two VS7 projects I
currently support.

Besides the obvious failure to have applied a design review process (or even the most
rudimentary of usability studies) to the VS7 interface, Microsoft's second worst mistake
in the VS domain was discontinuing the availability of VS6. This is based on the premise
that it is sound business practice to discontinue a successful product while replacing it
with something that would fail a first-semester GUI design course. (I know someone who
teaches GUI design, and I've often thought of telling him he should submit VS7 to his
students and have the entire class critique its numerous catastrophic failures, and send
the collection of student papers to Microsoft. Preferrably cced to Steve Ballmer).
					joe

On Thu, 13 May 2004 13:56:09 -0700, CMXDev <anonymous@discussions.microsoft.com> wrote:

>I have a huge VC++ 6 MFC application (exe and dlls).  How long will VC++ 6 MFC be supported  by Microsoft....i.e. how long do I have before my application becomes unsupported and must be converted/rewritten to use .Net and/or MFC7?

Joseph M. Newcomer [MVP]
email: newcomer@flounder.com
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm
0
newcomer (15974)
5/14/2004 1:32:15 AM
And I though my difficulties were just because
    a) I've only just moved to VS7 and haven't yet adjusted to the new and
better way of doing things
and
    b) I'm stupid.

--- Al.



"Joseph M. Newcomer" <newcomer@flounder.com> wrote in message
news:vp78a0lq7m2ol6e40rijbf427cf4dq7s91@4ax.com...
> It is a good question. A lot of us wonder the same thing. Bottom line:
until VS6 actually
> stops running, we consider VS7 only as a last-ditch solution. Since
effecitively it hasn't
> been supported in years (SP6 came as a surprise to most of us), it is not
something we've
> been overly concerned with. The real pain is fhe difficulty people have in
getting VS6,
> the last decent development environment Microsoft delivered. I have on
client that went to
> VS7 because there was no way to get VS6, then a few weeks later ranted at
me for three
> solid hours about how VS7 was unusable. The worst part about the rant was
that I could
> only agree with them on nearly every point. Their project is one of the
two VS7 projects I
> currently support.
>
> Besides the obvious failure to have applied a design review process (or
even the most
> rudimentary of usability studies) to the VS7 interface, Microsoft's second
worst mistake
> in the VS domain was discontinuing the availability of VS6. This is based
on the premise
> that it is sound business practice to discontinue a successful product
while replacing it
> with something that would fail a first-semester GUI design course. (I know
someone who
> teaches GUI design, and I've often thought of telling him he should submit
VS7 to his
> students and have the entire class critique its numerous catastrophic
failures, and send
> the collection of student papers to Microsoft. Preferrably cced to Steve
Ballmer).
> joe
>
> On Thu, 13 May 2004 13:56:09 -0700, CMXDev
<anonymous@discussions.microsoft.com> wrote:
>
> >I have a huge VC++ 6 MFC application (exe and dlls).  How long will VC++
6 MFC be supported  by Microsoft....i.e. how long do I have before my
application becomes unsupported and must be converted/rewritten to use .Net
and/or MFC7?
>
> Joseph M. Newcomer [MVP]
> email: newcomer@flounder.com
> Web: http://www.flounder.com
> MVP Tips: http://www.flounder.com/mvp_tips.htm


0
nosuch1 (64)
5/14/2004 11:20:22 AM
If your user base continues with Windows 2000/XP class operatinging systems,
then you have no limit on how long you can write programs using VC++6.

The fact that Microsoft may no longer support the product has no direct
impact on how long you can use the product.

For instance, I have a very old Pentium machine running DOS 6.2 and Zortec
C++ compiler, and an editor based on vi - none of which are supported, but I
can still write programs (some may have issue with that bold claim), and if
I could just find a user that was still committed to DOS 6.2 platform, I may
be able to create a market :)

regards
roy fine



"CMXDev" <anonymous@discussions.microsoft.com> wrote in message
news:95966B4B-8CFB-48BE-AC82-4028E90EB0BA@microsoft.com...
> I have a huge VC++ 6 MFC application (exe and dlls).  How long will VC++ 6
MFC be supported  by Microsoft....i.e. how long do I have before my
application becomes unsupported and must be converted/rewritten to use .Net
and/or MFC7?


0
rlfine8815 (162)
5/14/2004 12:45:41 PM
In article <OJHJnWaOEHA.2276@TK2MSFTNGP09.phx.gbl>, 
nosuch@address.com says...
> And I though my difficulties were just because
>     a) I've only just moved to VS7 and haven't yet adjusted to the new and
> better way of doing things

As far as I can tell, it doesn't have any better ways of doing 
things.  Most of its ways are worse, and the remainder simply don't 
work at all.

> and
>     b) I'm stupid.

I can't say one way or the other about that, but I can say this much: 
I'm pretty sure you're more intelligent than whoever designed the 
VC++ 7 IDE.  I don't know if you could design and implement a better 
one, but you seem to at least recognize its shortcomings, which is 
apparently better than he did.

-- 
    Later,
    Jerry.

The universe is a figment of its own imagination.
0
jcoffin1 (194)
5/14/2004 5:10:11 PM
In article <vp78a0lq7m2ol6e40rijbf427cf4dq7s91@4ax.com>, 
newcomer@flounder.com says...
> It is a good question. A lot of us wonder the same thing. Bottom line: until VS6 actually
> stops running, we consider VS7 only as a last-ditch solution. Since effecitively it hasn't
> been supported in years (SP6 came as a surprise to most of us), it is not something we've
> been overly concerned with. The real pain is fhe difficulty people have in getting VS6,
> the last decent development environment Microsoft delivered. I have on client that went to
> VS7 because there was no way to get VS6, then a few weeks later ranted at me for three
> solid hours about how VS7 was unusable. 

My advice would be to get them to buy MSDN Professional (or higher) 
which will get them copies of VS 6.

My advice to Microsoft would be to start work on VS 8 by scrapping 
everything in VS 7.x, and starting over from VS 6.  The SOLE change 
in VS 7 that should be retained is having the option to keep the help 
system in-board.  Of course, from another viewpoint, that's not 
really a new feature of VS 7 either -- it's just going back to the 
way things were in VC++ 4.x.

> The worst part about the rant was that I could only agree with them on nearly 
> every point. Their project is one of the two VS7 projects I currently support.

In this case, I should probably tone down my rhetoric in other 
threads -- if you have to support _any_ VS 7 projects, you deserve 
moral support, no matter how certain I might be that you're wrong.
 
> Besides the obvious failure to have applied a design review process (or even the most
> rudimentary of usability studies) to the VS7 interface, Microsoft's second worst mistake
> in the VS domain was discontinuing the availability of VS6. This is based on the premise
> that it is sound business practice to discontinue a successful product while replacing it
> with something that would fail a first-semester GUI design course. (I know someone who
> teaches GUI design, and I've often thought of telling him he should submit VS7 to his
> students and have the entire class critique its numerous catastrophic failures, and send
> the collection of student papers to Microsoft. Preferrably cced to Steve Ballmer).

What have those students done to you, that you'd subject them to such 
a thing?  Personally, I think this would be unconstitutional: if 
convicted criminals are protected for cruel and unusual punishment, 
surly poor, possibly even innocent colleges students should be as 
well.

-- 
    Later,
    Jerry.

The universe is a figment of its own imagination.
0
jcoffin1 (194)
5/14/2004 6:07:31 PM
Roy, thanks for the input.  I am generally looking for information on what Microsoft may have told other developers.  A salesperson and an "evangelist" came to my company a few months ago and really gave some fuzzy answers on how long applications written in VS6 would be supported.  And, I am with you....I personally don't care if they "support" the tool.  But, the company I work for considers it a risk to have an application/system running that could break due to lack of support from Microsoft for the windows/tool environment in which it is running.  So, I feel responsible for getting some accurate information re: what the fate of our huge VS6/VC++ application/system should be in the year(s) to come

At this point, I have been experimenting with converting all my VS6 modules to VS7.  I have only done a few modules and it hasn't been fun. 
0
anonymous (74717)
5/14/2004 6:31:02 PM
>I'm pretty sure you're more intelligent than whoever designed the 
>VC++ 7 IDE.

Unfortunately, this isn';t much of a compliment. I'd trust my pet rock to do a better
design. It might not do anything, and that would have been an improvement over what we
have.
				joe


On Fri, 14 May 2004 11:10:11 -0600, Jerry Coffin <jcoffin@taeus.us> wrote:

>In article <OJHJnWaOEHA.2276@TK2MSFTNGP09.phx.gbl>, 
>nosuch@address.com says...
>> And I though my difficulties were just because
>>     a) I've only just moved to VS7 and haven't yet adjusted to the new and
>> better way of doing things
>
>As far as I can tell, it doesn't have any better ways of doing 
>things.  Most of its ways are worse, and the remainder simply don't 
>work at all.
>
>> and
>>     b) I'm stupid.
>
>I can't say one way or the other about that, but I can say this much: 
>I'm pretty sure you're more intelligent than whoever designed the 
>VC++ 7 IDE.  I don't know if you could design and implement a better 
>one, but you seem to at least recognize its shortcomings, which is 
>apparently better than he did.

Joseph M. Newcomer [MVP]
email: newcomer@flounder.com
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm
0
newcomer (15974)
5/14/2004 6:55:55 PM
Actually, the inboard help system sucks, too. I used to be able to tile the MSDN lib and
VS6 so I could read both at once. This does not seem possible in VS7. I have not been able
to figure out how to tile help and source code. I solved the problem by moving to a
dual-monitor system and keeping a version of VS7 on the "other" monitor just to read the
documentation (I don't use it for development, so what I get is an interface poorer than
the original infobrowser that came with MSDN #1, but we've already pointed out to MS that
the quality of their documentation browser has been declining for a dozen years, with each
release being poorer than its predecessor).

Let's see: what would have improved VS6?

* Longer edit controls for things like control names, so we didn't have to use horizontal
scrolling
* Getting the Z-order of dialog layout right
* Showing the entire string name in the STRINGTABLE, instead of having a fixed-size column
that chops it off.
* Supporting all the new methods, messages, etc. that have evolved since VS6 was delivered
* Allowing WM_GETMINMAXINFO to be handled for dialog-based apps that have a resizing
border
* Keeping all control member variables protected instead of public
* Allowing decent support so the ghastly editor could be replaced with a real editor
* Use the clipboard for copy-and-paste of controls so they can be copied and pasted
BETWEEN copies of visual studio
* A more reliable NCB file mechanism
* Multiprocess debugging
* Saving settings INSTANTLY so if VS6 or the OS or hardware crashes, all customizations
are maintained (instead of being lost), and if a customizatiion is made, it is instantly
available in all versions of VS that are started, even before the version of VS in which
the changes were made has not been closed (get rid of MS-DOS thinking, that people
actually EXIT programs!)

I factor out the numerous improvements to the C compiler, MFC, etc. because these could
have been done as readily with a VS6 interface.

What do I like about VS7?
* The tabbed dialogs at the bottom of the screen so I can quickly switch views if I need
to, e.g., having the call stack a single mouse click away.
* Z-order on dialogs is fixed
* I can make control variables protected (the default of 'public' is always wrong, of
course; there is no sane reason to make control variables public)
* Multiprocess debugging
* There is one other thing I like, but I can't remember it

There is not room to list everything I detest about it.

OK, that exhausts my list, at least at the moment. So why didn't we just get these
improvements? Because it became somebody's "toy project" to do a "new" interface that was
an "improvement". As far as I can tell, the designer not once, not ever, wrote an MFC
program or the defects would have been instantaneously visible. No usability studies were
done with real programmers, or the results were ignored. A competent design review would
have deep-sixed this design at its first meeting. And the abomination was actually allowed
to escape the designer's office!
					joe

On Fri, 14 May 2004 12:07:31 -0600, Jerry Coffin <jcoffin@taeus.us> wrote:

>In article <vp78a0lq7m2ol6e40rijbf427cf4dq7s91@4ax.com>, 
>newcomer@flounder.com says...
>> It is a good question. A lot of us wonder the same thing. Bottom line: until VS6 actually
>> stops running, we consider VS7 only as a last-ditch solution. Since effecitively it hasn't
>> been supported in years (SP6 came as a surprise to most of us), it is not something we've
>> been overly concerned with. The real pain is fhe difficulty people have in getting VS6,
>> the last decent development environment Microsoft delivered. I have on client that went to
>> VS7 because there was no way to get VS6, then a few weeks later ranted at me for three
>> solid hours about how VS7 was unusable. 
>
>My advice would be to get them to buy MSDN Professional (or higher) 
>which will get them copies of VS 6.
>
>My advice to Microsoft would be to start work on VS 8 by scrapping 
>everything in VS 7.x, and starting over from VS 6.  The SOLE change 
>in VS 7 that should be retained is having the option to keep the help 
>system in-board.  Of course, from another viewpoint, that's not 
>really a new feature of VS 7 either -- it's just going back to the 
>way things were in VC++ 4.x.
>
>> The worst part about the rant was that I could only agree with them on nearly 
>> every point. Their project is one of the two VS7 projects I currently support.
>
>In this case, I should probably tone down my rhetoric in other 
>threads -- if you have to support _any_ VS 7 projects, you deserve 
>moral support, no matter how certain I might be that you're wrong.
> 
>> Besides the obvious failure to have applied a design review process (or even the most
>> rudimentary of usability studies) to the VS7 interface, Microsoft's second worst mistake
>> in the VS domain was discontinuing the availability of VS6. This is based on the premise
>> that it is sound business practice to discontinue a successful product while replacing it
>> with something that would fail a first-semester GUI design course. (I know someone who
>> teaches GUI design, and I've often thought of telling him he should submit VS7 to his
>> students and have the entire class critique its numerous catastrophic failures, and send
>> the collection of student papers to Microsoft. Preferrably cced to Steve Ballmer).
>
>What have those students done to you, that you'd subject them to such 
>a thing?  Personally, I think this would be unconstitutional: if 
>convicted criminals are protected for cruel and unusual punishment, 
>surly poor, possibly even innocent colleges students should be as 
>well.

Joseph M. Newcomer [MVP]
email: newcomer@flounder.com
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm
0
newcomer (15974)
5/14/2004 7:15:42 PM
"Joseph M. Newcomer" wrote:

>  (SP6 came as a surprise to most of us),

What does SP6 fix? I'm suspicious of updates. Sometimes they break something else.

Thanks,
Rick

0
Rick7596 (41)
5/15/2004 2:06:09 AM
I will get a lot of "hate mail" for not blasting/flaming Visual Studio 7,
but here's my 'ate-me's worth:

At first I thought it was just for use in .Net - because most of the things
that I was used to doing was no longer available - I did a lot of API stuff
like services, and server side DB apps, and a lot of client side apps using
MFC.  We finally jumped off the deep end, and converted everything to VS7,
one at a time.  And we are not all VS7  (mostly unmanaged, but more and more
C# for new stuff) - and I must say, all that I thought was "not there" was
just "in a different place".  Some things are a bit more tedious, like
wiring up member variables in a dialog, etc - but you get used to doing them
by hand.  MessageMaps were a big learning curve - but they are euqally
handled well in VS7...  etc, etc, etc, etc...

I you have concerns about being left on an unsupported paltform, migrate to
the supported.  It's not quite so bad as others would intimate.

regards
roy


"CMXDev" <anonymous@discussions.microsoft.com> wrote in message
news:66D32792-6F64-4D2A-A01E-FED1205BE88F@microsoft.com...
> Roy, thanks for the input.  I am generally looking for information on what
Microsoft may have told other developers.  A salesperson and an "evangelist"
came to my company a few months ago and really gave some fuzzy answers on
how long applications written in VS6 would be supported.  And, I am with
you....I personally don't care if they "support" the tool.  But, the company
I work for considers it a risk to have an application/system running that
could break due to lack of support from Microsoft for the windows/tool
environment in which it is running.  So, I feel responsible for getting some
accurate information re: what the fate of our huge VS6/VC++
application/system should be in the year(s) to come.
>
> At this point, I have been experimenting with converting all my VS6
modules to VS7.  I have only done a few modules and it hasn't been fun.


0
rlfine8815 (162)
5/15/2004 2:35:57 AM
In article <773162FA-1B5B-478A-BC1A-0CDD133F025A@microsoft.com>, 
anonymous@discussions.microsoft.com says...
> What about being able to create services?  I heard that you need 7 for that.  
> Is that true?

Presumably you mean web services, not Win32 services (which you can 
build with anything back to VC++ 2).

Officially support for web services was new with VS 7.  Less 
officially, you could build web services with VS 6 and the beta 
versions of the .NET SDK.

-- 
    Later,
    Jerry.

The universe is a figment of its own imagination.
0
jcoffin1 (194)
5/15/2004 4:29:08 AM
Actually, yes, there are some classes that make it easier to create Windows Services.
However, that's not a particularly difficult thing to do anyway. And these are features of
MFC, not of the IDE, which is where most of the problems are in VS7. If anything, I resent
the fact that the intolerable interface interferes with using these new features (one of
my clients actually requires an MFC feature not available in VS6, and they absolutely HATE
VS7, but they have to use it to get this feature)

A couple useful features that MFC7 has is the ability to use CString without buying into
all of MFC, and the ability to have a mix of 8-bit and 16-bit CStrings. But these are MFC
enhancements, which could have easily been done in VS6. That's why I'm trying to keep
separate the notions of what MFC does and what the interface looks like. There are a lot
of good features in the MFC that comes with VS7, but they are unrelated to the interface
that the user gets.
				joe

On Fri, 14 May 2004 22:29:08 -0600, Jerry Coffin <jcoffin@taeus.us> wrote:

>In article <773162FA-1B5B-478A-BC1A-0CDD133F025A@microsoft.com>, 
>anonymous@discussions.microsoft.com says...
>> What about being able to create services?  I heard that you need 7 for that.  
>> Is that true?
>
>Presumably you mean web services, not Win32 services (which you can 
>build with anything back to VC++ 2).
>
>Officially support for web services was new with VS 7.  Less 
>officially, you could build web services with VS 6 and the beta 
>versions of the .NET SDK.

Joseph M. Newcomer [MVP]
email: newcomer@flounder.com
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm
0
newcomer (15974)
5/15/2004 4:49:40 AM
It is more than "a bit more tedious"--it is a LOT more tedious, and that is inexcusable.
And having to do them by hand is an out-and-out condemnation of the crappy interface.

Things which should be simple are no longer simple. Things like adding variables, which is
so slow that I find the performance on my 2GHz machine unacceptable. The incredible
modality, where you have to be in the right place to right-click to get the menu that
gives you something (e.g., ClassWizard, that used to be invokable by Ctrl+W from
anywhere). The arrogance that says "You cannot edit resources while you are running", as
if it is the province of the IDE to prevent a perfectly reasonable set of changes from
being done. The annoying tendency of grabbing focus from the user and switching to
something completely irrelevant, e.g., each time I add a new control variable or handler,
being put into a piece of source code I could care less about. The sum of these idiocies
shows a remarkably lack of understanding of the coding process. Why would I want to switch
to code when I'm adding handlers? VS6 understood this; VS7 was designed by an idiot,
because his premises about how people program are at odds with how people ACTUALLY
program.

Asinine changes like the redefinition of Ctrl+X/Cut to mean something nonsensical are also
inexcusable (did you know that Ctrl+X, if nothing is selected, is no longer the no-op it
is IN EVERY OTHER MICROSOFT PRODUCT? Instead, it has been redefined to mean "cut the line
the caret is in". Why the designer thought he was entitled to redefine fundamental window
behavior escapes me. And there is no way to DISABLE this stupidity!

The number of mouse clicks required is ridiculous. I've done experiments that show that it
can take up to four times the mouse clicks in VS7 to accomplish something I could do
easily in VS6. Why? Because the interface is "smart" and "context sensitive" (as if I
would want that!) And the complexity of the "planning" (a term from cognitive psychology)
is substantially higher...you have to think more carefully about how to do something. The
most elementary of usability studies (the kind you assign first-semester students) would
have shown how bad this is; a study of basic principles of GUIs (no modality) would have
shown how bad this is; asking anyone what was wrong with VS6 would have come up with a set
of issues that the current VS7 either doesn't solve or makes worse.
					joe

On Fri, 14 May 2004 22:35:57 -0400, "Roy Fine" <rlfine@twt.obfuscate.net> wrote:

>I will get a lot of "hate mail" for not blasting/flaming Visual Studio 7,
>but here's my 'ate-me's worth:
>
>At first I thought it was just for use in .Net - because most of the things
>that I was used to doing was no longer available - I did a lot of API stuff
>like services, and server side DB apps, and a lot of client side apps using
>MFC.  We finally jumped off the deep end, and converted everything to VS7,
>one at a time.  And we are not all VS7  (mostly unmanaged, but more and more
>C# for new stuff) - and I must say, all that I thought was "not there" was
>just "in a different place".  Some things are a bit more tedious, like
>wiring up member variables in a dialog, etc - but you get used to doing them
>by hand.  MessageMaps were a big learning curve - but they are euqally
>handled well in VS7...  etc, etc, etc, etc...
>
>I you have concerns about being left on an unsupported paltform, migrate to
>the supported.  It's not quite so bad as others would intimate.
>
>regards
>roy
>
>
>"CMXDev" <anonymous@discussions.microsoft.com> wrote in message
>news:66D32792-6F64-4D2A-A01E-FED1205BE88F@microsoft.com...
>> Roy, thanks for the input.  I am generally looking for information on what
>Microsoft may have told other developers.  A salesperson and an "evangelist"
>came to my company a few months ago and really gave some fuzzy answers on
>how long applications written in VS6 would be supported.  And, I am with
>you....I personally don't care if they "support" the tool.  But, the company
>I work for considers it a risk to have an application/system running that
>could break due to lack of support from Microsoft for the windows/tool
>environment in which it is running.  So, I feel responsible for getting some
>accurate information re: what the fate of our huge VS6/VC++
>application/system should be in the year(s) to come.
>>
>> At this point, I have been experimenting with converting all my VS6
>modules to VS7.  I have only done a few modules and it hasn't been fun.
>

Joseph M. Newcomer [MVP]
email: newcomer@flounder.com
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm
0
newcomer (15974)
5/15/2004 5:02:21 AM
But how is that different from VS6, where the size of the two DLLs is close to a megabyte?
				joe

On Sat, 15 May 2004 11:40:33 -0700, "Michael Leung" <Leung_@163.com> wrote:

>I have just moved to VC7.0 and I'm now worrying many maintenance issues. In
>order to distribute .exe files written in VC7.0. It seems that we should
>copy the MFC71.dll & MSVCR71.dll. But isn't it very stupid  when the actual
>size of the .exe is xKB but the size of two dll is xMB?
>
>"CMXDev" <anonymous@discussions.microsoft.com> wrote in message
>news:95966B4B-8CFB-48BE-AC82-4028E90EB0BA@microsoft.com...
>> I have a huge VC++ 6 MFC application (exe and dlls).  How long will VC++ 6
>MFC be supported  by Microsoft....i.e. how long do I have before my
>application becomes unsupported and must be converted/rewritten to use .Net
>and/or MFC7?
>

Joseph M. Newcomer [MVP]
email: newcomer@flounder.com
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm
0
newcomer (15974)
5/15/2004 5:03:05 AM
"Joseph M. Newcomer" <newcomer@flounder.com> wrote in message
news:0j5aa0pgce6l12k3kebg1iegpam82shmpe@4ax.com...
> Actually, the inboard help system sucks, too. I used to be able to tile
the MSDN lib and
> VS6 so I could read both at once. This does not seem possible in VS7. I
have not been able
> to figure out how to tile help and source code. I solved the problem by
moving to a

Three ways:
1. Right click on the help window tab header. Check "Floating", then
"Dockable". You can then dock the help window together with task List, Find
Results, etc.
or 2. Right click ot the tab header. Select New horizontal tab group.
or 3. Tools->Options->Help->External help. You can then move help window to
another monitor.

> dual-monitor system and keeping a version of VS7 on the "other" monitor
just to read the
> documentation (I don't use it for development, so what I get is an
interface poorer than
> the original infobrowser that came with MSDN #1, but we've already pointed
out to MS that
> the quality of their documentation browser has been declining for a dozen
years, with each
> release being poorer than its predecessor).
>
> Let's see: what would have improved VS6?
>
> * Longer edit controls for things like control names, so we didn't have to
use horizontal
> scrolling
> * Getting the Z-order of dialog layout right

What was wrong with it?

> * Showing the entire string name in the STRINGTABLE, instead of having a
fixed-size column
> that chops it off.
> * Supporting all the new methods, messages, etc. that have evolved since
VS6 was delivered
> * Allowing WM_GETMINMAXINFO to be handled for dialog-based apps that have
a resizing
> border

Select CWnd message filter.

I also add: Allow to select font for binary editor view.


0
alegr (1131)
5/15/2004 5:12:00 AM
You can also "downgrade" your VC7.
http://msdn.microsoft.com/visualc/previous/downgrade.aspx

"Jerry Coffin" <jcoffin@taeus.us> wrote in message
news:MPG.1b0eb0cb19397e349896e2@msnews.microsoft.com...
> In article <vp78a0lq7m2ol6e40rijbf427cf4dq7s91@4ax.com>,
> newcomer@flounder.com says...
> > It is a good question. A lot of us wonder the same thing. Bottom line:
until VS6 actually
> > stops running, we consider VS7 only as a last-ditch solution. Since
effecitively it hasn't
> > been supported in years (SP6 came as a surprise to most of us), it is
not something we've
> > been overly concerned with. The real pain is fhe difficulty people have
in getting VS6,
> > the last decent development environment Microsoft delivered. I have on
client that went to
> > VS7 because there was no way to get VS6, then a few weeks later ranted
at me for three
> > solid hours about how VS7 was unusable.
>
> My advice would be to get them to buy MSDN Professional (or higher)
> which will get them copies of VS 6.
>


0
alegr (1131)
5/15/2004 5:14:24 AM
I was talking about a service that can run in Windows when the computer starts up.  What do you have to do to make a service?  I have docs on how to make a Windows NT service but haven't got to it yet.  Will that suffice for making one for XP?  Do you just use the correct classes and complie as usual to make a .exe?
0
anonymous (74717)
5/15/2004 6:26:02 AM
In article <e5pUkXiOEHA.2740@TK2MSFTNGP11.phx.gbl>, 
rlfine@twt.obfuscate.net says...

[ talking about VS 7 ] 

> I must say, all that I thought was "not there" was
> just "in a different place".

If somebody can show me where the working tagged regular expressions 
are, I'd appreciate it.

> Some things are a bit more tedious, like
> wiring up member variables in a dialog, etc - but you get used to doing them
> by hand.

Ultimately, this sounds a great deal to me as if Roy Fine has had 
essentially the same experiences as the rest of us with VS 7, and 
despite his claims to the contrary has basically confirmed our worst 
accusations against it.

The difference is in our attitudes about it: he says you get used to 
doing it by hand.  I (and apparently Joseph agrees) say you should 
NEVER get used to doing things by hand when the machine can do them 
for you, and do the job better, faster and more accurately.

I don't mean this as an attack directly on Roy Fine (the name sounds 
vaguely familiar, but I don't know enough about him), but I think the 
basic attitude of "you get used to doing them by hand" is a highly 
destructive one -- in particular, even if it's totally subconscious 
and unintentional, it leads almost inevitably to the attitude that 
"well, I've gotten used to doing things by hand, my users can do the 
same", and based on that, your OWN programs suffer as well.

The fact is, programming tools should raise our expectations of 
ourselves, and then they should help us meet those raised 
expectations.  VS7 does neither: it lowers our expectations of 
ourselves, and makes it more difficult to meet even those lowered 
expectations.

At least in my book, that's nearly the definition of an inferior 
tool.

-- 
    Later,
    Jerry.

The universe is a figment of its own imagination.
0
jcoffin1 (194)
5/15/2004 3:35:35 PM
In article news:<c38ba0prcl3d3q05oimrhpr30vrfbamkh0@4ax.com>, Joseph M. 
Newcomer wrote:
> A couple useful features that MFC7 has is the ability to use CString
> without buying into all of MFC, and the ability to have a mix of
> 8-bit and 16-bit CStrings.

If you're not "buying into" the whole of MFC you can always use 
std::string (and std::wstring) for this.

Cheers,
 Daniel.
 



0
wastebasket (364)
5/15/2004 4:28:53 PM
In article <F4587A29-2F1C-483F-AF59-1924584CB0D5@microsoft.com>, 
anonymous@discussions.microsoft.com says...
> I was talking about a service that can run in Windows when the computer 
> starts up.  What do you have to do to make a service?  I have docs on 
> how to make a Windows NT service but haven't got to it yet.  Will that 
> suffice for making one for XP?  Do you just use the correct classes and 
> complie as usual to make a .exe?

VS 7 does add an AppWizard template for creating a service that uses 
..NET.  Under VS 6, you can create a service perfectly well without a 
template, but if you want a template, there are a number floating 
around (e.g. I'd almost bet there's at least one on CodeProject).

-- 
    Later,
    Jerry.

The universe is a figment of its own imagination.
0
jcoffin1 (194)
5/15/2004 5:34:00 PM
I have just moved to VC7.0 and I'm now worrying many maintenance issues. In
order to distribute .exe files written in VC7.0. It seems that we should
copy the MFC71.dll & MSVCR71.dll. But isn't it very stupid  when the actual
size of the .exe is xKB but the size of two dll is xMB?

"CMXDev" <anonymous@discussions.microsoft.com> wrote in message
news:95966B4B-8CFB-48BE-AC82-4028E90EB0BA@microsoft.com...
> I have a huge VC++ 6 MFC application (exe and dlls).  How long will VC++ 6
MFC be supported  by Microsoft....i.e. how long do I have before my
application becomes unsupported and must be converted/rewritten to use .Net
and/or MFC7?


0
Michael
5/15/2004 6:40:33 PM
Jerry,

No complaints with your inputs - my position is one based a bit more on
what's available now, not so much on how it could have been.  Over a beer or
two on friday afternoon, I would blast VS7 with the best of them.  But come
Monday and through the end of the week, I use it to make a decent living
(all one could infer from that is "it works for me").  My initial perception
of the new interface was similar to most.  Time has softened that a bit -
likely due to figuring out how to do things in the new user interface,
partly because ranting has never gotten me that far (unlike the majority
here, few listen to me with any measurable amount ot attention), and last, I
just got a brand new system, sporting a quad-zillion GHZ AMD processor with
about that much memory, and now I am getting close to what I was getting
circa 1992 with Zortec C++/vi/486DX2 performance.

We do about 70% VC++/MFC and 30% C# - it's quite nice to have ONE user
interface.  I don't think it would have been any better had the C# IDE been
that of VB6, and VC7 stayed the same as VC6 (this is not the C# ng - but
these days we are not quite so single minded vis-a-vis languages as we were
just a few years ago, and the fewer tools I must master, the better).

As others can emit miles of anecdotal prose, consider this - after 2 weeks
of developing in Oracle PL/SQL(an Algol derivative), all of my C++
assignment statements are initially :=, not =; all blocks are BEGIN END, not
{}, and my first inclination towards debugging is to sprinkle code with
PUT_LINEs, not breakpoints.  So I tend to get more worked up about the lack
of standards and the differences between tool A and tool B, rather than
spending all that much time analyzing tool A or tool B.  The manager that I
had on my first programming job after leaving university told me thousands
of things that he thought were clever and important - I remember only two:
1) the best editor ever is the last one you learned to use
2) if the next release of our products do nothing else, they do make the
previous release a raving success.

The current may not be optimal (no arguments there) but it's functional, and
it's consistent --  much like the McDonalds hamburger, it's consistent
around the world - certainly not optimal, but consistent.

rlf

"Jerry Coffin" <jcoffin@taeus.us> wrote in message
news:MPG.1b0fe6a07377153d9896e4@msnews.microsoft.com...
> In article <e5pUkXiOEHA.2740@TK2MSFTNGP11.phx.gbl>,
> rlfine@twt.obfuscate.net says...
>
> [ talking about VS 7 ]
>
> > I must say, all that I thought was "not there" was
> > just "in a different place".
>
> If somebody can show me where the working tagged regular expressions
> are, I'd appreciate it.
>
> > Some things are a bit more tedious, like
> > wiring up member variables in a dialog, etc - but you get used to doing
them
> > by hand.
>
> Ultimately, this sounds a great deal to me as if Roy Fine has had
> essentially the same experiences as the rest of us with VS 7, and
> despite his claims to the contrary has basically confirmed our worst
> accusations against it.
>
> The difference is in our attitudes about it: he says you get used to
> doing it by hand.  I (and apparently Joseph agrees) say you should
> NEVER get used to doing things by hand when the machine can do them
> for you, and do the job better, faster and more accurately.
>
> I don't mean this as an attack directly on Roy Fine (the name sounds
> vaguely familiar, but I don't know enough about him), but I think the
> basic attitude of "you get used to doing them by hand" is a highly
> destructive one -- in particular, even if it's totally subconscious
> and unintentional, it leads almost inevitably to the attitude that
> "well, I've gotten used to doing things by hand, my users can do the
> same", and based on that, your OWN programs suffer as well.
>
> The fact is, programming tools should raise our expectations of
> ourselves, and then they should help us meet those raised
> expectations.  VS7 does neither: it lowers our expectations of
> ourselves, and makes it more difficult to meet even those lowered
> expectations.
>
> At least in my book, that's nearly the definition of an inferior
> tool.
>
> -- 
>     Later,
>     Jerry.
>
> The universe is a figment of its own imagination.


0
rlfine8815 (162)
5/15/2004 7:51:00 PM
You can't rely on any MFC DLL being on the user's system.. and your
installer should allow for that.  If you don't want to redistribute the MFC
DLL's, then link to the MFC Lib statically.

To stay on topic - I agree with everything Joseph has said in this thread
about VC7.

    Rail
-- 
      Recording Engineer/Software Developer
      Rail Jon Rogut Software
      http://www.railjonrogut.com
      mailto:rail@railjonrogut.com

"Michael Leung" <Leung_@163.com> wrote in message
news:OKvd64lOEHA.640@TK2MSFTNGP12.phx.gbl...
> Programs written by VC6 are linked to MFC42.dll & MSVCR.dll. These two dll
> files are already in the system directory of the mainstream MS Windows. So
> we needn't copy them when distribute .exe files. But MFC71.dll & MSVCR.dll
> are NOT included in the OS, we had to copy or when run the programs
produced
> by VC7, they will complain "can nont find certain dlls"...
>
> You can find mfc42.dll in your windows system directory. In my Win2K, they
> located in  C:\Winnt\system32.
>
> "Joseph M. Newcomer" <newcomer@flounder.com> wrote in message
> news:h39ba01jkrk7itfl6e0dicc30g78nll3n0@4ax.com...
> > But how is that different from VS6, where the size of the two DLLs is
> close to a megabyte?
> > joe
> >
> > On Sat, 15 May 2004 11:40:33 -0700, "Michael Leung" <Leung_@163.com>
> wrote:
> >
> > >I have just moved to VC7.0 and I'm now worrying many maintenance
issues.
> In
> > >order to distribute .exe files written in VC7.0. It seems that we
should
> > >copy the MFC71.dll & MSVCR71.dll. But isn't it very stupid  when the
> actual
> > >size of the .exe is xKB but the size of two dll is xMB?
> > >
> > >"CMXDev" <anonymous@discussions.microsoft.com> wrote in message
> > >news:95966B4B-8CFB-48BE-AC82-4028E90EB0BA@microsoft.com...
> > >> I have a huge VC++ 6 MFC application (exe and dlls).  How long will
> VC++ 6
> > >MFC be supported  by Microsoft....i.e. how long do I have before my
> > >application becomes unsupported and must be converted/rewritten to use
> .Net
> > >and/or MFC7?
> > >
> >
> > Joseph M. Newcomer [MVP]
> > email: newcomer@flounder.com
> > Web: http://www.flounder.com
> > MVP Tips: http://www.flounder.com/mvp_tips.htm
>
>


0
railro (128)
5/15/2004 8:29:02 PM
You could enable that feature in VC6, too (allow copy without selection:
Options/Compatibility), but you would not want! Now, it's always enabled. I
guess it was how VB editor used to work (never tried).

"Joseph M. Newcomer" <newcomer@flounder.com> wrote in message
news:bc8ba09el5ik211u1csbdrtibmk0c9ofk8@4ax.com...
>
> Asinine changes like the redefinition of Ctrl+X/Cut to mean something
nonsensical are also
> inexcusable (did you know that Ctrl+X, if nothing is selected, is no
longer the no-op it
> is IN EVERY OTHER MICROSOFT PRODUCT? Instead, it has been redefined to
mean "cut the line
> the caret is in". Why the designer thought he was entitled to redefine
fundamental window
> behavior escapes me. And there is no way to DISABLE this stupidity!
>


0
alegr (1131)
5/15/2004 9:19:15 PM
> I have just moved to VC7.0 and I'm now worrying many maintenance issues. In
> order to distribute .exe files written in VC7.0. It seems that we should
> copy the MFC71.dll & MSVCR71.dll. But isn't it very stupid  when the actual
> size of the .exe is xKB but the size of two dll is xMB?

You can avoid this by linking statically.

-- 
Jim Johnson 
0
jamos (15)
5/15/2004 11:44:31 PM
Programs written by VC6 are linked to MFC42.dll & MSVCR.dll. These two dll
files are already in the system directory of the mainstream MS Windows. So
we needn't copy them when distribute .exe files. But MFC71.dll & MSVCR.dll
are NOT included in the OS, we had to copy or when run the programs produced
by VC7, they will complain "can nont find certain dlls"...

You can find mfc42.dll in your windows system directory. In my Win2K, they
located in  C:\Winnt\system32.

"Joseph M. Newcomer" <newcomer@flounder.com> wrote in message
news:h39ba01jkrk7itfl6e0dicc30g78nll3n0@4ax.com...
> But how is that different from VS6, where the size of the two DLLs is
close to a megabyte?
> joe
>
> On Sat, 15 May 2004 11:40:33 -0700, "Michael Leung" <Leung_@163.com>
wrote:
>
> >I have just moved to VC7.0 and I'm now worrying many maintenance issues.
In
> >order to distribute .exe files written in VC7.0. It seems that we should
> >copy the MFC71.dll & MSVCR71.dll. But isn't it very stupid  when the
actual
> >size of the .exe is xKB but the size of two dll is xMB?
> >
> >"CMXDev" <anonymous@discussions.microsoft.com> wrote in message
> >news:95966B4B-8CFB-48BE-AC82-4028E90EB0BA@microsoft.com...
> >> I have a huge VC++ 6 MFC application (exe and dlls).  How long will
VC++ 6
> >MFC be supported  by Microsoft....i.e. how long do I have before my
> >application becomes unsupported and must be converted/rewritten to use
..Net
> >and/or MFC7?
> >
>
> Joseph M. Newcomer [MVP]
> email: newcomer@flounder.com
> Web: http://www.flounder.com
> MVP Tips: http://www.flounder.com/mvp_tips.htm


0
Michael
5/16/2004 12:22:42 AM
In article <0j5aa0pgce6l12k3kebg1iegpam82shmpe@4ax.com>, 
newcomer@flounder.com says...

[ ... ]

> Let's see: what would have improved VS6?

[ list elided ] 

I can think of a few more things:

1) bring back search AND replace in files (was available in PWB).
2) bring back custom project templates (also in PWB).
3) bring back ability to compile a file without it being part of a
   project (at the risk of boring people, yup, PWB did that too).
4) allow custom colorizing -- this is sort of available already, but
   only to the extent that you can define things to be treated as key
   words.
5) create a documented interface for plug-in DLLs.  In one fell swoop
   this deals with a lot of other potential problems (come to
   think of it, PWB also had this, even under DOS).
6) Have it use debughlp.dll for debugging -- which would allow mixing
   compilers and environments (e.g. VS 6, CL 13.x).
7) Really an MSDN issue: functions should not have separate help for
   Windows CE -- when applicable, CE should just be listed as a
   supported platform (with differences noted as necessary).

> * Allowing WM_GETMINMAXINFO to be handled for dialog-based apps that have a resizing
> border

This can be done already -- in the ClassWizard under Class Info, 
change the message filter from "Dialog" to "Window" or "Topmost 
Frame" (a couple of the others might work also).

> * Keeping all control member variables protected instead of public

I'd rather see them private, so perhaps it would be best to make it 
configurable.

> * Allowing decent support so the ghastly editor could be replaced with a real editor

Hmmm...there are external editors that work along with it, though 
this is probably more in spite of MS than with their support.

> * Use the clipboard for copy-and-paste of controls so they can be copied and pasted
> BETWEEN copies of visual studio

Yes, you'd think they hadn't read the Windows documentation on how to 
support custom clipboard formats or something...

> I factor out the numerous improvements to the C compiler, MFC, etc. because these could
> have been done as readily with a VS6 interface.

AAMOF, it takes only a little playing with the executable/include/lib 
paths to get VS 6 to compile with the current compiler and MFC -- 
though debugging doesn't work (see point 6 above).

> * There is one other thing I like, but I can't remember it

I can think of at least one other: the ability to quickly collapse 
function definitions so only the headers are shown is kind of handy 
at times.

> OK, that exhausts my list, at least at the moment. So why didn't we just get these
> improvements? Because it became somebody's "toy project" to do a "new" interface that was
> an "improvement". As far as I can tell, the designer not once, not ever, wrote an MFC
> program or the defects would have been instantaneously visible. No usability studies were
> done with real programmers, or the results were ignored. A competent design review would
> have deep-sixed this design at its first meeting. And the abomination was actually allowed
> to escape the designer's office!

I'm pretty sure the ultimate idea was pretty simple: they were going 
to make everything else run under the VB environment, regardless of 
how poorly it suited them.  I can (sort of) sympathize with the basic 
idea, and at its core the idea isn't necessarily a bad one -- but in 
this case the execution in general is fatally flawed.

-- 
    Later,
    Jerry.

The universe is a figment of its own imagination.
0
jcoffin1 (194)
5/16/2004 4:22:44 AM
In article <uVQUtcrOEHA.1340@TK2MSFTNGP12.phx.gbl>, 
rlfine@twt.obfuscate.net says...

[ ... ]

> As others can emit miles of anecdotal prose, consider this - after 2 weeks
> of developing in Oracle PL/SQL(an Algol derivative), all of my C++
> assignment statements are initially :=, not =; all blocks are BEGIN END, not
> {}, and my first inclination towards debugging is to sprinkle code with
> PUT_LINEs, not breakpoints.  So I tend to get more worked up about the lack
> of standards and the differences between tool A and tool B, rather than
> spending all that much time analyzing tool A or tool B.

Actually, we seem to agree somewhat on that.  For example, see: 
http://tinyurl.com/2mr55

The time I really start to have a problem is when a tool is SO 
intrusive that I can't ignore its oddities or even think of a halfway 
reasonable excuse for them being the way they are.

[ ... ]

> The current may not be optimal (no arguments there) but it's functional, and
> it's consistent --  much like the McDonalds hamburger, it's consistent
> around the world - certainly not optimal, but consistent.

This, perhaps, summarizes the difference between us.  I'm pretty sure 
I haven't eaten a McDonalds hamburger in at least 10 years, and 
probably closer to 15.

I also don't agree with the idea that it's functional OR consistent 
-- and in fact, much of it's lack of functionality stems directly 
from the fact that it's INconsistent (aka modal).

-- 
    Later,
    Jerry.

The universe is a figment of its own imagination.
0
jcoffin1 (194)
5/16/2004 4:38:07 AM
In article news:<uVQUtcrOEHA.1340@TK2MSFTNGP12.phx.gbl>, Roy Fine wrote:
> I just got a brand new system, sporting a quad-zillion GHZ AMD
> processor with about that much memory, and now I am getting close
> to what I was getting circa 1992 with Zortec C++/vi/486DX2
> performance.

Hmm. I know how you feel. Hardware expectations keep going up (that is: 
the hardware that software suppliers expect you to have to run their 
stuff keeps getting fancier).

The manual on my shelf says "Zortech" (with an 'h'), BTW. I remember 
when they were Zorland (good job they didn't call themselves Zinprise, 
someone might have complained <smile>). That compiler was certainly 
pretty fast compared with some modern compilers (even when the latter 
are run on much more powerful platforms) ... but the "C++" it compiled 
was a far cry from today's standard. "generic.h" and all that.

The Zorland/Zortech comiler was written by Walter Bright, who is also 
responsible for the Digital Mars compiler. I've not tried that but it is 
said to be pretty quick.

> The current may not be optimal (no arguments there) but it's
> functional, and it's consistent ...

Everyone want a good IDE. Everyone will praise and applaud an IDE 
release that offers more than the previous version. Nobody likes an IDE 
release that offers less that the previous version (even if it offers 
more in some other feature).

For those of us who use *only* C++ there is no advantage in making the 
IDE more like that of VB, or making it use more code in common with the 
VB IDE -- frankly we couldn't give a fig if VB disappeared without trace 
never to be seen again (some of us would rejoice) -- all we want is for 
the C++ IDE to be as good as possible as a C++ IDE. We rejoice at steps 
forward toward this goal, we howl with complaint at steps in any 
contrary direction (be it toward a perfect C# IDE, or wherever).

I, personally, will suffer the VC7.x IDE reluctantly because it comes 
with a much better C++ compiler than that in VC6 ... but I'll howl with 
the rest at the good things from the C++ IDE that have been dropped.

I saw a quick preview of some of the features in VC-whatever-comes-next 
(VC8?) which they're calling "whidbey" (or some such stupid name that 
means nothing to anybody) at the ACCU conference last month. A lot of 
the changes have to do with extending the C++ language (in as 
unintrusive a way as possible) to make all the features of the CLI 
available through C++, but there do seem to be some new features in the 
IDE including much better class browsing (without having to compile the 
code first) and a limited amount of support for "refactoring" (by which 
they may only mean method renaming -- it wasn't clear). I hope this is 
an indication that MS is taking our comments seriously and trying to put 
the power back into the IDE. I suppose we'll find out in a month or two 
when the beta beta is due to become available.

Cheers,
 Daniel.
 

0
wastebasket (364)
5/16/2004 10:06:32 AM
Whenever I try to drill into a function using F11 I get a message 'No disk in 
Hard Drive'. I dismiss the dialog box a couple of times and it then works.

Apart from that, it seems OK

Rick Lee wrote:
> "Joseph M. Newcomer" wrote:
> 
> 
>> (SP6 came as a surprise to most of us),
> 
> 
> What does SP6 fix? I'm suspicious of updates. Sometimes they break something else.
> 
> Thanks,
> Rick
> 

0
isemmel (236)
5/16/2004 8:07:51 PM
Ditto to what you say, but it has never been fully explained (for me) just WHY 
they had to do a U-turn and upset everything.

A common IDE is a good idea, but usually in programming, you have to write code 
that fits into the user's environment, not tell the user "I've written this 
really good program. All you have to do is change the way you do everything". I 
can imagine the reaction from my customers if I tried this.

I think it would have been easier for MS to develop VS6 into something better 
than the path they chose. I think I remember something about some guru they got 
from Borland who decided that the VS7 approach was they way to go.

As far as changes, I would have liked something to be done with resources. The 
present way (been around forever) using #defines has always been a bit of a 
kludge in my opinion.

I would like resources to have names, which would allow for better code sharing. 
MFC could convert these "under the hood" to global values if that's what's needed.

How in VS7 do you get a convenient list of member variables you have defined as 
you can in VS6 in the 'Variables' tab of class wizard.

Why does the hourglass cursor come up when I hit F3 to search for the next 
occurrence of a string ? Something must be seriously wrong.

As far as support for VS6 goes, I think that the overwhelming majority are still 
using it. I don't think that there are many commercial applications around that 
demand the use of .NET, the main reason that VS7 was developed.

Joseph M. Newcomer wrote:

> Actually, the inboard help system sucks, too. I used to be able to tile the MSDN lib and
> VS6 so I could read both at once. This does not seem possible in VS7. I have not been able
> to figure out how to tile help and source code. I solved the problem by moving to a
> dual-monitor system and keeping a version of VS7 on the "other" monitor just to read the
> documentation (I don't use it for development, so what I get is an interface poorer than
> the original infobrowser that came with MSDN #1, but we've already pointed out to MS that
> the quality of their documentation browser has been declining for a dozen years, with each
> release being poorer than its predecessor).
> 
> Let's see: what would have improved VS6?
> 
> * Longer edit controls for things like control names, so we didn't have to use horizontal
> scrolling
> * Getting the Z-order of dialog layout right
> * Showing the entire string name in the STRINGTABLE, instead of having a fixed-size column
> that chops it off.
> * Supporting all the new methods, messages, etc. that have evolved since VS6 was delivered
> * Allowing WM_GETMINMAXINFO to be handled for dialog-based apps that have a resizing
> border
> * Keeping all control member variables protected instead of public
> * Allowing decent support so the ghastly editor could be replaced with a real editor
> * Use the clipboard for copy-and-paste of controls so they can be copied and pasted
> BETWEEN copies of visual studio
> * A more reliable NCB file mechanism
> * Multiprocess debugging
> * Saving settings INSTANTLY so if VS6 or the OS or hardware crashes, all customizations
> are maintained (instead of being lost), and if a customizatiion is made, it is instantly
> available in all versions of VS that are started, even before the version of VS in which
> the changes were made has not been closed (get rid of MS-DOS thinking, that people
> actually EXIT programs!)
> 
> I factor out the numerous improvements to the C compiler, MFC, etc. because these could
> have been done as readily with a VS6 interface.
> 
> What do I like about VS7?
> * The tabbed dialogs at the bottom of the screen so I can quickly switch views if I need
> to, e.g., having the call stack a single mouse click away.
> * Z-order on dialogs is fixed
> * I can make control variables protected (the default of 'public' is always wrong, of
> course; there is no sane reason to make control variables public)
> * Multiprocess debugging
> * There is one other thing I like, but I can't remember it
> 
> There is not room to list everything I detest about it.
> 
> OK, that exhausts my list, at least at the moment. So why didn't we just get these
> improvements? Because it became somebody's "toy project" to do a "new" interface that was
> an "improvement". As far as I can tell, the designer not once, not ever, wrote an MFC
> program or the defects would have been instantaneously visible. No usability studies were
> done with real programmers, or the results were ignored. A competent design review would
> have deep-sixed this design at its first meeting. And the abomination was actually allowed
> to escape the designer's office!
> 					joe
> 
> On Fri, 14 May 2004 12:07:31 -0600, Jerry Coffin <jcoffin@taeus.us> wrote:
> 
> 
>>In article <vp78a0lq7m2ol6e40rijbf427cf4dq7s91@4ax.com>, 
>>newcomer@flounder.com says...
>>
>>>It is a good question. A lot of us wonder the same thing. Bottom line: until VS6 actually
>>>stops running, we consider VS7 only as a last-ditch solution. Since effecitively it hasn't
>>>been supported in years (SP6 came as a surprise to most of us), it is not something we've
>>>been overly concerned with. The real pain is fhe difficulty people have in getting VS6,
>>>the last decent development environment Microsoft delivered. I have on client that went to
>>>VS7 because there was no way to get VS6, then a few weeks later ranted at me for three
>>>solid hours about how VS7 was unusable. 
>>
>>My advice would be to get them to buy MSDN Professional (or higher) 
>>which will get them copies of VS 6.
>>
>>My advice to Microsoft would be to start work on VS 8 by scrapping 
>>everything in VS 7.x, and starting over from VS 6.  The SOLE change 
>>in VS 7 that should be retained is having the option to keep the help 
>>system in-board.  Of course, from another viewpoint, that's not 
>>really a new feature of VS 7 either -- it's just going back to the 
>>way things were in VC++ 4.x.
>>
>>
>>>The worst part about the rant was that I could only agree with them on nearly 
>>>every point. Their project is one of the two VS7 projects I currently support.
>>
>>In this case, I should probably tone down my rhetoric in other 
>>threads -- if you have to support _any_ VS 7 projects, you deserve 
>>moral support, no matter how certain I might be that you're wrong.
>>
>>
>>>Besides the obvious failure to have applied a design review process (or even the most
>>>rudimentary of usability studies) to the VS7 interface, Microsoft's second worst mistake
>>>in the VS domain was discontinuing the availability of VS6. This is based on the premise
>>>that it is sound business practice to discontinue a successful product while replacing it
>>>with something that would fail a first-semester GUI design course. (I know someone who
>>>teaches GUI design, and I've often thought of telling him he should submit VS7 to his
>>>students and have the entire class critique its numerous catastrophic failures, and send
>>>the collection of student papers to Microsoft. Preferrably cced to Steve Ballmer).
>>
>>What have those students done to you, that you'd subject them to such 
>>a thing?  Personally, I think this would be unconstitutional: if 
>>convicted criminals are protected for cruel and unusual punishment, 
>>surly poor, possibly even innocent colleges students should be as 
>>well.
> 
> 
> Joseph M. Newcomer [MVP]
> email: newcomer@flounder.com
> Web: http://www.flounder.com
> MVP Tips: http://www.flounder.com/mvp_tips.htm

0
isemmel (236)
5/16/2004 8:35:25 PM
It is naive to assume those DLLs are present, and in the correct version. The only correct
way to install is to include them. You have merely been lucky, and you have been violating
the principles of how installers are supposed to work. So all you seem to be asking is a
way to get away with continuing to use bad install techniques.
					joe

On Sat, 15 May 2004 17:22:42 -0700, "Michael Leung" <Leung_@163.com> wrote:

>Programs written by VC6 are linked to MFC42.dll & MSVCR.dll. These two dll
>files are already in the system directory of the mainstream MS Windows. So
>we needn't copy them when distribute .exe files. But MFC71.dll & MSVCR.dll
>are NOT included in the OS, we had to copy or when run the programs produced
>by VC7, they will complain "can nont find certain dlls"...
>
>You can find mfc42.dll in your windows system directory. In my Win2K, they
>located in  C:\Winnt\system32.
>
>"Joseph M. Newcomer" <newcomer@flounder.com> wrote in message
>news:h39ba01jkrk7itfl6e0dicc30g78nll3n0@4ax.com...
>> But how is that different from VS6, where the size of the two DLLs is
>close to a megabyte?
>> joe
>>
>> On Sat, 15 May 2004 11:40:33 -0700, "Michael Leung" <Leung_@163.com>
>wrote:
>>
>> >I have just moved to VC7.0 and I'm now worrying many maintenance issues.
>In
>> >order to distribute .exe files written in VC7.0. It seems that we should
>> >copy the MFC71.dll & MSVCR71.dll. But isn't it very stupid  when the
>actual
>> >size of the .exe is xKB but the size of two dll is xMB?
>> >
>> >"CMXDev" <anonymous@discussions.microsoft.com> wrote in message
>> >news:95966B4B-8CFB-48BE-AC82-4028E90EB0BA@microsoft.com...
>> >> I have a huge VC++ 6 MFC application (exe and dlls).  How long will
>VC++ 6
>> >MFC be supported  by Microsoft....i.e. how long do I have before my
>> >application becomes unsupported and must be converted/rewritten to use
>.Net
>> >and/or MFC7?
>> >
>>
>> Joseph M. Newcomer [MVP]
>> email: newcomer@flounder.com
>> Web: http://www.flounder.com
>> MVP Tips: http://www.flounder.com/mvp_tips.htm
>

Joseph M. Newcomer [MVP]
email: newcomer@flounder.com
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm
0
newcomer (15974)
5/17/2004 3:42:14 AM
Which, of course, gives you an executable of massive size, thus not solving the problem,
but the poster seems to think that including the DLLs was not required (it was always
required for a conforming installer to include the DLLs, so the correct DLLs would always
be installed)
				joe

On Sat, 15 May 2004 16:44:31 -0700, jamos@technotoys.com (Jim) wrote:

>> I have just moved to VC7.0 and I'm now worrying many maintenance issues. In
>> order to distribute .exe files written in VC7.0. It seems that we should
>> copy the MFC71.dll & MSVCR71.dll. But isn't it very stupid  when the actual
>> size of the .exe is xKB but the size of two dll is xMB?
>
>You can avoid this by linking statically.

Joseph M. Newcomer [MVP]
email: newcomer@flounder.com
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm
0
newcomer (15974)
5/17/2004 3:46:06 AM
Thanks for the pointer on the docking. OF COURSE this was "intuitively obvious".

Horizontal scrolling sucks as an interface. For one thing, you can't see all of the name
without scrolling, which is a really bad idea. Then if you click on the name, say,
IDC_THIS_IS_A_CONTROL between the I and S of THIS, it selects everything, moves the
contents of the window around, and ends up selecting some other part of the name.

The Z-order for over a dozen years was opposite at runtime and design time, and the design
time was the wrong order. So if you wanted to make a static control be behind a group of
controls, you had to put it in front of them at design time. This is so pitiful that it is
amazing it took so many years to fix.

The point about selecting the message filter is that for some reason the key information
for resetting the message filter is hidden, so it is not an invertible operation. You
can't go back. So it is a real pain to (a) have to do this when it is obvious that it
should be done automatically and (b) impossible to undo it and get back the correct
dialog.

Compare the control files produced; I forget which file it is. Information is lost in a
non-recoverable fashion.
				joe

On Fri, 14 May 2004 22:12:00 -0700, "Alexander Grigoriev" <alegr@earthlink.net> wrote:

>"Joseph M. Newcomer" <newcomer@flounder.com> wrote in message
>news:0j5aa0pgce6l12k3kebg1iegpam82shmpe@4ax.com...
>> Actually, the inboard help system sucks, too. I used to be able to tile
>the MSDN lib and
>> VS6 so I could read both at once. This does not seem possible in VS7. I
>have not been able
>> to figure out how to tile help and source code. I solved the problem by
>moving to a
>
>Three ways:
>1. Right click on the help window tab header. Check "Floating", then
>"Dockable". You can then dock the help window together with task List, Find
>Results, etc.
>or 2. Right click ot the tab header. Select New horizontal tab group.
>or 3. Tools->Options->Help->External help. You can then move help window to
>another monitor.
>
>> dual-monitor system and keeping a version of VS7 on the "other" monitor
>just to read the
>> documentation (I don't use it for development, so what I get is an
>interface poorer than
>> the original infobrowser that came with MSDN #1, but we've already pointed
>out to MS that
>> the quality of their documentation browser has been declining for a dozen
>years, with each
>> release being poorer than its predecessor).
>>
>> Let's see: what would have improved VS6?
>>
>> * Longer edit controls for things like control names, so we didn't have to
>use horizontal
>> scrolling
>> * Getting the Z-order of dialog layout right
>
>What was wrong with it?
>
>> * Showing the entire string name in the STRINGTABLE, instead of having a
>fixed-size column
>> that chops it off.
>> * Supporting all the new methods, messages, etc. that have evolved since
>VS6 was delivered
>> * Allowing WM_GETMINMAXINFO to be handled for dialog-based apps that have
>a resizing
>> border
>
>Select CWnd message filter.
>
>I also add: Allow to select font for binary editor view.
>

Joseph M. Newcomer [MVP]
email: newcomer@flounder.com
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm
0
newcomer (15974)
5/17/2004 3:51:34 AM
I've gotten this message as well, and I haven't installed SP6. I've not had it on my
machine, but on many customer machines, and this was long before SP6 was released.
				joe

On Sun, 16 May 2004 20:07:51 GMT, Ian Semmel <isemmel@removejunkmailrocketcomp.com.au>
wrote:

>Whenever I try to drill into a function using F11 I get a message 'No disk in 
>Hard Drive'. I dismiss the dialog box a couple of times and it then works.
>
>Apart from that, it seems OK
>
>Rick Lee wrote:
>> "Joseph M. Newcomer" wrote:
>> 
>> 
>>> (SP6 came as a surprise to most of us),
>> 
>> 
>> What does SP6 fix? I'm suspicious of updates. Sometimes they break something else.
>> 
>> Thanks,
>> Rick
>> 

Joseph M. Newcomer [MVP]
email: newcomer@flounder.com
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm
0
newcomer (15974)
5/17/2004 3:55:55 AM
On Sun, 16 May 2004 23:42:14 -0400, Joseph M. Newcomer <newcomer@flounder.com> wrote:

> It is naive to assume those DLLs are present, and in the correct version. The only correct
> way to install is to include them.

To stray from the original topic a tad bit more, have you ever done a search on your system for files matching the patten "mfc*.dll"? Always interesting to see just how many times and under how many different names the MFC dlls have been installed. It's also a "finger in the wind" way to see if an app you use has migrated to VS 7.

The total storage used for the dlls actually was not as bad as I feared. Only around 23MB on my Win2K system (leaving out the copies that are in VS 6 and the MS SDK).

-irrational john
0
5/17/2004 6:00:19 AM
Ian,

"Ian Semmel" <isemmel@removejunkmailrocketcomp.com.au> a �crit dans le
message de news:hgQpc.42313$TT.2629@news-server.bigpond.net.au...
<snip>
> I would like resources to have names, which would allow for better code
sharing.
> MFC could convert these "under the hood" to global values if that's what's
needed.
>

In fact, they do. Actually, you'll have to go through an extra step using
#defined identifiers (MAKEINTRESOURCE), but this is hidden from you by MFC.
The environment allows you to identify resources by name, however.

Johan Rosengren
Abstrakt Mekanik AB

<snip>


0
5/17/2004 6:38:58 AM
In article news:<2ddga0t6734shgifsjl7brb3qshkqlficp@4ax.com>, Joseph M. 
Newcomer wrote:
> Thanks for the pointer on the docking. OF COURSE this was
> "intuitively obvious".

Hmm. I think you mean that ironically ... but to anyone who has grooked 
the dockability aspect of so many of the IDE windows it actually is 
obvious. What's poor is that the designers of the IDE apparently 
thought that window dockability was obvious, and so didn't draw 
attention to it -- or the things you can do with it -- in the 
help/docs.

[As an aside: I've recently been looking at the Eclipse Open Source IDE 
for Java, which supports the concept of "perspectives". A perspective 
is a user-definable set of child-window layouts and positions. A 
project can have many perspectives defined, and by switching from one 
perspective to another the user can quickly change the set of windows 
displayed and their positions within the parent frame. It seems very 
powerful.]

> Horizontal scrolling sucks as an interface. For one thing, you can't
> see all of the name without scrolling, which is a really bad idea.

I agree with you there. The solution isn't just to have larger edit 
controls for the display of long items but to make all the dialogs that 
hold such edit controls resizable, and have the controls grow with the 
dialog. It's really not that hard to do (have a look at the way sizers 
are implemented in the wxWidgets library) and IMHO *should* have been a 
standard feature of the native dialogs in Windows.

Cheers,
 Daniel.
 


0
wastebasket (364)
5/17/2004 10:03:35 AM
In article news:<hgQpc.42313$TT.2629@news-server.bigpond.net.au>, Ian 
Semmel wrote:
> A common IDE is a good idea, but usually in programming, you have
> to write code that fits into the user's environment, not tell the
> user "I've written this really good program. All you have to do is
> change the way you do everything". I can imagine the reaction from
> my customers if I tried this.
> 
> I think it would have been easier for MS to develop VS6 into
> something better than the path they chose. I think I remember
> something about some guru they got from Borland who decided that
> the VS7 approach was they way to go.

The thing they got wrong was thinking that it would be "real cool" to 
have the *same* environment for Visual C, Visial Basic, and Visual 
Whatever, rather than separate environments for each language that 
would do what made sense for that language. I believe they had a 
considerable amount of feedback from customers who used both VB and VC, 
for example, saying that they'd like to use the same IDE for all 
development. I don't believe the people making that request thought for 
a minute that the result would be a lowest-common-denominator IDE that 
met fewer of their needs than the existing IDEs.

I can see a lot of advantages in having an IDE that can handle a 
project that includes some buildable applications that are in C++ and 
some that are in VB (and maybe some that are in Haskell, or Prolog, or 
Ada...) and being able to edit all the sources side-by-side in a common 
environment. Such an environment would have common code to handle 
things that were common to all types of programming (text editing, 
window management, build control) and language specific code (maybe 
implemented as a set of plugins) that would handle specific things for 
different languages (syntax highlighting, context-sensitive editing 
features, wizards, etc.). It's not rocket science, but one does have to 
think about what's needed.

> As far as changes, I would have liked something to be done with
> resources. The present way (been around forever) using #defines has
> always been a bit of a kludge in my opinion.

You can't change *too* much of the way resources are handled without 
changing the format of the executable file. A bit more wizard-style 
help wouldn't go amiss, though. 

I'd like to see IDE support for importing dialogs and other resources 
from another project (including the resource ID definitions, with 
automatic reallocation of ID values where they clash) and I'd like to 
see some provision for managing multiple string tables automatically -- 
or at least for allocating resource ID values within specified ranges.

That is, for example, I'd like to keep all the help strings and all the 
menu text strings in my application grouped together; both by location 
in the resource files and by ID value. I can do that by deliberately 
setting certain strings to have given resource IDs and always adding 
new strings of the same type at the correct place in the string table - 
but it's the very devil to set straight again when some clown doing a 
bugfix ignores the rules and adds a few new strings of both types at 
the end of the table. I'd like the IDE to be able to sort that out for 
me automagically.

It'd be nice if the IDE could manage conditional blocks in resource 
files, too, so that (say) a dialog template or a version resource could 
have extra fields in debug and release builds.

Cheers,
 Daniel.
 



0
wastebasket (364)
5/17/2004 10:03:36 AM
"Daniel James" <wastebasket@nospam.aaisp.org> wrote in message
news:VA.000006a9.0278b880@nospam.aaisp.org...
> In article news:<hgQpc.42313$TT.2629@news-server.bigpond.net.au>, Ian
> Semmel wrote:
> > A common IDE is a good idea, but usually in programming, you have
> > to write code that fits into the user's environment, not tell the
> > user "I've written this really good program. All you have to do is
> > change the way you do everything". I can imagine the reaction from
> > my customers if I tried this.
> >
> > I think it would have been easier for MS to develop VS6 into
> > something better than the path they chose. I think I remember
> > something about some guru they got from Borland who decided that
> > the VS7 approach was they way to go.
>
> The thing they got wrong was thinking that it would be "real cool" to
> have the *same* environment for Visual C, Visial Basic, and Visual
> Whatever, rather than separate environments for each language that
> would do what made sense for that language.


Unfortunately -- the answer is in the numbers -- with a 10:1 (or higher)
ratio of VB programmers to VC++ programmers, we should feel fortunate that
there is a VC++7  :)

rlf


0
rlfine8815 (162)
5/17/2004 12:22:57 PM
It is worth noting that Eclipse is developing a C/C++ version. Folks at Microsoft should
note this effort. Sun may not become the only company which is Eclipsed...

(Friends who have beta-release versions of Eclipse for C/C++ say it is what an IDE SHOULD
be--perhaps the first instance of a user interface in the Unix world that shows actual
DESIGN instead of being thrown together by a couple grad students late at night).

And yes, I agree that making resizable dialogs would have been intelligent. But how can
you expect such an incredible leap of design faith from people who have edit controls that
are supposed to contain C/C++ language symbols and actually allow characters other than
0-9A-Za-z_ to be typed in? Having an annoying dialog box pop up (when you shift focus
away) that tells you that the synbol contains illegal characters is amateurish. If they
were illegal, why could they be typed in the first place?
					joe

On Mon, 17 May 2004 11:03:35 +0100, Daniel James <wastebasket@nospam.aaisp.org> wrote:

>In article news:<2ddga0t6734shgifsjl7brb3qshkqlficp@4ax.com>, Joseph M. 
>Newcomer wrote:
>> Thanks for the pointer on the docking. OF COURSE this was
>> "intuitively obvious".
>
>Hmm. I think you mean that ironically ... but to anyone who has grooked 
>the dockability aspect of so many of the IDE windows it actually is 
>obvious. What's poor is that the designers of the IDE apparently 
>thought that window dockability was obvious, and so didn't draw 
>attention to it -- or the things you can do with it -- in the 
>help/docs.
>
>[As an aside: I've recently been looking at the Eclipse Open Source IDE 
>for Java, which supports the concept of "perspectives". A perspective 
>is a user-definable set of child-window layouts and positions. A 
>project can have many perspectives defined, and by switching from one 
>perspective to another the user can quickly change the set of windows 
>displayed and their positions within the parent frame. It seems very 
>powerful.]
>
>> Horizontal scrolling sucks as an interface. For one thing, you can't
>> see all of the name without scrolling, which is a really bad idea.
>
>I agree with you there. The solution isn't just to have larger edit 
>controls for the display of long items but to make all the dialogs that 
>hold such edit controls resizable, and have the controls grow with the 
>dialog. It's really not that hard to do (have a look at the way sizers 
>are implemented in the wxWidgets library) and IMHO *should* have been a 
>standard feature of the native dialogs in Windows.
>
>Cheers,
> Daniel.
> 
>

Joseph M. Newcomer [MVP]
email: newcomer@flounder.com
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm
0
newcomer (15974)
5/17/2004 2:27:44 PM
A small, single-exe program is better linked with static MFC. Reduces
support pain a lot.

"Michael Leung" <Leung_@163.com> wrote in message
news:%23%23Zh2EAPEHA.1348@TK2MSFTNGP12.phx.gbl...
> Thanks for all your advice.
>
> In fact, I really have found many programs produced by  VC6 (which can by
> dectected by Dependency Walker) did NOT copy the dlls. These programs is
> relatively small (xKB ~ xMB) and lots of them are freeware or shareware.
And
> even the AutoCAD2000 which really link to MFC42.dll did not copy the dll.
>
> And I personally think that for LARGE and COMMERCIAL programs, it is
> neccessary to copy the dlls. But for very small and no-such important
..exes,
> it becomes a philosophical issue, it depends on the author's attitude
about
> this question. I assure there are few  people who like to include MB dlls
> while the distributed program  is KB in size.
>
> To be or NOT to be, that is a question. :)
>
> Best Regards,
> Michael Leung
>
>
> "Joseph M. Newcomer" <newcomer@flounder.com> wrote in message
> news:v1dga0dd5d0u3ljndre2m9gqjc34ns42g1@4ax.com...
> > It is naive to assume those DLLs are present, and in the correct
version.
> The only correct
> > way to install is to include them. You have merely been lucky, and you
> have been violating
> > the principles of how installers are supposed to work. So all you seem
to
> be asking is a
> > way to get away with continuing to use bad install techniques.
> > joe
> >
> > On Sat, 15 May 2004 17:22:42 -0700, "Michael Leung" <Leung_@163.com>
> wrote:
> >
> > >Programs written by VC6 are linked to MFC42.dll & MSVCR.dll. These two
> dll
> > >files are already in the system directory of the mainstream MS Windows.
> So
> > >we needn't copy them when distribute .exe files. But MFC71.dll &
> MSVCR.dll
> > >are NOT included in the OS, we had to copy or when run the programs
> produced
> > >by VC7, they will complain "can nont find certain dlls"...
> > >
> > >You can find mfc42.dll in your windows system directory. In my Win2K,
> they
> > >located in  C:\Winnt\system32.
> > >
> > >"Joseph M. Newcomer" <newcomer@flounder.com> wrote in message
> > >news:h39ba01jkrk7itfl6e0dicc30g78nll3n0@4ax.com...
> > >> But how is that different from VS6, where the size of the two DLLs is
> > >close to a megabyte?
> > >> joe
> > >>
> > >> On Sat, 15 May 2004 11:40:33 -0700, "Michael Leung" <Leung_@163.com>
> > >wrote:
> > >>
> > >> >I have just moved to VC7.0 and I'm now worrying many maintenance
> issues.
> > >In
> > >> >order to distribute .exe files written in VC7.0. It seems that we
> should
> > >> >copy the MFC71.dll & MSVCR71.dll. But isn't it very stupid  when the
> > >actual
> > >> >size of the .exe is xKB but the size of two dll is xMB?
> > >> >
> > >> >"CMXDev" <anonymous@discussions.microsoft.com> wrote in message
> > >> >news:95966B4B-8CFB-48BE-AC82-4028E90EB0BA@microsoft.com...
> > >> >> I have a huge VC++ 6 MFC application (exe and dlls).  How long
will
> > >VC++ 6
> > >> >MFC be supported  by Microsoft....i.e. how long do I have before my
> > >> >application becomes unsupported and must be converted/rewritten to
use
> > >.Net
> > >> >and/or MFC7?
> > >> >
> > >>
> > >> Joseph M. Newcomer [MVP]
> > >> email: newcomer@flounder.com
> > >> Web: http://www.flounder.com
> > >> MVP Tips: http://www.flounder.com/mvp_tips.htm
> > >
> >
> > Joseph M. Newcomer [MVP]
> > email: newcomer@flounder.com
> > Web: http://www.flounder.com
> > MVP Tips: http://www.flounder.com/mvp_tips.htm
>
>


0
alegr (1131)
5/17/2004 3:35:45 PM
Hi all,

VC7 is an odd one. They are now giving the compiler away without an IDE. I 
have no idea what this means. Does MS want more VC programmers out there? 
Does MS want to sway the VC market to 7 with newcomers (no pun intended)?

There are three major parts to this: the IDE, the compiler / linkers (with 
support tools) and .Net.

IDE:

I tend to look at this whole .Net thing from a distance: the IDE is 
disgusting for VC. For ASP it is good because ASP has improved so 
substantially. For VB it is a great improvement - there are tons of new 
features in the IDE that VB programmers did not have before.

One unified IDE sensible. VS laid the foundations for this in its 
architecture. The VB IDE had meandered along over the years with only one 
major improvement - to MDI. Why learn several IDE's when one architecturally 
strong IDE is all that is needed?

Compilers:

It is well known that the V7 compilers are stronger in many areas - 
particularly VC6 code. The bugs that are most apparent are in the '7' 
implementations - attributed programming and the like.

..Net

..Net for ASP is a huge improvement. For VB Programmers it is a new 
language - each and every VB progammer has to effectively learn a new 
language. For C++ the core language hasn't changed much but...

Looking into .Net from several perspectives gives only 1 major point of 
apprehension for me: essentially all the '7' variant languages (IE managed 
code) are new languages - VC7 managed code is a totally different language 
but thankfully a superset of the existing C++. What standards adherence is 
there / will there be and which other compiler vendors are coming to the 
party supporting managed code so reinforcing the language changes? Are the 
languages changes just a fad?

The positives in the new language (singular I.E. the CLR) is that there are 
very substantial extensions to the 'class library'. So many new facilities 
are in there that make the programmers life more productive and easier, that 
to ignore them is to risk living in the dark ages. The new facilities for 
the C++ (or VB or C#) programmer are powerful tools which when compared to 
current methods of low level coding make current coding look like plodding 
around in assembler - highly unproductive, slow to code, many lines of code 
to achieve a task and so a high risk of bugs. Take a look at the ease of 
integrating say: Event Logging, Performance Monitor metrics, Services (web 
and system), MSI Installer integration, NUnit - JUnit style test 
orchistration, very very substantial Security related improvements - and 
these are only *my* favourites.

The point I wish to make is to not steer away from .Net because you dislike 
the IDE.

Getting back to the original question... Having written a substantial amount 
of VC6 code, I too am concerned about the longevity of the product. It is 
easy enough in my own experience to 'port' to VC7, but that is not an 
answer. The services that VC6 is built upon are more worrying. For example: 
ADO and ODBC. It would be near impossible for MS to drop ODBC. ADO has 
already been superceeded by ADO.Net - when will support for classic ADO end? 
What happens when the new fangled highly secure OS versions come out that 
are .Net integrated - will running any non .Net / CLR programs be 
non-conformant of security standards or has MS had the foresight of being 
able to wrap these systems in safe containers?

I am enormously concerned about MS ability to deliver a supposed Enterprise 
class language that will have a support life time sufficient to justify 
writing large applications - applications that are legacy by nature. I can 
see COBOL people with a smile on their faces. Until I see stability in the 
future direction of the IDE I can not see stability in the core language - 
as separate as they may be.

- Tim


"Roy Fine" <rlfine@twt.obfuscate.net> wrote in message 
news:ecxw7oAPEHA.644@tk2msftngp13.phx.gbl...
>
> "Daniel James" <wastebasket@nospam.aaisp.org> wrote in message
> news:VA.000006a9.0278b880@nospam.aaisp.org...
>> In article news:<hgQpc.42313$TT.2629@news-server.bigpond.net.au>, Ian
>> Semmel wrote:
>> > A common IDE is a good idea, but usually in programming, you have
>> > to write code that fits into the user's environment, not tell the
>> > user "I've written this really good program. All you have to do is
>> > change the way you do everything". I can imagine the reaction from
>> > my customers if I tried this.
>> >
>> > I think it would have been easier for MS to develop VS6 into
>> > something better than the path they chose. I think I remember
>> > something about some guru they got from Borland who decided that
>> > the VS7 approach was they way to go.
>>
>> The thing they got wrong was thinking that it would be "real cool" to
>> have the *same* environment for Visual C, Visial Basic, and Visual
>> Whatever, rather than separate environments for each language that
>> would do what made sense for that language.
>
>
> Unfortunately -- the answer is in the numbers -- with a 10:1 (or higher)
> ratio of VB programmers to VC++ programmers, we should feel fortunate that
> there is a VC++7  :)
>
> rlf
>
> 


0
Tim
5/17/2004 11:32:34 PM
Hi Tim,

"Tim" <Tim@NoSpam> wrote in message
news:Os97DdGPEHA.3896@TK2MSFTNGP12.phx.gbl...

> VC7 is an odd one. They are now giving the compiler away without an IDE. I
> have no idea what this means. Does MS want more VC programmers out there?
> Does MS want to sway the VC market to 7 with newcomers (no pun intended)?

I don't know about getting the compiler without the IDE, but I do know that
Microsoft wants people to move to the newer platforms.

> IDE:
>
> I tend to look at this whole .Net thing from a distance: the IDE is
> disgusting for VC. For ASP it is good because ASP has improved so
> substantially. For VB it is a great improvement - there are tons of new
> features in the IDE that VB programmers did not have before.

I've been using the new IDE for a while now and I've grown to like it.  You
are right that it is different, but there are some advantages especially for
those of us who use different languages so I think it is worth the effort to
get used to it.

> One unified IDE sensible. VS laid the foundations for this in its
> architecture. The VB IDE had meandered along over the years with only one
> major improvement - to MDI. Why learn several IDE's when one
architecturally
> strong IDE is all that is needed?

I don't know who's choice the direction was, but it is what it is today and
it's not going to change back :o)

> Getting back to the original question... Having written a substantial
amount
> of VC6 code, I too am concerned about the longevity of the product. It is
> easy enough in my own experience to 'port' to VC7, but that is not an
> answer. The services that VC6 is built upon are more worrying. For
example:
> ADO and ODBC.

I've ported a couple of project from V6 to V7.1 now (if you can really call
it porting) and it wasn't all that big of deal.  These were substantial
applications with serious user interface.  There were a few glitches to work
around, libraries to recompile, etc., but I'm glad to have them in the new
world.
>
> - Tim
>
Tom


0
tserface (3860)
5/18/2004 12:12:35 AM
<big snip>

> I've ported a couple of project from V6 to V7.1 now (if you can really 
> call
> it porting) and it wasn't all that big of deal.  These were substantial
> applications with serious user interface.  There were a few glitches to 
> work
> around, libraries to recompile, etc., but I'm glad to have them in the new
> world.

Ditto. It was a non event here to. We are still on VC6, have conditional 
compile code or structured comments that detail *all* the amendments needed 
to move to V7 and have removed a couple of bugs not seen by the V6 compiler 
or us humans. (This was rehearsed and took very little time given the volume 
of code).

However this transitions one to VC7 only. It is not a rewrite to .Net with 
managed code and so the benefits of .Net are not yet achieved.

So why wait? Extensive Testing. The IDE. V7 runtime deployment - bug 
isolation to V7 installation, & a lack of confidence. Also, no hurry either.

Interestingly, given all this hestitation / procrastination, it is not 
stopping us from including .Net functionality in the V6 product - (IE 
cryptography is so much easier in .Net) what do they call it? Interop or 
something...

- Tim


0
Tim
5/18/2004 12:40:07 AM
Thanks for all your advice.

In fact, I really have found many programs produced by  VC6 (which can by
dectected by Dependency Walker) did NOT copy the dlls. These programs is
relatively small (xKB ~ xMB) and lots of them are freeware or shareware. And
even the AutoCAD2000 which really link to MFC42.dll did not copy the dll.

And I personally think that for LARGE and COMMERCIAL programs, it is
neccessary to copy the dlls. But for very small and no-such important .exes,
it becomes a philosophical issue, it depends on the author's attitude about
this question. I assure there are few  people who like to include MB dlls
while the distributed program  is KB in size.

To be or NOT to be, that is a question. :)

Best Regards,
Michael Leung


"Joseph M. Newcomer" <newcomer@flounder.com> wrote in message
news:v1dga0dd5d0u3ljndre2m9gqjc34ns42g1@4ax.com...
> It is naive to assume those DLLs are present, and in the correct version.
The only correct
> way to install is to include them. You have merely been lucky, and you
have been violating
> the principles of how installers are supposed to work. So all you seem to
be asking is a
> way to get away with continuing to use bad install techniques.
> joe
>
> On Sat, 15 May 2004 17:22:42 -0700, "Michael Leung" <Leung_@163.com>
wrote:
>
> >Programs written by VC6 are linked to MFC42.dll & MSVCR.dll. These two
dll
> >files are already in the system directory of the mainstream MS Windows.
So
> >we needn't copy them when distribute .exe files. But MFC71.dll &
MSVCR.dll
> >are NOT included in the OS, we had to copy or when run the programs
produced
> >by VC7, they will complain "can nont find certain dlls"...
> >
> >You can find mfc42.dll in your windows system directory. In my Win2K,
they
> >located in  C:\Winnt\system32.
> >
> >"Joseph M. Newcomer" <newcomer@flounder.com> wrote in message
> >news:h39ba01jkrk7itfl6e0dicc30g78nll3n0@4ax.com...
> >> But how is that different from VS6, where the size of the two DLLs is
> >close to a megabyte?
> >> joe
> >>
> >> On Sat, 15 May 2004 11:40:33 -0700, "Michael Leung" <Leung_@163.com>
> >wrote:
> >>
> >> >I have just moved to VC7.0 and I'm now worrying many maintenance
issues.
> >In
> >> >order to distribute .exe files written in VC7.0. It seems that we
should
> >> >copy the MFC71.dll & MSVCR71.dll. But isn't it very stupid  when the
> >actual
> >> >size of the .exe is xKB but the size of two dll is xMB?
> >> >
> >> >"CMXDev" <anonymous@discussions.microsoft.com> wrote in message
> >> >news:95966B4B-8CFB-48BE-AC82-4028E90EB0BA@microsoft.com...
> >> >> I have a huge VC++ 6 MFC application (exe and dlls).  How long will
> >VC++ 6
> >> >MFC be supported  by Microsoft....i.e. how long do I have before my
> >> >application becomes unsupported and must be converted/rewritten to use
> >.Net
> >> >and/or MFC7?
> >> >
> >>
> >> Joseph M. Newcomer [MVP]
> >> email: newcomer@flounder.com
> >> Web: http://www.flounder.com
> >> MVP Tips: http://www.flounder.com/mvp_tips.htm
> >
>
> Joseph M. Newcomer [MVP]
> email: newcomer@flounder.com
> Web: http://www.flounder.com
> MVP Tips: http://www.flounder.com/mvp_tips.htm


0
Michael
5/18/2004 2:25:57 AM
See below...
On Sun, 16 May 2004 20:35:25 GMT, Ian Semmel <isemmel@removejunkmailrocketcomp.com.au>
wrote:

>Ditto to what you say, but it has never been fully explained (for me) just WHY 
>they had to do a U-turn and upset everything.
****
As far as I can tell, because Somebody Had A Vision. And no one had the sense to squash
him at the beginning, By the time this got into beta, the decision to build such a crappy
interface was unrecoverable. I gave up being a beta tester years ago, because all MS wants
us to do is debug the software. No feedback about the design was ever considered valid,
and nothing ever made it into the product release or the next release because a beta
tester said "This design sucks". So I found little point to continuing. (Not to mention
the fact that they would send us a beta for a product called GLORP or some other cute
internal name, and never once explain what GLORP was, or why I would care to beta test
it!)
****
>
>A common IDE is a good idea, but usually in programming, you have to write code 
>that fits into the user's environment, not tell the user "I've written this 
>really good program. All you have to do is change the way you do everything". I 
>can imagine the reaction from my customers if I tried this.
*****
The designer of VS7 probably got a stock bonus for this abomination. There Ain't No
Justice. The rest of us would be told to get our resumes in order, as our careers with
whatever company employs us would be in jeopardy, and deservedly so.
*****
>
>I think it would have been easier for MS to develop VS6 into something better 
>than the path they chose. I think I remember something about some guru they got 
>from Borland who decided that the VS7 approach was they way to go.
****
Borland's final revenge on Microsoft? Perhaps the reason Borland went downhill so fast was
their products looked like VS7?
****
>
>As far as changes, I would have liked something to be done with resources. The 
>present way (been around forever) using #defines has always been a bit of a 
>kludge in my opinion.
*****
How so? It is no more a kludge than the use of #define to define any other constant.
*****
>
>I would like resources to have names, which would allow for better code sharing. 
>MFC could convert these "under the hood" to global values if that's what's needed.
*****
Resources have always had names. They're just hard to use. Any resource whose name is not
preprocessed into an integer by having a suitable #define is named with the literal string
that is its name. This has been true since Windows 1.0.

But it doesn't allow better code-sharing. What WOULD allow better code-sharing is if you
could separately compile .rc files and link .res files together, using link-time
resolution for the names instead of compile-time resolution for the names. Then you could,
as many people have asked for, put resources into .lib files (after all, .res files are
just in COFF format, so all the mechanisms are already in place!)

Like most really useful features needed for large-scale development, this seems to have
escaped the Microsoft developers' attention for nearly 20 years. Instead, we are given
ActiveX, a gratuitously complex solution to a simple problem. Note that C# gets rid of the
resource problem by not having any resources (yep! They create thousands of lines of code
that create the forms on the fly!)
*****
>
>How in VS7 do you get a convenient list of member variables you have defined as 
>you can in VS6 in the 'Variables' tab of class wizard.
*****
WHAT? YOU WANT A USEFUL FEATURE LIKE THIS! SHAME ON YOU! (I agree; the VS7 model is a
seriously defective way of handling this. I can't look and say "What controls don't have
variables attached", or add the variables quickly with one incarnation of the add-variable
wizard. A wizard that takes 2 seconds to invoke on a 2GHz dual processor is beneath
contempt. Another of the massive steps-backward that VS7 took, and again one of the many
reasons I am convinced the designer never actually wrote an MFC program in his life, or he
would know that this is an important feature!)
*****
>
>Why does the hourglass cursor come up when I hit F3 to search for the next 
>occurrence of a string ? Something must be seriously wrong.
*****
It's VS7. ANYTHING can be construed as "seriously wrong" and you would be correct! It is
SO SLOW. After years of making the compilers and environments faster and faster, I get one
that is SLOWER on my 2GHz dual processor than VS6 was on my 500MHz uniprocessor!
*****
>
>As far as support for VS6 goes, I think that the overwhelming majority are still 
>using it. I don't think that there are many commercial applications around that 
>demand the use of .NET, the main reason that VS7 was developed.
*****
There is nothing in the VS7 interface that supports .NET that can explain the systematic
destruction of a useful interface.
*****
>
>Joseph M. Newcomer wrote:
>
>> Actually, the inboard help system sucks, too. I used to be able to tile the MSDN lib and
>> VS6 so I could read both at once. This does not seem possible in VS7. I have not been able
>> to figure out how to tile help and source code. I solved the problem by moving to a
>> dual-monitor system and keeping a version of VS7 on the "other" monitor just to read the
>> documentation (I don't use it for development, so what I get is an interface poorer than
>> the original infobrowser that came with MSDN #1, but we've already pointed out to MS that
>> the quality of their documentation browser has been declining for a dozen years, with each
>> release being poorer than its predecessor).
>> 
>> Let's see: what would have improved VS6?
>> 
>> * Longer edit controls for things like control names, so we didn't have to use horizontal
>> scrolling
>> * Getting the Z-order of dialog layout right
>> * Showing the entire string name in the STRINGTABLE, instead of having a fixed-size column
>> that chops it off.
>> * Supporting all the new methods, messages, etc. that have evolved since VS6 was delivered
>> * Allowing WM_GETMINMAXINFO to be handled for dialog-based apps that have a resizing
>> border
>> * Keeping all control member variables protected instead of public
>> * Allowing decent support so the ghastly editor could be replaced with a real editor
>> * Use the clipboard for copy-and-paste of controls so they can be copied and pasted
>> BETWEEN copies of visual studio
>> * A more reliable NCB file mechanism
>> * Multiprocess debugging
>> * Saving settings INSTANTLY so if VS6 or the OS or hardware crashes, all customizations
>> are maintained (instead of being lost), and if a customizatiion is made, it is instantly
>> available in all versions of VS that are started, even before the version of VS in which
>> the changes were made has not been closed (get rid of MS-DOS thinking, that people
>> actually EXIT programs!)
>> 
>> I factor out the numerous improvements to the C compiler, MFC, etc. because these could
>> have been done as readily with a VS6 interface.
>> 
>> What do I like about VS7?
>> * The tabbed dialogs at the bottom of the screen so I can quickly switch views if I need
>> to, e.g., having the call stack a single mouse click away.
>> * Z-order on dialogs is fixed
>> * I can make control variables protected (the default of 'public' is always wrong, of
>> course; there is no sane reason to make control variables public)
>> * Multiprocess debugging
>> * There is one other thing I like, but I can't remember it
>> 
>> There is not room to list everything I detest about it.
>> 
>> OK, that exhausts my list, at least at the moment. So why didn't we just get these
>> improvements? Because it became somebody's "toy project" to do a "new" interface that was
>> an "improvement". As far as I can tell, the designer not once, not ever, wrote an MFC
>> program or the defects would have been instantaneously visible. No usability studies were
>> done with real programmers, or the results were ignored. A competent design review would
>> have deep-sixed this design at its first meeting. And the abomination was actually allowed
>> to escape the designer's office!
>> 					joe
>> 
>> On Fri, 14 May 2004 12:07:31 -0600, Jerry Coffin <jcoffin@taeus.us> wrote:
>> 
>> 
>>>In article <vp78a0lq7m2ol6e40rijbf427cf4dq7s91@4ax.com>, 
>>>newcomer@flounder.com says...
>>>
>>>>It is a good question. A lot of us wonder the same thing. Bottom line: until VS6 actually
>>>>stops running, we consider VS7 only as a last-ditch solution. Since effecitively it hasn't
>>>>been supported in years (SP6 came as a surprise to most of us), it is not something we've
>>>>been overly concerned with. The real pain is fhe difficulty people have in getting VS6,
>>>>the last decent development environment Microsoft delivered. I have on client that went to
>>>>VS7 because there was no way to get VS6, then a few weeks later ranted at me for three
>>>>solid hours about how VS7 was unusable. 
>>>
>>>My advice would be to get them to buy MSDN Professional (or higher) 
>>>which will get them copies of VS 6.
>>>
>>>My advice to Microsoft would be to start work on VS 8 by scrapping 
>>>everything in VS 7.x, and starting over from VS 6.  The SOLE change 
>>>in VS 7 that should be retained is having the option to keep the help 
>>>system in-board.  Of course, from another viewpoint, that's not 
>>>really a new feature of VS 7 either -- it's just going back to the 
>>>way things were in VC++ 4.x.
>>>
>>>
>>>>The worst part about the rant was that I could only agree with them on nearly 
>>>>every point. Their project is one of the two VS7 projects I currently support.
>>>
>>>In this case, I should probably tone down my rhetoric in other 
>>>threads -- if you have to support _any_ VS 7 projects, you deserve 
>>>moral support, no matter how certain I might be that you're wrong.
>>>
>>>
>>>>Besides the obvious failure to have applied a design review process (or even the most
>>>>rudimentary of usability studies) to the VS7 interface, Microsoft's second worst mistake
>>>>in the VS domain was discontinuing the availability of VS6. This is based on the premise
>>>>that it is sound business practice to discontinue a successful product while replacing it
>>>>with something that would fail a first-semester GUI design course. (I know someone who
>>>>teaches GUI design, and I've often thought of telling him he should submit VS7 to his
>>>>students and have the entire class critique its numerous catastrophic failures, and send
>>>>the collection of student papers to Microsoft. Preferrably cced to Steve Ballmer).
>>>
>>>What have those students done to you, that you'd subject them to such 
>>>a thing?  Personally, I think this would be unconstitutional: if 
>>>convicted criminals are protected for cruel and unusual punishment, 
>>>surly poor, possibly even innocent colleges students should be as 
>>>well.
>> 
>> 
>> Joseph M. Newcomer [MVP]
>> email: newcomer@flounder.com
>> Web: http://www.flounder.com
>> MVP Tips: http://www.flounder.com/mvp_tips.htm

Joseph M. Newcomer [MVP]
email: newcomer@flounder.com
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm
0
newcomer (15974)
5/18/2004 5:45:52 AM
I can't see how an interface this crappy could make sense in VB either.

I actually just sent a reply that said separately compiled .rc files would be really nice
for large projects. Furthermore, resource IDs should be link-time values, not compile-time
values.
				joe

On Mon, 17 May 2004 11:03:36 +0100, Daniel James <wastebasket@nospam.aaisp.org> wrote:

>In article news:<hgQpc.42313$TT.2629@news-server.bigpond.net.au>, Ian 
>Semmel wrote:
>> A common IDE is a good idea, but usually in programming, you have
>> to write code that fits into the user's environment, not tell the
>> user "I've written this really good program. All you have to do is
>> change the way you do everything". I can imagine the reaction from
>> my customers if I tried this.
>> 
>> I think it would have been easier for MS to develop VS6 into
>> something better than the path they chose. I think I remember
>> something about some guru they got from Borland who decided that
>> the VS7 approach was they way to go.
>
>The thing they got wrong was thinking that it would be "real cool" to 
>have the *same* environment for Visual C, Visial Basic, and Visual 
>Whatever, rather than separate environments for each language that 
>would do what made sense for that language. I believe they had a 
>considerable amount of feedback from customers who used both VB and VC, 
>for example, saying that they'd like to use the same IDE for all 
>development. I don't believe the people making that request thought for 
>a minute that the result would be a lowest-common-denominator IDE that 
>met fewer of their needs than the existing IDEs.
>
>I can see a lot of advantages in having an IDE that can handle a 
>project that includes some buildable applications that are in C++ and 
>some that are in VB (and maybe some that are in Haskell, or Prolog, or 
>Ada...) and being able to edit all the sources side-by-side in a common 
>environment. Such an environment would have common code to handle 
>things that were common to all types of programming (text editing, 
>window management, build control) and language specific code (maybe 
>implemented as a set of plugins) that would handle specific things for 
>different languages (syntax highlighting, context-sensitive editing 
>features, wizards, etc.). It's not rocket science, but one does have to 
>think about what's needed.
>
>> As far as changes, I would have liked something to be done with
>> resources. The present way (been around forever) using #defines has
>> always been a bit of a kludge in my opinion.
>
>You can't change *too* much of the way resources are handled without 
>changing the format of the executable file. A bit more wizard-style 
>help wouldn't go amiss, though. 
>
>I'd like to see IDE support for importing dialogs and other resources 
>from another project (including the resource ID definitions, with 
>automatic reallocation of ID values where they clash) and I'd like to 
>see some provision for managing multiple string tables automatically -- 
>or at least for allocating resource ID values within specified ranges.
>
>That is, for example, I'd like to keep all the help strings and all the 
>menu text strings in my application grouped together; both by location 
>in the resource files and by ID value. I can do that by deliberately 
>setting certain strings to have given resource IDs and always adding 
>new strings of the same type at the correct place in the string table - 
>but it's the very devil to set straight again when some clown doing a 
>bugfix ignores the rules and adds a few new strings of both types at 
>the end of the table. I'd like the IDE to be able to sort that out for 
>me automagically.
>
>It'd be nice if the IDE could manage conditional blocks in resource 
>files, too, so that (say) a dialog template or a version resource could 
>have extra fields in debug and release builds.
>
>Cheers,
> Daniel.
> 
>
>

Joseph M. Newcomer [MVP]
email: newcomer@flounder.com
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm
0
newcomer (15974)
5/18/2004 5:47:36 AM
I agree that a single strong IDE is a good idea. Too bad there wasn't a strong IDE
developed. The IDE is crap, no question. I've used it for C# and for C and C++, and
C++/MFC. It sucks for C#, for C, for C++ and for C++/MFC. I can't imagine how it would
make sense in VB, because all the defects would apply equally well to that environment.
Poor organization, excess modality, an unbelievably poor representation of properties
(competely at odds with how programmers need to think about them!), an editor that makes
vi look sophisticated, just to name the obvious defects. The three VB apps I had to work
with were completely disgusting, because I was forced to use the crappy interface. I
finally got around most of need to use the editor for C#, but the rest of the interface is
just as bad.
				joe
On Tue, 18 May 2004 11:32:34 +1200, "Tim" <Tim@NoSpam> wrote:

>Hi all,
>
>VC7 is an odd one. They are now giving the compiler away without an IDE. I 
>have no idea what this means. Does MS want more VC programmers out there? 
>Does MS want to sway the VC market to 7 with newcomers (no pun intended)?
>
>There are three major parts to this: the IDE, the compiler / linkers (with 
>support tools) and .Net.
>
>IDE:
>
>I tend to look at this whole .Net thing from a distance: the IDE is 
>disgusting for VC. For ASP it is good because ASP has improved so 
>substantially. For VB it is a great improvement - there are tons of new 
>features in the IDE that VB programmers did not have before.
>
>One unified IDE sensible. VS laid the foundations for this in its 
>architecture. The VB IDE had meandered along over the years with only one 
>major improvement - to MDI. Why learn several IDE's when one architecturally 
>strong IDE is all that is needed?
>
>Compilers:
>
>It is well known that the V7 compilers are stronger in many areas - 
>particularly VC6 code. The bugs that are most apparent are in the '7' 
>implementations - attributed programming and the like.
>
>.Net
>
>.Net for ASP is a huge improvement. For VB Programmers it is a new 
>language - each and every VB progammer has to effectively learn a new 
>language. For C++ the core language hasn't changed much but...
>
>Looking into .Net from several perspectives gives only 1 major point of 
>apprehension for me: essentially all the '7' variant languages (IE managed 
>code) are new languages - VC7 managed code is a totally different language 
>but thankfully a superset of the existing C++. What standards adherence is 
>there / will there be and which other compiler vendors are coming to the 
>party supporting managed code so reinforcing the language changes? Are the 
>languages changes just a fad?
>
>The positives in the new language (singular I.E. the CLR) is that there are 
>very substantial extensions to the 'class library'. So many new facilities 
>are in there that make the programmers life more productive and easier, that 
>to ignore them is to risk living in the dark ages. The new facilities for 
>the C++ (or VB or C#) programmer are powerful tools which when compared to 
>current methods of low level coding make current coding look like plodding 
>around in assembler - highly unproductive, slow to code, many lines of code 
>to achieve a task and so a high risk of bugs. Take a look at the ease of 
>integrating say: Event Logging, Performance Monitor metrics, Services (web 
>and system), MSI Installer integration, NUnit - JUnit style test 
>orchistration, very very substantial Security related improvements - and 
>these are only *my* favourites.
>
>The point I wish to make is to not steer away from .Net because you dislike 
>the IDE.
>
>Getting back to the original question... Having written a substantial amount 
>of VC6 code, I too am concerned about the longevity of the product. It is 
>easy enough in my own experience to 'port' to VC7, but that is not an 
>answer. The services that VC6 is built upon are more worrying. For example: 
>ADO and ODBC. It would be near impossible for MS to drop ODBC. ADO has 
>already been superceeded by ADO.Net - when will support for classic ADO end? 
>What happens when the new fangled highly secure OS versions come out that 
>are .Net integrated - will running any non .Net / CLR programs be 
>non-conformant of security standards or has MS had the foresight of being 
>able to wrap these systems in safe containers?
>
>I am enormously concerned about MS ability to deliver a supposed Enterprise 
>class language that will have a support life time sufficient to justify 
>writing large applications - applications that are legacy by nature. I can 
>see COBOL people with a smile on their faces. Until I see stability in the 
>future direction of the IDE I can not see stability in the core language - 
>as separate as they may be.
>
>- Tim
>
>
>"Roy Fine" <rlfine@twt.obfuscate.net> wrote in message 
>news:ecxw7oAPEHA.644@tk2msftngp13.phx.gbl...
>>
>> "Daniel James" <wastebasket@nospam.aaisp.org> wrote in message
>> news:VA.000006a9.0278b880@nospam.aaisp.org...
>>> In article news:<hgQpc.42313$TT.2629@news-server.bigpond.net.au>, Ian
>>> Semmel wrote:
>>> > A common IDE is a good idea, but usually in programming, you have
>>> > to write code that fits into the user's environment, not tell the
>>> > user "I've written this really good program. All you have to do is
>>> > change the way you do everything". I can imagine the reaction from
>>> > my customers if I tried this.
>>> >
>>> > I think it would have been easier for MS to develop VS6 into
>>> > something better than the path they chose. I think I remember
>>> > something about some guru they got from Borland who decided that
>>> > the VS7 approach was they way to go.
>>>
>>> The thing they got wrong was thinking that it would be "real cool" to
>>> have the *same* environment for Visual C, Visial Basic, and Visual
>>> Whatever, rather than separate environments for each language that
>>> would do what made sense for that language.
>>
>>
>> Unfortunately -- the answer is in the numbers -- with a 10:1 (or higher)
>> ratio of VB programmers to VC++ programmers, we should feel fortunate that
>> there is a VC++7  :)
>>
>> rlf
>>
>> 
>

Joseph M. Newcomer [MVP]
email: newcomer@flounder.com
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm
0
newcomer (15974)
5/18/2004 5:53:49 AM
In article news:<dmiha09l6cmbfg7ib0q14l7s7ncaf95d7p@4ax.com>, Joseph 
M. Newcomer wrote:
> It is worth noting that Eclipse is developing a C/C++ version.
> Folks at Microsoft should note this effort. Sun may not become
> the only company which is Eclipsed...

Eclipse does seem very nice to use, I'm appreciating more and more of 
its features as I get to know it better. Of course, Eclipse has the 
great advantage that it is working with Java, which has a MUCH 
simpler syntax than C++ and is much easier to parse and analyse.

At the ACCU conference in Oxford last month we had a lunchtime 
session entitled "What is wrong with C++". The almost-unanimous 
answer from those present was "the quality of tools support". One 
person present actually went so far as to suggest that he used Java 
in preference to C++ because support from tools like Eclipse and 
JUnit made it much more productive for him (that provoked a ripple of 
muttering from others present). I haven't really got to grips with 
the refactoring tools that Eclipse offers for Java, but they do seem 
potentially very powerful. The ability to do things like clicking on 
a method in a class browser and select "rename" to have the 
environment change the name of that method (but not other methods 
that overload the name) everywhere in the code is nice -- and Eclipse 
can do far more than that.

The trouble is that to do these things one has to perform basically 
the same parsing job that the first couple of passes of the compiler 
do. This is much harder to do in C++ than in Java because (a) C++ has 
more complex semantics, (b) C++ has a macro preprocessor that adds an 
extra level of complexity, and (c) C++ has templates which add an 
extra two or three levels of complexity AND follow different rules 
with respect to things like scope resolution from the rest of the 
language. A C++ compiler is quite a tricky beast to write (which is 
why there still aren't *any* commonly used commercial compilers that 
manage to do it - I think the EDG compiler is still the only one and 
that's only available through resellers like Comeau) so C++ tools 
that have to incorporate the first (and trickiest) third of an entire 
compiler aren't going to be terribly easy, either. 

The best way to achieve good parsing for sourcecode tools like 
browsers and refactoring tools is to get a compiler to do it. It's 
not that easy, though, one can't simply take an open source compiler 
(such as g++) and pull out the parser, because the parse needed by 
browsing/refactoring tools is a different parse from that needed by 
the compiler. The compiler can perform the preprocessing pass and 
then throw away all knowledge of the original source and just parse 
the processed output; sourcecode tools need to track both the 
original and the preprocessed source so as to enable browsing of both 
preprocessor symbols and language symbols (and of language symbols 
used explicitly in the definitions of preprocessor symbols and 
implicitly in macro substitutions).

The good news is that, also at the ACCU conference, Microsoft's David 
Burggraaf (who is "Production Unit Manager Visual C++" - whatever 
that means) gave in interesting talk about some of the new 'stuff' 
coming in the next VC++. He spent most of his talk by telling us easy 
it will be to pull legacy C and C++ projects in to VC and run them on 
the .NET CLI and add managed code to them (should you happen to want 
to do such a thing) with extensive reference to MS's port of the Open 
Source Quake code to the CLI; but he did also mention that the new 
environment will have much improved source browsing based on a new 
browse engine which will parse the source as the project is loaded 
(without having to do a full compile), and that the IDE will have 
some simple refactoring capabilities.

The new VC ("palfrey"? "Whitebait"? ... "Whidbey", that's it -- 
whatever that means) should be available in public Beta later this 
summer, they tell us. For the first time in a very long time I find 
myself actually looking forward to being able to play with a new 
release from Microsoft. that's refreshing. 

Cheers,
 Daniel.
 




0
wastebasket (364)
5/18/2004 3:12:25 PM
In article news:<dmiha09l6cmbfg7ib0q14l7s7ncaf95d7p@4ax.com>, Joseph 
M. Newcomer wrote:
> And yes, I agree that making resizable dialogs would have been
> intelligent. But how can you expect such an incredible leap of
> design faith from people who have edit controls that are supposed
> to contain C/C++ language symbols and actually allow characters
> ther than 0-9A-Za-z_ to be typed in? Having an annoying dialog box
> pop up (when you shift focus away) that tells you that the synbol
> contains illegal characters is amateurish. If they were illegal,
> why could they be typed in the first place?

A couple of point:

1. I was suggesting that ALL dialogs in Windows should have been made 
resizable by default, not just those in the VC IDE, and that this 
should have been done years before there *was* a VC IDE. I hardly thnk 
the same people would have been responsible for the design decsions 
(unless Bill does all the GUIs himself?)

2. I think we've disagreed over this before, I very much prefer 
dialogs to perform validation once when completed rather than 
continuously while the user is adding data. I've used too many dialog 
boxes that try to perform on-the-fly validation where the value that 
are acceptable for one field depend on the value in another, and the 
rules are expressed incorrectly so one can never actually persuade the 
damn thing to accept a correct set of data. Even when the dialog *is* 
coded correctly it can be very difficult for the user to understand 
why the dialog won't accept a valid input in one box until he goes 
away and changes the value elsewhere. 

There's also a maintenance headache waiting to leap out. If you code a 
dialog for the entry of a person's address details that works 
perfectly in the US it won't work well in the UK (say) where phone 
numbers have a different number of digits and postcodes are 
alphanumeric.

Most users, these days, interact as much (probably more, sad to say) 
with web forms as they do with traditional dialog boxes. Web forms 
can't validate data on entry without using your old friends 
ActiveVirus and JavaVirus. For a consistent "user experience" true 
dialogs should work the same way.

I don't think there is anything amateurish about waiting until you 
have all the data before passing judgment on its validity.

Cheers,
 Daniel.
 


0
wastebasket (364)
5/18/2004 3:12:25 PM
In article news:<#oQWzCHPEHA.2976@TK2MSFTNGP10.phx.gbl>, Tim wrote:
> We are still on VC6, have conditional compile code or structured
> comments that detail *all* the amendments needed to move to V7
> and have removed a couple of bugs not seen by the V6 compiler 
> or us humans. (This was rehearsed and took very little time given
> the volume of code).

That's an interesting exercise, isn't it? I found a few real howlers 
recompiling some of my VC6 code under the newer, better, compiler.

> However this transitions one to VC7 only. It is not a rewrite to
> .Net with managed code and so the benefits of .Net are not yet
> achieved.

The "benefits" of .NET -- that is, of managed code running in the CLI 
-- are illusory unless .NET offers something of which you can take 
advantage that you're not getting from the native platform. Garbage 
collection is nice, but if you have well-designed C++ code it won't 
leak memory so what are you worrying about? The .NET runtime has a lot 
of good (AFAIK) library code, but your app works without using that 
now, so why would you need to use it? If you have a VC7 unmanaged 
application today it is trivially easy to add a managed module to use 
that library as and when you need to.

Yes, .NET offers the promise of portability to other platforms, and 
that'll be useful for some if and when those platforms get decent CLI 
implementations. At the moment the implementations on non-Windows 
platforms are limited in functionality (last time I looked there was 
no non-Windows GUI support, for example).

Cheers,
 Daniel
 

0
wastebasket (364)
5/18/2004 3:12:25 PM
I agree about the testing issue.  The code we ported was a major release and
done before the testing cycle as part of the normal release development.  I
would not advocate changing anything that major without having the time to
do complete regression testing.  You're also right that the resulting
application was the same.  I think this is the first step to getting to the
new platform (moving the code initially).

Tom

"Tim" <Tim@NoSpam> wrote in message
news:%23oQWzCHPEHA.2976@TK2MSFTNGP10.phx.gbl...


> So why wait? Extensive Testing. The IDE. V7 runtime deployment - bug
> isolation to V7 installation, & a lack of confidence. Also, no hurry
either.
>
> Interestingly, given all this hestitation / procrastination, it is not
> stopping us from including .Net functionality in the V6 product - (IE
> cryptography is so much easier in .Net) what do they call it? Interop or
> something...
>
> - Tim
>
>


0
tserface (3860)
5/18/2004 4:15:26 PM
>>> I have just moved to VC7.0 and I'm now worrying many maintenance
>>> issues. In order to distribute .exe files written in VC7.0. It
>>> seems that we should copy the MFC71.dll & MSVCR71.dll. But isn't
>>> it very stupid  when the actual size of the .exe is xKB but the
>>> size of two dll is xMB?
>>
>>You can avoid this by linking statically.
>
> Which, of course, gives you an executable of massive size, thus
> not solving the problem,

Nope.  Static vs. Dynamic link executable size for my MDI was
only a couple hundred KB(VC6.0).  You have to try it to see what the
bloat is, but my guess is that static linking is a *big* space saver.
I suppose it must depend on how many different MFC features you're
using.  This is for a CAD package that did use all the basic controls,
so I don't know what part of MFC I wasn't using.  Static linking was
definately a big plus on reducing the size of my distriubuted package
(which is over web only, not on CD).

--Mike


0
pmte (28)
5/18/2004 6:02:16 PM
On Fri, 14 May 2004 22:35:57 -0400, "Roy Fine"
<rlfine@twt.obfuscate.net> wrote:

>Some things are a bit more tedious, like
>wiring up member variables in a dialog, etc - but you get used to doing them
>by hand. 

Don't you think that's a terrible judgement on an IDE : that it sucks
so badly you end up doing things by hand ? We gave up on VS7 after a
week of trying to live with its shortcomings, and the Add Variable
dialog was really the coup de grace - a tool so bad it beggars belief.

We've tried to justify using it again, but simply can't live with it.
Roll on Whidbey - but if it was designed by the same guys, I'm not
getting my hopes up.

0
bobm (116)
5/19/2004 9:43:02 AM
YIKES!  I give up!  It sucks a lot!  :)


rlf


"Bob Moore" <bobm@mvps.org> wrote in message
news:grama0lt65bcsr01pqq1hv5a052t0t5b77@4ax.com...
> On Fri, 14 May 2004 22:35:57 -0400, "Roy Fine"
> <rlfine@twt.obfuscate.net> wrote:
>
> >Some things are a bit more tedious, like
> >wiring up member variables in a dialog, etc - but you get used to doing
them
> >by hand.
>
> Don't you think that's a terrible judgement on an IDE : that it sucks
> so badly you end up doing things by hand ? We gave up on VS7 after a
> week of trying to live with its shortcomings, and the Add Variable
> dialog was really the coup de grace - a tool so bad it beggars belief.
>
> We've tried to justify using it again, but simply can't live with it.
> Roll on Whidbey - but if it was designed by the same guys, I'm not
> getting my hopes up.
>


0
rlfine8815 (162)
5/20/2004 2:05:03 AM
On Tue, 18 May 2004 16:12:25 +0100, Daniel James <wastebasket@nospam.aaisp.org> wrote:

>In article news:<dmiha09l6cmbfg7ib0q14l7s7ncaf95d7p@4ax.com>, Joseph 
>M. Newcomer wrote:
>> It is worth noting that Eclipse is developing a C/C++ version.
>> Folks at Microsoft should note this effort. Sun may not become
>> the only company which is Eclipsed...
>
>Eclipse does seem very nice to use, I'm appreciating more and more of 
>its features as I get to know it better. Of course, Eclipse has the 
>great advantage that it is working with Java, which has a MUCH 
>simpler syntax than C++ and is much easier to parse and analyse.
*****
Yes, but  the C/C++ version is in beta; I know at least two people who are trying it
*****
>
>At the ACCU conference in Oxford last month we had a lunchtime 
>session entitled "What is wrong with C++". The almost-unanimous 
>answer from those present was "the quality of tools support". One 
>person present actually went so far as to suggest that he used Java 
>in preference to C++ because support from tools like Eclipse and 
>JUnit made it much more productive for him (that provoked a ripple of 
>muttering from others present). I haven't really got to grips with 
>the refactoring tools that Eclipse offers for Java, but they do seem 
>potentially very powerful. The ability to do things like clicking on 
>a method in a class browser and select "rename" to have the 
>environment change the name of that method (but not other methods 
>that overload the name) everywhere in the code is nice -- and Eclipse 
>can do far more than that.
****
Apparently there is a discussion group going on in Microsoft which is discussing the tool
quality. I haven't had a chance to get to this yet, but if anyone from Microsoft is
reading this selection of posts (and I really hope they are! And paying attention!)

An option to keep Spy++ Always On Top. Hey, guys, I've been asking for these three lines
of code to be added for AT LEAST ten years. It is so blindingly obvious that I cannot
understand why it has not been added. In fact, I don't undertand why this was not part of
version 1.0.

Named configurations in Spy++, so I don't have to keep suppressing the same collection of
messages each time I start it, and I can customize the configuration for each project. I
should be able to save my current selection as a .spy file, and load it at any time.

The ability to save the current output in a file, instead of having to enable output to a
file and re-running the test..

The ability to add a comment into the Spy++ stream, e.g., a simple popup dialog with an
edit control, which then puts
=============================================
your text here
=============================================
so it stands out.

All of this seems obvious, but none of it has made the product

(Actually, this is one of the compelling arguments of the open-source movement. I would
have put this in myself a decade ago if I had source)
*****
>
>The trouble is that to do these things one has to perform basically 
>the same parsing job that the first couple of passes of the compiler 
>do. This is much harder to do in C++ than in Java because (a) C++ has 
>more complex semantics, (b) C++ has a macro preprocessor that adds an 
>extra level of complexity, and (c) C++ has templates which add an 
>extra two or three levels of complexity AND follow different rules 
>with respect to things like scope resolution from the rest of the 
>language. A C++ compiler is quite a tricky beast to write (which is 
>why there still aren't *any* commonly used commercial compilers that 
>manage to do it - I think the EDG compiler is still the only one and 
>that's only available through resellers like Comeau) so C++ tools 
>that have to incorporate the first (and trickiest) third of an entire 
>compiler aren't going to be terribly easy, either. 
*****
Actually, an IDE doesn't have to parse anything. Simple lexical analysis works well enough
to do syntax highlighting. As far as I know, the VC IDEs do not do anything vaguely
resembling parsing of the source, so I don't buy any of the parsing argument.

Besides, Java is getting templates.

And the compiler and the IDE are completely orthogonal. The IDE is free to invoke any
compiler it wants, including any version of Microsoft's C/C++ compiler.
*****
>
>The best way to achieve good parsing for sourcecode tools like 
>browsers and refactoring tools is to get a compiler to do it. It's 
>not that easy, though, one can't simply take an open source compiler 
>(such as g++) and pull out the parser, because the parse needed by 
>browsing/refactoring tools is a different parse from that needed by 
>the compiler. The compiler can perform the preprocessing pass and 
>then throw away all knowledge of the original source and just parse 
>the processed output; sourcecode tools need to track both the 
>original and the preprocessed source so as to enable browsing of both 
>preprocessor symbols and language symbols (and of language symbols 
>used explicitly in the definitions of preprocessor symbols and 
>implicitly in macro substitutions).
*****
And that's what the Microsoft compiler does. It wouldn't surprise me if similar
information could be derived from the gnu tools; a properly modularized IDE would simply
have a well-defined interface to browse, and suitable plugins could be written. In any
case, the person I know who is using the Eclipse beta has pointed out that it apparently
interfaces well with SlickEdit (his hope being to get an IDE with a respectable editor,
instead of the crap Microsoft has tried to pass off as an editor) and SlickEdit itself
claims to support refactoring. I don't know about SlickEdit, but he's planning to download
a version and try it within the next couple weeks.
****
>
>The good news is that, also at the ACCU conference, Microsoft's David 
>Burggraaf (who is "Production Unit Manager Visual C++" - whatever 
>that means) gave in interesting talk about some of the new 'stuff' 
>coming in the next VC++. He spent most of his talk by telling us easy 
>it will be to pull legacy C and C++ projects in to VC and run them on 
>the .NET CLI and add managed code to them (should you happen to want 
>to do such a thing) with extensive reference to MS's port of the Open 
>Source Quake code to the CLI; but he did also mention that the new 
>environment will have much improved source browsing based on a new 
>browse engine which will parse the source as the project is loaded 
>(without having to do a full compile), and that the IDE will have 
>some simple refactoring capabilities.
****
That scares me. Anyone who can't understand how to write an editor is going to have
problems understanding how to write refactoring code.
****
>
>The new VC ("palfrey"? "Whitebait"? ... "Whidbey", that's it -- 
>whatever that means) should be available in public Beta later this 
>summer, they tell us. For the first time in a very long time I find 
>myself actually looking forward to being able to play with a new 
>release from Microsoft. that's refreshing. 
****
"Fishbait"? I have a beta, and I've seen some impressive demos but I can't talk about them
because of NDA, but I haven't had time to bring up the machine I want to dedicate to this
platform (I can't risk putting it up on a production machine). My AMD64 will more likely
take precedence, and I don't have time to even order it. There are some SERIOUSLY
interesting things I saw at the demo, but they still don't know how to write an editor.
****
>
>Cheers,
> Daniel.
> 
>
>
>

Joseph M. Newcomer [MVP]
email: newcomer@flounder.com
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm
0
newcomer (15974)
5/20/2004 4:54:06 AM
In article news:<8i8oa0trnlu5mim304dqqc4qug05c49of1@4ax.com>, Joseph 
M. Newcomer wrote:
> [I wrote]
> >Eclipse does seem very nice to use, I'm appreciating more and more
> > of its features as I get to know it better. Of course, Eclipse
> > has the great advantage that it is working with Java, which has
> > a MUCH simpler syntax than C++ and is much easier to parse and
> > analyse.
> *****
> Yes, but  the C/C++ version is in beta; I know at least two people
> who are trying it

Yes, I know there's a C++ version. I intend to take a good long look 
at that when I have a moment.

[ Spy++ ]
> (Actually, this is one of the compelling arguments of the
> open-source movement. I would have put this in myself a decade
> ago if I had source)

Agreed. Of course, the source for the old Spy (not Spy++) tool is an 
MSDN sample. I wonder why Spy++ isn't.

> Actually, an IDE doesn't have to parse anything. Simple lexical
> analysis works well enough to do syntax highlighting. As far as
> I know, the VC IDEs do not do anything vaguely resembling parsing
> of the source, so I don't buy any of the parsing argument.

There are things you can't do without parsing. One of those is source 
browsing - which VC (6) achieves by requiring the project to be 
compiled before it can be browsed. The parse is done by the compiler 
and made available to the browser in the form of .sbr files. Other 
things that might require parsing are, for example, a class wizard. 
The problems one sometimes encounters in VC6 with ClassWiz getting 
out of step with the source and the .clw and .aps files having to be 
rebuilt could more easily be avoided if the Wiz used a full parse 
tree to keep track of the shape of the project, and we might not need 
to sprinkle the code with //{{AFX_POINT_OUT_THE_OBVIOUS comments.

Eclipse provides some nice refactoring tools for Java, you can rename 
classes (Eclipse automatically updates all references to the class -- 
and renames the source file to match), you can rename methods, you 
can extract interfaces, you can automatically move members from one 
level to another in a class hiearchy ... all these things require 
more understanding of the program stucture than can be gained by 
lexical analysis alone.

> Besides, Java is getting templates.

The comment I heard on that was along the lines of "they managed to 
make the syntax only slightly more complex than it needed to be, so 
Java will still be easier to parse than C++, but unfortunately they 
only really support typesafe collections so Java's templates only 
give a tiny part of the power of C++'s".

> And the compiler and the IDE are completely orthogonal. The IDE
> is free to invoke any compiler it wants, including any version of
> Microsoft's C/C++ compiler.

I agree absolutely ... that's *why* any independent IDE will have to 
provide its own source parsing if it wants to support browsing and 
refactoring and other such goodies -- it can't rely on a cooperative 
compiler giving .sbr files to play with.

I'm not saying this is impossible -- just pointing out that it's 
inherently hard; which is why C++ lags behind Java in tool support 
and is why IDE's that can rely on compiler support are better placed 
to provide good tools soon. I hope VC8/wibbley/whatever delivers.

> >The best way to achieve good parsing for sourcecode tools like 
> >browsers and refactoring tools is to get a compiler to do it.
[snip]
> *****
> And that's what the Microsoft compiler does.

In VC6 (and, I guess, 7) yes. It's interesting, though, that in the 
next release one won't have to compile a project in order to be able 
to browse it. I gather they're still using the first pass of the 
compiler to generate the parse tree, but that compiler pass is 
invoked directly by the IDE as it loads the project for the first 
time (this was demonstrated using the Open Source Quake code (which, 
admittedly, is C not C++, so not rocket science to parse) and -- 
unless it was all smoke and mirrors -- seemed to work well).

> It wouldn't surprise me if similar information could be derived
> from the gnu tools; a properly modularized IDE would simply
> have a well-defined interface to browse, and suitable plugins
> could be written.

It would be nice to see all compilers offer some sort of tool-helper 
interface to the parse tree, yes. The MS compiler is the only one 
that I know does this today.

> ... the person I know who is using the Eclipse beta has pointed out
> that it apparently interfaces well with SlickEdit (his hope being
> to get an IDE with a respectable editor, instead of the crap
> Microsoft has tried to pass off as an editor) ...

Eclipse's design allows a lot of different tools to be interfaced 
through plugins, yes. Pluggable editors are certainly possible (in 
fact, anything other than a plain text editor has to be a plugin, 
including the Java code editor).

I don't mind the VC editor, myself. Yes, it's, er, "light on 
functionality" ... but it does work, it doesn't crash, it supports 
99% of the things I want to do when I'm editing code ... I miss the 
1%, of course, and if there's a specific editing task I know will be 
easier in another editor I know I have that option, but most of the 
time it's easier just to use what's there.

Back in 16-bit VC days I used to use a product called "Fusion" from 
the CodeWright people, which gave most of the power of the CodeWright 
editor within VC (by subclassing the edit windows of the IDE). It was 
much more powerful and did 99.9% of the things I wanted ... but it 
used to crash or lose work (i.e. CodeWright's idea of the edit 
windows' contents got out of sync with VC's) about once every couple 
of days so I gave up on it in the end. If the environment had 
actually supported pluggable editors by the front door it would have 
been a different matter.

> "Fishbait"? I have a beta, ... and I've seen some impressive demos
> but I can't talk about them because of NDA, [snip]. There are some
> SERIOUSLY interesting things I saw at the demo, but they still
> don't know how to write an editor.

<smile>.

They said they hoped it would go to public beta in a couple of 
months, so I guess I can wait and see for myself.

Cheers,
 Daniel.
 









0
wastebasket (364)
5/20/2004 11:26:22 AM
Reply:

Similar Artilces:

Photoshop 6
Any idea please why Photoshop6 will not work with Publisher.[Office 2000] running XP Pro. Thankyou I use PS Elements and have found a weird problem and it could be the same thing that happens to you. Is your PS window not showing but Task Manager says it is? Try closing Publisher and I'll bet PS returns. -- JoAnn Paules MVP Microsoft [Publisher] "RENE" <anonymous@discussions.microsoft.com> wrote in message news:d92a01c43ac7$0e36c5b0$a001280a@phx.gbl... > Any idea please why Photoshop6 will not work with > Publisher.[Office 2000] running XP Pro. Thankyou what...

NDR Status Code 6.4.1
Hi...I'm new to this group, but we are running up against a problem with a front-end exchange server that has just been implemented. Since this server has been installed, the error log is filling up with NDR 6.4.1 error messages and those select email are NOT getting delivered properly even though other email comes through fine. Best we can tell in house, this error code is indicating that we might not have a setting correct on the front-end exchange server to allow 8-bit MIME types to get through. Are there any suggestions on what might be occurring. Are there default settings ...

CRM 4.0 Activities Flaw/Issue
After upgrading from CRM 3 to 4 about 1 month ago, a sales rep pointed out an issue with Activites that isn't working as it should (or would think). In CRM 3, if you selected the Due Today option, it would list only activities due today. No overdue items. In CRM 4, if you select the Due Today option, it shows all activities due Today AND overdue. Basically, it's broken and useless with no Today option. In CRM 3, if you selected the Due Overdue option, it would list activites that are overdue. In CRM 4, if you selecte the Due Overdue option, it shows all activities due Today AND ove...

Can't send a link from IE 6
Installed Outlook 2003 recently, and now I cannot send a link to a page from IE6. I ran Tweakol2003 so I can receive links, etc. Something really simple I'll bet, but I have looked thru the help files and have not hit on it yet. Thanks for any guidance ... John Patch <fred@hotmail.com> wrote: > Installed Outlook 2003 recently, and now I cannot send a link to a > page from IE6. I ran Tweakol2003 so I can receive links, etc. How do you know you can't send it? -- Brian Tillman Usually when the you try and send a link, a Outlook form comes up over the IE screen jus...

SQL Performance Issue whe HQ and Navision reside on same server
We are experiencing problems with one of our major clients when they run 401 worksheets. They have a server with an HQ database that has 10 stores. Residing on the same server is a substantial Navision database. The HQ server program is running on a separate PC. When an HQ Client connects and a 401 Data Upload runs, the SQL server program appears to ‘lock up’ and prevents any access to any of the SQL databases, causing problems with the Navision users. Our query is should this type of event occur? What is actually happening within the SQL server when a 401 worksheet is being proces...

Issues with 12.1.2 with tables and page breaks.
Version: 2008 Operating System: Mac OS X 10.4 (Tiger) Processor: Intel I work for a small company that is primarily mac based. I noticed in this latest patch that our documents are having major issues after this patch. For one the text in tables is missing totally or partially. It is there though. The solution I found is to select the table and do a word wrap in the table properties but we have thousands of documents like this. Also I have been getting reports and also noticed that it is inserting extra page breaks in documents. Not sure what is going on with this new patch but it has made...

Using Visual C++ 6.0 MFC Application
01/19/2004 Using a single document or a dialog application, I am able to use my own variables that are declared in the same source file, however, if I try to declare a global variable in a header file or a source file included before the code I am using, I get the error "Undeclared Identifier". Example in Old C: "First.h" int i; "Main.cpp" #include "First.h" main() { i=5; printf("%d",i); } When I declare a variable in a header file, in Class View - Globals, my variable does show up, b...

very basic MS access 2007 (button click no read issue)
I added 2 text fields and a button to a form in MS access 2007. and i went to the code builder and tried to add values to the text fields . ex: textBox1.text = "name" i coded this to the button click event.. but some times after i get an error.. the button click property never works... so i have to create a new form and redo it. can some one tell me why this is hapenning , and tell me a way to prevent this.. In Access, you can only use the text property if the control has the focus. Instead, try: textbox1 = "Name" or textbox1.Value = "...

Standard Visual Basic vs Visual Basic for Applications
I've recently purchased Front Page and understand that I can code with Visual Basic as part of this software package. 1. What does Front Page contain: Standard Visual Basic or VBA? 2. Do either or both work with Visual Studio? 3. Is Visio different from Visual Studio? -- Deb Front Page and Visio are both Microsoft Office applications that contain VBA (Visual Basic for Applications). These programs are productivity applications first and programming platforms second. Visual Studio is a pure programming application. (All it does is let you write other programs.) Older versions of ...

Outlook integration issues
We're running Outlook 2K3 and the CRM client with ver. 1.2, when I try to import the contacts list it tells me that Outlook cannot be started even if it is running. Can anyone assist me with troubleshooting this issue. ...

HP Image Editor files default to C:\ directory
Re: HP 3970 Scanner Hello Everyone: Maybe someone here has or has used this scanner and knows the answer. I will make my question as straightforward as possible. Once I have scanned an image and 'saved it,' it defaults to the C:\ directory unless I choose another location. If it is saved in another directory, it will not show up on the image editor so I unable to print or edit the image. Is there a way to change the settings so that an image is automatically saved to a default location other than C:\ or do I have to move an image to the C:\ location each time I ...

I Visual Basic Error "File Not Found" when Excel opens
Good afternoon. I am using XP Pro at work and My computer just started doing this. when I open Excel, I get a message pop up that says in title "Visual Basic Error" and in body of error window is "File Not Found". If I click on help, says something about error 53 but when I try to look that up on Microsoft's website, can't find what seems to apply to my issue. And now when I go into my personal.xls to view my macros, I can get in, but if I try to save anything, I get a window pop up saying Excel must be shut down, and then a window pops up asking me if I want...

C-DLL-VBA-EXCEL strings
Hello, I'm trying to connect excel to a C dll library (call C dll from excel through the VBA). It works well for returning integer and double values (see simple example below), but I can't seem to get it to return strings. I am using MinGW gcc (so basically only C) to construct my dll, so I don't have access to BSTR and other cpp like objects/functions... Is there a way to make the C dll return strings to excel? Thanks DLL.c #ifdef BUILD_DLL #define EXPORT __declspec(dllexport) #else #define EXPORT __declspec(dllimport) #endif EXPORT int __stdcall add2(int num){ return num + 2; ...

Agent version issue on secondary DPM
I am trying to restore a secondary DPM server back to working order by reinstallation of the OS (server 2008 R2), installation of DPM 2007, installation of DPM 2007 SP1, and installation of hotfix KB976542. Following this I restore the DB using "dpmsync -restoredb -dbloc mypath\dbdpm.bak" then resyncing with "dpmsync -sync". My replicas were preserved. However, I'm having an agent problem with my primary server. If I try to install the agent on the primary server, I get an error 372: The agent operation failed because DPM detected a more recent versio...

Chart #6
I'm using Excel 2002. I need to know how to create a chart based on numbers from multiple sheets in one workbook. Jake - http://peltiertech.com/Excel/ChartsHowTo/ChartFromDiffSheets.html - Jon ------- Jon Peltier, Microsoft Excel MVP Peltier Technical Services Tutorials and Custom Solutions http://PeltierTech.com/ _______ Jake wrote: > I'm using Excel 2002. I need to know how to create a chart based on numbers > from multiple sheets in one workbook. ...

Undo Auto Reply in Out Ex #6?
Help ....before I went on vacation, I set up an auto reply in my Outlook Express 6 mail program. For the life of me, I cannot find where to undo this ! Tools-> Message Rules perhaps? Note that this is an Microsoft Office Outlook forum. Outlook Express is family of Internet Explorer and Outlook of the Office family. Here is the link for the right forum http://communities.microsoft.com/newsgroups/default.asp?icp=InternetExplorer Good Luck! -- Roady [MVP] www.sparnaaij.net Microsoft Office and Microsoft Office related News Also Outlook FAQ, How To's, Downloads and more... Tip of ...

C++ equivalent?
Hi, In c# where I would access a named property of a chart series like: series["DrawingStyle"]= columnStyle; But I can't figure out how to do the equivalent in c++. Where a 'normal' property would be set like this in c++: series->MarkerSize= markerSize; c# series.MarkerSize= markerSize; Thanks, Dan. On 23-04-2010 17:41, DanB wrote: > In c# where I would access a named property of a chart series like: > series["DrawingStyle"]= columnStyle; > But I can't figure out how to do the equivalent in c++. > > > Wher...

Visual C++ AND .Net
What would be the best package for me to purchase if I want to move from VC++ 6.0 and VB 6.0 to .Net? I think it is Visual Studio .Net (around $800.00). Is this correct? I just need a little direction since I have just been given the go ahead to purchase these items. Any information on these products - from someone who has used them - would be helpful. Thank you Ken >-----Original Message----- >What would be the best package for me to purchase if I want to move from >VC++ 6.0 and VB 6.0 to .Net? I think it is Visual Studio .Net (around >$800.00). Is this correct? I just nee...

Looking for Visual C++ programmer with MS SQL Server 2005 to work off-site on small project
Looking for Visual C++ programmer with MS SQL Server 2005 to work off-site on small project. Please send me an email to: larryTAKEOUT@seldin.net Lawrence M. Seldin, CMC, CPC Contributing writer for FUTURES Magazine Author of RECRUITSOURCE PEOPLESOFT EXAM and RECRUITSOURCE SAP/R3 EXAM Author of POWER TIPS FOR THE APPLE NEWTON and INTRODUCTION TO CSP NOTE: To send me an email, remove TAKEOUT from my email address: larryTAKEOUT@seldin.net NOTE: My web home page: www.seldin.net ...

list control #6
how can i delete an item from a list control > how can i delete an item from a list control CListCtrl::DeleteItem. Heres the link. Sample code is at the bottom: http://msdn2.microsoft.com/en-us/library/84fyba4z.aspx --- Ajay This should help you as well: http://msdn2.microsoft.com/en-us/library/zdff988k.aspx Tom "dspman" <dspman@dspman.com> wrote in message news:%23kH3mlCpGHA.4812@TK2MSFTNGP04.phx.gbl... > how can i delete an item from a list control > i tried sth like this but is not working void CSpeedDial::OnSpeedDelete() { POSITION pos = m_speed...

Frx 6.7 install on Citrix
Hi WE're getting an error when installing FRx 6.7 on Citrix server. I was given the following link which has a modified version of FRx. But the link is not working. Has the site been moved? Can anyone give me the new site address to download this modified version? ftp://ftp.greatplains.com/dynamicsftp/frx67/FRx6.7.0.2013gp.zip Thanks ...

Amazing Problem in AllocPhysMem wince 6.0
Hi I am writing a Port Driver for x86 platform in WinCE 6.0. I want to allocate virtual and equivalent physical memory in driver and mapped it to USER mode to use application. For that I used AllocPhysMem in driver and passed that address through IOCTL calls but i cant use that virtual and physical address in application side. Because AllocPhysMem returns Error Code as 0x57 (meaning Parameter incorrect). But the same code is working in WinCe 5.0. My code snippet is, VirAddress = (LPVOID)AllocPhysMem(32, PAGE_READWRITE|PAGE_NOCACHE, 0, ...

How does C# avoid needing C++ style header files?
I am new to C# and want to understand its architecture a little better. How does C# avoid needing C++ style header files? Hello, By design when you compile some code, metadata are stored as part of the generated file allowing to use those classes in a self contained way. It has all the needed info built into it. See : http://msdn.microsoft.com/en-us/library/xcd8txaw(VS.71).aspx (Metadata Overview) -- Patrice "Peter Olcott" <NoSpam@SeeScreen.com> a �crit dans le message de groupe de discussion : t8CdnWMCZcduNcTWnZ2dnUVZ_hudnZ2d@giganews.com... &...

Sending E-mail with express 6.x
I get this error message when I try and send e-mail from my outlook express (i have an account with Juno).... The message could not be sent because one of the recipients was rejected by the server. The rejected e- mail address was 'sparlin@uii.com'. Subject 'another test', Account: 'Juno', Server: 'smtp.juno.com', Protocol: SMTP, Server Response: '553 sorry, that domain isn't in my list of allowed rcpthosts (#5.7.1)', Port: 25, Secure(SSL): No, Server Error: 553, Error Number: 0x800CCC79 I don't understant the "isn't in my list ...

links #6
I have a "Master" workbook that does some calculations based on data that is entered into a couple of "Daughter" workbooks. If I move the location of one of the "Daughter" workbooks, the "Master" loses the link to that "Daughter". Now when I open the "Master" it prompts me to browse to the new location of the "Daughter". I browse to the "Daughter" and everthing works fine. However, I am tired of having to do this everytime I use the "Master". Is there a way to refresh the links, so that it re...