VB 4.0 Bugs "enhancements" 
Author Message
 VB 4.0 Bugs "enhancements"

I do not like Microsoft changing the way the cursor keys work
in VB 4.0 vs VB 3.0.  Now, if you left or right cursor it will
"wrap" back to the previous, or next line.  IMO, that is the
stupidest thing I have ever seen. I have talked to their Tech
support lines for days and was finally told that it will stay
as it is and was designed to make all microsoft products have
and integrated "interface".  What? I want an EDITOR, not another
WORD PROCESSOR.  Hello Microsfoft, are you listening here?
I could not get any of the numerous Techs that I talked to, to
give me ONE reason that an EDITOR should have scroll-around.
Why would I want to go back to the previous line? Am I writing a
novel?  I thought I was writing a set of statements in a computer
language...

More good news for those who haven't seen this "feature"....
Try this in your favorite version of 4.0, debug window will do
just fine...

? 1 / 10 * 3500

or if you want to get really nitpicky, use int variables instead of
constants.  Guess what? same thing.  Try it with int division "\"?
Yep, you got it.  In fact anything in the denominator that resolves
to greater than 2^15 or less than 2^-15 returns an error.  Microsoft
suggested workaround?   Either do not use equations in the denominator
(good one) or change all variable type int to long (oh ok no problem,
why not just define everything as double or currency and be done with
it)

Have you seen the "Procedure Too Long, Exiting Compiler" MsgBox when
compiling your favorite 3.0 code in 4.0?  I have a Sub that is 1231
lines long and is within MS VB 3.0 and 4.0 published limits and it
has always compiled fine under 3.0.  4.0 will not compile.

I have no other bugs to report as I haven't gotten a single 3.0 project
to compile under 4.0 yet and run for more than a few seconds....

I must guess that either no one else uses 4.0, or no one is attempting
any arithmatic other than adding and subtracting....

Craig H. Rogers



Tue, 09 Jun 1998 03:00:00 GMT  
 VB 4.0 Bugs "enhancements"

Quote:
>More good news for those who haven't seen this "feature"....
>Try this in your favorite version of 4.0, debug window will do
>just fine...

>? 1 / 10 * 3500

I get 350; what do you get?

Quote:
>or if you want to get really nitpicky, use int variables instead of
>constants.  Guess what? same thing.  Try it with int division "\"?
>Yep, you got it.  In fact anything in the denominator that resolves
>to greater than 2^15 or less than 2^-15 returns an error.  Microsoft
>suggested workaround?   Either do not use equations in the denominator
>(good one) or change all variable type int to long (oh ok no problem,
>why not just define everything as double or currency and be done with
>it)

I'm not exactly sure what you're getting at here, but in 32-bit VB4
I would recommend using Longs instead of Integers anyway, since
integers are still 16-bit.  In fact I even saw one benchmark where
longs were slightly faster than integers in 32-bit VB4, probably
because integers are 32-bits in Win32.

Quote:
>Have you seen the "Procedure Too Long, Exiting Compiler" MsgBox when
>compiling your favorite 3.0 code in 4.0?  I have a Sub that is 1231
>lines long and is within MS VB 3.0 and 4.0 published limits and it
>has always compiled fine under 3.0.  4.0 will not compile.

Yecch.  I can't imagine any reason for writing a Sub even half that
long.  Of course if the docs say it's OK and it's not, that is a
problem.

Quote:
>I must guess that either no one else uses 4.0, or no one is attempting
>any arithmatic other than adding and subtracting....

If you're doing really heavy arithmetic, you might be better off
with a dll for that stuff anyway.  Even without bugs an interpreted
language is going to be slow.

Just my $.02,

Jeff



Tue, 09 Jun 1998 03:00:00 GMT  
 VB 4.0 Bugs "enhancements"

Quote:

>I do not like Microsoft changing the way the cursor keys work
>in VB 4.0 vs VB 3.0.  Now, if you left or right cursor it will
>"wrap" back to the previous, or next line.  IMO, that is the
>stupidest thing I have ever seen. I have talked to their Tech
>support lines for days and was finally told that it will stay
>as it is and was designed to make all microsoft products have
>and integrated "interface".  What? I want an EDITOR, not another
>WORD PROCESSOR.  Hello Microsfoft, are you listening here?
>I could not get any of the numerous Techs that I talked to, to
>give me ONE reason that an EDITOR should have scroll-around.
>Why would I want to go back to the previous line? Am I writing a
>novel?  I thought I was writing a set of statements in a computer
>language...

>More good news for those who haven't seen this "feature"....
>Try this in your favorite version of 4.0, debug window will do
>just fine...

>? 1 / 10 * 3500

>or if you want to get really nitpicky, use int variables instead of
>constants.  Guess what? same thing.  Try it with int division "\"?
>Yep, you got it.  In fact anything in the denominator that resolves
>to greater than 2^15 or less than 2^-15 returns an error.  Microsoft
>suggested workaround?   Either do not use equations in the denominator
>(good one) or change all variable type int to long (oh ok no problem,
>why not just define everything as double or currency and be done with
>it)

>Have you seen the "Procedure Too Long, Exiting Compiler" MsgBox when
>compiling your favorite 3.0 code in 4.0?  I have a Sub that is 1231
>lines long and is within MS VB 3.0 and 4.0 published limits and it
>has always compiled fine under 3.0.  4.0 will not compile.

>I have no other bugs to report as I haven't gotten a single 3.0 project
>to compile under 4.0 yet and run for more than a few seconds....

>I must guess that either no one else uses 4.0, or no one is attempting
>any arithmatic other than adding and subtracting....

>Craig H. Rogers

The wraparound pisses me off as well, but I started with 4.0 so havent suffered
the 3.0 conversion problem (I will be doing it the other way around soon
though) I am really pissed at basic in general, everything is backwards and
stupid...who wants to keep track of / and \????  why does DIM mean declare?
why are there now like 8 different ways to round a number? all I want is ROUND
and TRUNC, but they have INT, FIX (why FIX?), CINT and loads of STUPID
stuff...and why doesnt VB compile??? VB *could* compile, I mean, Microsoft has
the worlds best programmers(or so they think) yet they are too lazy to make VB
compile??? I want to kill them now!

--

"It can't rain all the time"
-Kryptology



Thu, 11 Jun 1998 03:00:00 GMT  
 VB 4.0 Bugs "enhancements"

Crow) threw this at us:

Quote:
>I am really pissed at basic in general, everything is backwards and
>stupid...
>who wants to keep track of / and \????

Who wants to keep track of :=, == or = ?? And who wants to type
like this; (I'm referring to Pascal and C with the ";"); Don't
you just love that; I know I do; It's great;

Quote:
>why does DIM mean declare?

It doesn't. Ha ha. It means Dimension.

Quote:
>why are there now like 8 different ways to round a number? all I want is ROUND
>and TRUNC, but they have INT, FIX (why FIX?), CINT and loads of STUPID
>stuff...
>and why doesnt VB compile??? VB *could* compile, I mean, Microsoft has
>the worlds best programmers(or so they think) yet they are too lazy to make VB
>compile??? I want to kill them now!

That's the problem. Everyone (including me sometimes, to) thinks
compiled code is better. Of course, it's faster, and small
program = small executables. But then again, You have to
distribute the same built-in stuff with every app you make -- you
don't need to with VB (but someone do, since they can't be sure
the end user really has all the stuff they need beforehand.
*sigh*). It's really a difference in religion -- MS thinks the
"reusable code" religion is the better for VB, whilst they think
the "compiled and fast" religion is better for C. Who knows what
they really want?

Anyway, when MS decides to ship the VB DLLs with Win10 (that's
Windows 2010), we VB'ers can laugh at the stupid C and Delphi
programmers still struggling with those huge EXEs.

Jens
--
* Everything I said are the opinions of someone else.   *
* I just cut-and-pasted.                                *

Jens Balchen jr.       http://www.sn.no/~balchen



Thu, 11 Jun 1998 03:00:00 GMT  
 VB 4.0 Bugs "enhancements"

Jens.  I think you're getting trigger happy here.  In another article,
you claimed you didn't know much (anything significant) about C.
However, you shoot it down here like you know it more than you said
you do.  Compiled C/C++ Windows program do "re-use" code.  That's the
whole point of the Win SDK and the DLL architecture of Windows.  Even
if compiled C programs repackage some static RTL functions/libs,
they're still smaller (and faster) than VB's pcode.

George


Quote:

>Crow) threw this at us:
>>I am really pissed at basic in general, everything is backwards and
>>stupid...
>>who wants to keep track of / and \????
>Who wants to keep track of :=, == or = ?? And who wants to type
>like this; (I'm referring to Pascal and C with the ";"); Don't
>you just love that; I know I do; It's great;
>>why does DIM mean declare?
>It doesn't. Ha ha. It means Dimension.
>>why are there now like 8 different ways to round a number? all I want is ROUND
>>and TRUNC, but they have INT, FIX (why FIX?), CINT and loads of STUPID
>>stuff...
>>and why doesnt VB compile??? VB *could* compile, I mean, Microsoft has
>>the worlds best programmers(or so they think) yet they are too lazy to make VB
>>compile??? I want to kill them now!
>That's the problem. Everyone (including me sometimes, to) thinks
>compiled code is better. Of course, it's faster, and small
>program = small executables. But then again, You have to
>distribute the same built-in stuff with every app you make -- you
>don't need to with VB (but someone do, since they can't be sure
>the end user really has all the stuff they need beforehand.
>*sigh*). It's really a difference in religion -- MS thinks the
>"reusable code" religion is the better for VB, whilst they think
>the "compiled and fast" religion is better for C. Who knows what
>they really want?
>Anyway, when MS decides to ship the VB DLLs with Win10 (that's
>Windows 2010), we VB'ers can laugh at the stupid C and Delphi
>programmers still struggling with those huge EXEs.
>Jens

===============================================================================
 George R. Torralba              xxxxxxxxxxxx                  Batang Cebu!!!
 Seattle, Washington             206.241.2801              MIME mail accepted
===============================================================================


Thu, 11 Jun 1998 03:00:00 GMT  
 VB 4.0 Bugs "enhancements"

(George R. Torralba) threw this at us:

Quote:
>I think you're getting trigger happy here.  In another article,
>you claimed you didn't know much (anything significant) about C.

I don't. Actually, I'm just learning the language now. (That's
why I so irritated at that ";")

Quote:
>However, you shoot it down here like you know it more than you said
>you do.  Compiled C/C++ Windows program do "re-use" code.  That's the
>whole point of the Win SDK and the DLL architecture of Windows.

Of course. Every Windows program re-uses the Windows DLLs. It's
those other things I'm talking (but I don't know which, since I
don't know C. Maybe I can have a shot at those ".h" files).

Quote:
>Even
>if compiled C programs repackage some static RTL functions/libs,
>they're still smaller (and faster) than VB's pcode.

That must depend on the program itself. However, that was not my
point. The point is the way you look at the compiled (or not so
compiled) code: from speed or from size. If you know that
everyone using this program will have the run-time dlls, you have
very little to distribute when you use VB. But that slowes the
app down.

[While I'm standing on the stage talking to you, suddenly a guy
comes running from backstage screaming "But Delphi..", and I hit
him over the head with something hard]

Sometime, in a hopefully not-so-far-away-future, MS will make
everything you need for VB-apps to run available in the OS (be it
Win96-7-8-9 or WinNT).

Jens
--
* Everything I said are the opinions of someone else.   *
* I just cut-and-pasted.                                *

Jens Balchen jr.       http://www.sn.no/~balchen



Fri, 12 Jun 1998 03:00:00 GMT  
 VB 4.0 Bugs "enhancements"


: (George R. Torralba) threw this at us:

: >I think you're getting trigger happy here.  In another article,
: >you claimed you didn't know much (anything significant) about C.

: I don't. Actually, I'm just learning the language now. (That's
: why I so irritated at that ";")

: >However, you shoot it down here like you know it more than you said
: >you do.  Compiled C/C++ Windows program do "re-use" code.  That's the
: >whole point of the Win SDK and the DLL architecture of Windows.

: Of course. Every Windows program re-uses the Windows DLLs. It's

No not necessarily, though you have to go out of your way to
avoid using them.

: those other things I'm talking (but I don't know which, since I

Geez...

: don't know C. Maybe I can have a shot at those ".h" files).

_Do Not_ touch the header files.  If you are just learning C and
C++ as you say above, the last thing you should be doing is messing
with the .h (header) files.  All they do is proto type the functions
in the libraries.  As C++ is a strongly "typed" language, you can
do real harm.  You will learn more if you study the on-line books.

: >Even
: >if compiled C programs repackage some static RTL functions/libs,
: >they're still smaller (and faster) than VB's pcode.

: That must depend on the program itself. However, that was not my
: point. The point is the way you look at the compiled (or not so
: compiled) code: from speed or from size. If you know that
: everyone using this program will have the run-time dlls, you have

You really need to spend more time learning your C/C++ compiler.
And less time bashing VB for what you perceive as it's failings.
In MSVC++ you have the option of compiling code that totally
depends on runtime dll files.  Although few people ever choose
this option.

The difference between C/C++ and VB has less to do with
runtime options than you make it out to be.  They are
different languages, with different intended purposes.

It is entirely possible to take a program written in
ANSI C for a mainframe environment and "port" it to
Win/WinNT.  It is simply a matter of keeping the
core program seperate from the OS specific modules.
Which is something that I have done on several occasions.

: very little to distribute when you use VB. But that slowes the
: app down.

The speed of a VB app also depends on the skill of the programmer ;-)

: Sometime, in a hopefully not-so-far-away-future, MS will make
: everything you need for VB-apps to run available in the OS (be it
: Win96-7-8-9 or WinNT).

Don't hold your breath.  This is something that programmers have
been asking for since VB/Win v1.00.

: Jens
: --
: * Everything I said are the opinions of someone else.   *
: * I just cut-and-pasted.                                *

Too bad, you really should try coding a least once. ;^)

Peter Mikalajunas

http://www.xnet.com/~kd9fb



Sat, 13 Jun 1998 03:00:00 GMT  
 VB 4.0 Bugs "enhancements"

(Peter Mikalajunas) threw this at us:

Quote:
>The difference between C/C++ and VB has less to do with
>runtime options than you make it out to be.

But it were the runtime options we were discussing. :)

Jens
--
* Everything I said are the opinions of someone else.   *
* I just cut-and-pasted.                                *

Jens Balchen jr.       http://www.sn.no/~balchen



Sat, 13 Jun 1998 03:00:00 GMT  
 VB 4.0 Bugs "enhancements"

Quote:

> Sometime, in a hopefully not-so-far-away-future, MS will make
> everything you need for VB-apps to run available in the OS (be it
> Win96-7-8-9 or WinNT).

. and they will call it Windows for Visual Basic.

For the compile debate :

When you are driving nails in wood.. use a hammer. When you are
writing time-critical code, us C (or ASM), but write the UI in
the development environment that's the easiest and fastest (in
terms of development time!) : VB 3.0 (i would surely like to
say VB 4.0, bat that's after they come with a bug-fix release)

Season Greetings Jens

Marcel van der Gragt
DLW Software



Sat, 13 Jun 1998 03:00:00 GMT  
 VB 4.0 Bugs "enhancements"

Quote:

>(Peter Mikalajunas) threw this at us:

>>The difference between C/C++ and VB has less to do with
>>runtime options than you make it out to be.

>But it were the runtime options we were discussing. :)

But the problem is you don't really understand the
run-time options with modern C/C++ compilers.  With,
for instance, Visual C++, you can link your exe to
the dynamic version of the MFC library, and then
you get a nice small executable with the advantage
of compiled code.  The run-time library is a DLL that
can be shared by other programs, just like the VB
runtime is shared among VB programs. What makes you
think something has be interpreted p-code instead of
a compiled .exe to take advantage of code reuse?


Sun, 14 Jun 1998 03:00:00 GMT  
 VB 4.0 Bugs "enhancements"

Quote:

>: very little to distribute when you use VB. But that slowes the
>: app down.
>The speed of a VB app also depends on the skill of the programmer ;-)

Yes indeed, to make VB4 apps go faster you have to use lots of
workaround code and tricks. VB is bad programming practice.

In fact, the main rule to speed up VB apps is to use as less "fancy"
VB functions as possible.

        Scott.



Sun, 14 Jun 1998 03:00:00 GMT  
 
 [ 13 post ] 

 Relevant Pages 

1. VB Script "bug"???

2. VB Script "bug"???

3. Bug in vb's "raiseevent"

4. VB 4.0 : "Unknown error;Quitting"

5. VB and NT 4.0 registry "transience"

6. What exactly is VB 4.0 "a"?

7. Searching VB 4.0 "MDB Database Files"

8. *"*-.,._,.-*"* I"LL TRADE VISUAL C++ FOR VBASIC *"*-.,_,.-*"*

9. Strange "bug?" in VS

10. Bound ComboBox "Bug"?

11. RemoteDataControl .EditMode "bug"

12. FileSystemObject.DateCreated "bug"?

 

 
Powered by phpBB® Forum Software