A simple request

[Rick Rothstein]

The VB7 developers should read through the various VB-oriented newsgroups,
look at the questions that keep coming up over and over and over and over
again and include functions/subroutines/components to handle them . . .
simple.

For example, why don't "containers" (a form, a frame, etc.) have a property
that can be set which controls whether things in it are automatically
resized as the form is resized.

Or, why isn't there a full-bodied expression evaluator available "directly"
within VB? After all, the Print statement already knows how to evaluate
extremely complex "string" expressions; why isn't it a simple thing for VB
to "tap" into this internal routine and use it to evaluate a user-provided
string instead of a "fixed at design time" string expression?

Or . . . well, you get the idea.

Rick

[Phil Weber]

> The VB7 developers should read through the various VB-
> oriented newsgroups, look at the questions that keep coming
> up over and over and over and over again and include func-
> tions/subroutines/components to handle them...simple.

Rick: I would prefer that VB's developers not spend their limited time
building into VB features that are readily available elsewhere. There are
numerous third-party resizing controls, and MS already provides a free
expression evaluator that can be used from VB. What's to be gained by
building these features into VB? I'd rather have them fix bugs and add
features that can't easily be implemented by third parties.
---
Phil Weber

[Damit Senanayake]

Phil,

: I'd rather have them fix bugs and add
: features that can't easily be implemented by third parties.

A prime example of which is returning a positive HRESULT from a class
function w/o vtable hacks ... and allowing you to return more than one
element from a For Each (right now you have to hack by calling
IEnumVARIANT::Next directly):

Dim vaData(0 to 3) As Variant

colItems.GetNext(4, vaData())

Another would be improving the control siting methods - so that we can
*natively* have tabstops, accelerator processing, etc. without having to use
a typelib.
--
Damit Senanayake | damit@mvps.org
Please reply to newsgroups, not by e-mail.
http://members.xoom.com/damit | {http,ftp}://damit.dyndns.org (experimental)
ICQ: 6930718

[Rick Rothstein]

Phil,

Below are some inline comments that I just wrote. In re-reading them, they
sound a little more "combative" than I originally intended. However, it is
nearly four in the morning, so I'm not going to change them. Please make the
necessary allowances for their "tone".

Also, I was not intending that other efforts not be addressed by Microsoft,
merely that those areas where considerable confusion appears to exist, as
demonstrated by the repeat questions asked on the various newsgroups be
accounted for. If these questions keep coming up over and over, then those
asking them -- and more important, those experiencing them but NOT asking --
are probably becoming frustrated with the language and might become turned
off to VB and possibly even programming in general.

Rick


> Rick: I would prefer that VB's developers not spend their
> limited time . . .

Pardon my cynacism, but with all the money Microsoft has you would think
they could hire an additional programmer or two to work on these items.


> . . . building into VB features that are readily available
> elsewhere.

They may be readily available, but based on the questions that have been
asked (remember my original premise) since VB6's release , they are either
not well known or cost more than some users deem appropriate.


> . . . and MS already provides a free expression evaluator
> that can be used from VB. What's to be gained by building
> these features into VB?

I may have done something wrong, but I seem to remember having trouble
making that expression evaluator handle trig functions (the help files are a
little skimpy for it). Besides, I repeat -- the ability to process complex
expressions already exists in VB via the internal routines available in the
Print command. It seems like it should be easy to either point these
routines, if they are not pre-compiled, to a user supplied string or to add
their code logic directly into VB in order to handle these user supplied
strings.


> I'd rather have them fix bugs . . .

Well, I kind of thought they have been developing upgrades for a while now.
There are have been three Service Packs released to date and there is no
reason to assume others won't be released if the bugs are serious enough to
warrant them. For those not that serious, I doubt if they will be ignored
when VB7 is actually released.