Re: Visual C++ 6 support issue
From: Daniel James (wastebasket_at_nospam.aaisp.org)
Date: 05/17/04
- Next message: Brad McMillan: "Problem Inserting an ActiveX Control Into a Modeless Dialog Box"
- Previous message: Daniel James: "Re: Visual C++ 6 support issue"
- In reply to: Ian Semmel: "Re: Visual C++ 6 support issue"
- Next in thread: Roy Fine: "Re: Visual C++ 6 support issue"
- Reply: Roy Fine: "Re: Visual C++ 6 support issue"
- Reply: Joseph M. Newcomer: "Re: Visual C++ 6 support issue"
- Messages sorted by: [ date ] [ thread ]
Date: Mon, 17 May 2004 11:03:36 +0100
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.
- Next message: Brad McMillan: "Problem Inserting an ActiveX Control Into a Modeless Dialog Box"
- Previous message: Daniel James: "Re: Visual C++ 6 support issue"
- In reply to: Ian Semmel: "Re: Visual C++ 6 support issue"
- Next in thread: Roy Fine: "Re: Visual C++ 6 support issue"
- Reply: Roy Fine: "Re: Visual C++ 6 support issue"
- Reply: Joseph M. Newcomer: "Re: Visual C++ 6 support issue"
- Messages sorted by: [ date ] [ thread ]
Relevant Pages
|
