"Kevin Provance" <casey> wrote in message
news:2296
> Option Base 1 at the general decs level will force arrays to start at 1.

In vb.net?

Michael

"Bob Butler" <noway> wrote in message
news:4424
> "Robert Morley" <rmorley> wrote in message
> news:3460
>>> doesn't care whether it uses COM, the win32 API or voodoo
>>
>> Oh, oh! I want one that uses voodoo! Then there'd be all kinds of
>> justification for those techies who make their machines work like magic.
>
> Chicken.Waive(WaveAround.Head,WaiveTime.Midnight)

That's VB net code!!!

Michael

On Tue, 22 May 2007 09:24:14 +1000, "Michael C" <nospam>
wrote:
in <u7Aeb8$mHHA.2596>

>Have a read of this one, it looks like they tried to have non-zero based
>arrays but decided against it for very good reason.
>[..]
>
>> An array of days of the month comes to mind right off hand. Why number it
>> 0 to 30 when it could be 1 to 31?

Anyone who buys into that argument probably should give up a career in
programming. Every compiler is capable of compiling the offset as a
constant into the base address as - guess what - a ~constant offset~.

So if the .NET whoopdydoo can't account for an array offset which is a
compile time constant - not a runtime thing - then the wonder boys did a
crappy job designing that interface.

Whoever wrote that article is blowing smoke - pure smoke.

FORTRAN handled that problem over forty years ago without blinking. It
didn't matter what the base of the array was - the compiler simply added
the offset to the base address of the array and away it went. The
initial index could be negative, zero, or positive.

Blowin' smoke - the microsoft way. They're still spreading the FUD and
covering their a$$es. Ludicrous this is.

"Stefan Berglund" <sorry.no.koolaid> wrote in message
news:goki
> On Tue, 22 May 2007 09:24:14 +1000, "Michael C" <nospam>
> wrote:
> in <u7Aeb8$mHHA.2596>
>> Anyone who buys into that argument probably should give up a career in
> programming. Every compiler is capable of compiling the offset as a
> constant into the base address as - guess what - a ~constant offset~.
>
> So if the .NET whoopdydoo can't account for an array offset which is a
> compile time constant - not a runtime thing - then the wonder boys did a
> crappy job designing that interface.
>
> Whoever wrote that article is blowing smoke - pure smoke.

Yep, just like the arguments for most of the changes being "required by the
platform". MS had no understanding of what they had with VB and no interest
in preserving it. All the rest is a cover story to not have to admit to the
major mistakes they made.

Oh, no. Sorry. Actually, I don't know to be frank. I toyed with VB 2005
Express for a bit but not to the point where I could answer that correctly.
:)

- Kev

"Michael C" <nospam> wrote in message
news:3656
| "Kevin Provance" <casey> wrote in message
| news:2296
| > Option Base 1 at the general decs level will force arrays to start at 1.
|
| In vb.net?
|
| Michael
|
|

| All the rest is a cover story to not have to admit to the
| major mistakes they made.

Microsoft is run by the Republican party? <eg>

"Kevin Provance" <casey> wrote in message
news:3460
>| All the rest is a cover story to not have to admit to the
> | major mistakes they made.
>
> Microsoft is run by the Republican party? <eg>

No, they just use each other's playbooks

"Bob Butler" <noway> wrote in message
news:a716
> "Steve Gerrard" <mynamehere> wrote in message
> news:nz2d
>
> There are a few things that may not have been feasible to implement but MS
> then looked at it and said
> since we can't do everything let's not worry about doing anything". The
> attitude was, and still is, that VB is a toy language suitable only for
> throw-away work.

Lest I be branded a .Netter (more so than I am), let me clarify. I think MS did
an appalling job of managing the roll out of .Net, and have gone on to do an
appalling job of managing the Vista roll out.

The demos available from MS on .Net are an excellent example of their disconnect
from real world developers - both the C# and VB ones, I might add. They are all
trivially simplistic demos, with relentless emphasis on drag and drop and "not
having to write any code" - as if writing 6 lines of elaborate XML with
attributes was any easier than writing 2 or 3 lines of program code to establish
a database connection, to pick on one example. Equally aggravating is the
proliferation of wizards that generate mounds of repetitive code, and like the
wizards in VB6, are only useful for first and second tries. One of their "best
practices" web pages suggests that laying out the data model for an application
should take about 15 minutes. Yikes.

I am also sick of hearing about "visually compelling experiences" in regard to
Vista. MS seems to believe that everyone sits around admiring their tool bars or
something, while in fact they are browsing YouTube and could care less about the
window frame. A real world "visually compelling experience" is finding out
whether Britney was wearing her underpants, not whether the browser title bar
was translucent.

Unlike some, I have found that for some purposes, .Net works well, and I am
quite happy with how my .Net project at work, a corporate database app, is
working out. The real task in going .Net is wading through the enormous class
library and working out which parts to use to get useful results. It is a task
regardless of which .Net language you go to, by the way. If only it were as easy
as finding the new constant to use for red.

You might find it amusing that .Net Framework 3.0 has a new section called
Microsoft.VisualBasic.Compatibility.VB6 (you can find it on MSDN). It includes
such sensible things as "drop in" replacements for the ADODC control, and the
File System Object. They are trying harder, but they still don't get it...

> I'm definately not the first person. The problems are extensive but
> basically you're not making a real app. With VB6 you have to work to add
> the required functionality. In access you have to work to remove a lot of
> functionality in an attempt to make it look like a real app. The forms
> just look plain ugly and outdated because they made all their own
> controls.

Really? I've always thought VB6 forms suffered from that. Besides, in
either case, you can always load in custom controls, so I don't see that as
a huge issue.

> This also eliminates the possibility of using APIs on the controls because
> they are not real windows controls.

Such as? I've never seen a need to use an API on a control...for anything.
It's probably cuz I'm a DB person; I don't need my controls to do funky
things, I need them to work. The Access controls do that far better than
the built-in VB controls in my experience.

> Then there's the instability of the backend and problems with customers
> having different versions.

What instability? The only real issue is the problems when an app shuts
down unexpectedly. I'll admit, they could've done a bit better of a job
with that in Access. As for compatibility, they're all backwards
compatible...the newer ones are seamless and transparently backwards
compatible. As long as you're not looking for forwards compatibility, it
should be a problem.

>> Oh but they do...they could choose to go the same route they did with
>> VB.NET and break compatibility with all former applications, forcing all
>> existing code to be re-written. But that would be a dumb idea, wouldn't
>> it? ;-)
>
> They could not do that and you know it. It is a different situation to
> what has happened with dot net and your analogy doesn't quite hold water.

That's not the way many of us see it.

> With VB6 you can still develop apps in vb6 that will run on all OSs.

And cross your fingers and pray to any and all divinities if you're trying
to run it on Vista...or so I hear. :-)

> A better analogy would be if they implemented a new API structure in
> windows but kept the old one also, which is exactly what they do all the
> time.

Ah, but in VB.NET, they didn't keep the old one also, did they? They simply
trashed the old one and told you to re-write with the new structure.

> I should be able to create a table called Person with FirstName, LastName
> etc and then create Staff and Customer tables that inherit from Person. I
> haven't ever used it so not sure how well it would work in reality.

I've never heard of database tables supporting that functionality...though
admittedly, most of my experience is with the MS products. That sounds like
something that should be the work of an OO language, not a database itself.

> Have a read of this one, it looks like they tried to have non-zero based
> arrays but decided against it for very good reason.
> [..]

Thanks for that. I at least understand the thought behind it now, though
given that C# and VB.NET go through so much else, being managed languages, I
wouldn't have thought the performance hit (or size hit, if they'd followed
Karl's suggestion in the commentary) of a non-zero array would really be
that big of an issue.

> I would prefer 1 based arrays myself but am more than happy to have all
> zero based arrays if that means we have consistancy. I agree it's a little
> confusing going from 0 to 30 but this is the same with any list of items.
> The first item is index zero, the second is index 1 etc.

True enough. Personally, I almost never use anything but 0-based arrays,
but it certainly IS convenient at times to have the choice.

>>> I'm suprised a third party hasn't released a better upgrade tool. It
>>> wouldn't be hard to do and would be popular and could be fairly
>>> expensive.
>>
>> Yes, it would be EXTREMELY popular, I'd imagine.
>
> Could be a good project for those on this group.

We should ask Rick Rothstein to do it. He'll manage it in just one line!
;-)



Rob

>| All the rest is a cover story to not have to admit to the
> | major mistakes they made.
>
> Microsoft is run by the Republican party? <eg>

You've got that backwards, Kevin!



Rob

"Stefan Berglund" <sorry.no.koolaid> wrote in message
news:goki
[..]
>
> Whoever wrote that article is blowing smoke - pure smoke.
>
> FORTRAN handled that problem over forty years ago without blinking. It
> didn't matter what the base of the array was - the compiler simply added
> the offset to the base address of the array and away it went. The
> initial index could be negative, zero, or positive.
>
> Blowin' smoke - the microsoft way. They're still spreading the FUD and
> covering their a$$es. Ludicrous this is.

Really? How exactly does that work when you pass the array to an already
*compiled* componented. Basically it doesn't so the array needs to store the
lbound which will slow things down. The article did mention this.

Michael

> Unlike some, I have found that for some purposes, .Net works well, and I
> am quite happy with how my .Net project at work, a corporate database app,
> is working out.

I'd be curious to hear more about what you've done in .Net with database
apps, as that's my main function at work as well. I had considered going to
..NET early on, but gave that up based on speed concerns. For now, it's
staying in Access (with most of the code actually being in VB6 DLL's), but
I'd be curious to hear what someone else has done successfully with it.
Feel free to take this private, as I doubt the rest of the group wants to
hear much about .NET. :-) My e-mail address should be fairly obvious if you
look at it, but post back if you have any difficulties de-obfuscating it.

> It includes such sensible things as "drop in" replacements for the ADODC
> control, and the File System Object. They are trying harder, but they
> still don't get it...

Hmmm...drop-in replacements for a) a moderately unused control (most VB'ers
skip the control and use ADODB, right?...like I've said before, I'm an
Access guy, so VB6's data-binding...by either method...is a little foreign
to me) and b) a totally disparaged library that people have been told never
to use. Good thinking, MS!



Rob

"Steve Gerrard" <mynamehere> wrote in message
news:nz2d
> Lest I be branded a .Netter (more so than I am), let me clarify. I think
> MS did an appalling job of managing the roll out of .Net, and have gone on
> to do an appalling job of managing the Vista roll out.
>
> The demos available from MS on .Net are an excellent example of their
> disconnect from real world developers - both the C# and VB ones, I might
> add. They are all trivially simplistic demos, with relentless emphasis on
> drag and drop and "not having to write any code" - as if writing 6 lines
> of elaborate XML with attributes was any easier than writing 2 or 3 lines
> of program code to establish a database connection, to pick on one
> example. Equally aggravating is the proliferation of wizards that generate
> mounds of repetitive code, and like the wizards in VB6, are only useful
> for first and second tries. One of their "best practices" web pages
> suggests that laying out the data model for an application should take
> about 15 minutes. Yikes.

I completely agree with this. The worst part about this is the drag-drop
programmers use this to back up their arguements at work. I've stated what
you've stated above many times at work. I think MS are just advertising
their new features.

> I am also sick of hearing about "visually compelling experiences" in
> regard to Vista. MS seems to believe that everyone sits around admiring
> their tool bars or something, while in fact they are browsing YouTube and
> could care less about the window frame. A real world "visually compelling
> experience" is finding out whether Britney was wearing her underpants, not
> whether the browser title bar was translucent.

I have to agree there too. The real tragedy of this is that faster and
faster machines are being forced apon us that we really don't need. There's
been a push lately for small cheap green machines ($100 to $300) that would
serve 90% of the population's needs (word, web, email). This is being
erroded by MS and wanky visual effects in vista.

> Unlike some, I have found that for some purposes, .Net works well, and I
> am quite happy with how my .Net project at work, a corporate database app,
> is working out. The real task in going .Net is wading through the enormous
> class library and working out which parts to use to get useful results. It
> is a task regardless of which .Net language you go to, by the way. If only
> it were as easy as finding the new constant to use for red.

There's a similar amount of stuff for vb6, possibly even more, it's just not
referenced by default.

> You might find it amusing that .Net Framework 3.0 has a new section called
> Microsoft.VisualBasic.Compatibility.VB6 (you can find it on MSDN). It
> includes such sensible things as "drop in" replacements for the ADODC
> control, and the File System Object. They are trying harder, but they
> still don't get it...

Didn't they have that from version 1.0?

Michael

"Michael C" <nospam> wrote in message
news:3544
> "Steve Gerrard" <mynamehere> wrote in message
> news:nz2d
>>> You might find it amusing that .Net Framework 3.0 has a new section called
>> Microsoft.VisualBasic.Compatibility.VB6 (you can find it on MSDN). It
>> includes such sensible things as "drop in" replacements for the ADODC
>> control, and the File System Object. They are trying harder, but they still
>> don't get it...
>
> Didn't they have that from version 1.0?
>

They have had Microsoft.VisualBasic for since 1.1, anyway, but I think the
..Compatibility.VB6 section is new.

It does help quite a bit to "Import Microsoft.VisualBasic" in most modules, I
would certainly agree, especially for all the classic VB string functions.

"Robert Morley" <rmorley> wrote in message
news:a716
> Really? I've always thought VB6 forms suffered from that. Besides, in
> either case, you can always load in custom controls, so I don't see that
> as a huge issue.

VB6 controls are standard windows controls. Access controls are not. You
could load activeX controls but you'd need to get them from somewhere and
they don't exist afaik.

> Such as? I've never seen a need to use an API on a control...for
> anything. It's probably cuz I'm a DB person; I don't need my controls to
> do funky things, I need them to work. The Access controls do that far
> better than the built-in VB controls in my experience.

I use API all the time for enhanced functionality in vb6 (eg userdrawn items
in a listbox). What about access controls is better?

> What instability?
> The only real issue is the problems when an app shuts down unexpectedly.
> I'll admit, they could've done a bit better of a job with that in Access.

We get between 2 and 5 corrupt databases sent to us a week out of 500 users.
Some can be recovered, some can't. Access basically doesn't work over
wireless (most of our users are not on

> As for compatibility, they're all backwards compatible...the newer ones
> are seamless and transparently backwards compatible. As long as you're
> not looking for forwards compatibility, it should be a problem.

It will ask to upgrade etc. If they upgrade then they can't go back. I know
you can get around it but you need to do that.

With access the end result feels a lot less professional to me than a vb6
exe.

>> They could not do that and you know it. It is a different situation to
>> what has happened with dot net and your analogy doesn't quite hold water.
>
> That's not the way many of us see it.

Your analogy would hold more water if vb6 didn't work on vista but it does.

>> With VB6 you can still develop apps in vb6 that will run on all OSs.
>
> And cross your fingers and pray to any and all divinities if you're trying
> to run it on Vista...or so I hear. :-)

So far it works.

> Ah, but in VB.NET, they didn't keep the old one also, did they? They
> simply trashed the old one and told you to re-write with the new
> structure.

The old one is still available in vb6.

> I've never heard of database tables supporting that functionality...though
> admittedly, most of my experience is with the MS products. That sounds
> like something that should be the work of an OO language, not a database
> itself.

It could have huge potential in a database.

> Thanks for that. I at least understand the thought behind it now, though
> given that C# and VB.NET go through so much else, being managed languages,
> I wouldn't have thought the performance hit (or size hit, if they'd
> followed Karl's suggestion in the commentary) of a non-zero array would
> really be that big of an issue.

I wouldn't think it would be that big a hit but I guess it has to subtract
that number for every single array access.

> True enough. Personally, I almost never use anything but 0-based arrays,
> but it certainly IS convenient at times to have the choice.

I would much prefer 1 based arrays. There are so many reasons it works
better, but I'm happy to use zero if it means consistancy, even with API
etc.

> We should ask Rick Rothstein to do it. He'll manage it in just one line!
> ;-)

Would have to be 1 big line of code.

Michael