"Steve Gerrard" <mynamehere> wrote in message
news:nz2d
> They have had Microsoft.VisualBasic for since 1.1, anyway, but I think the
> .Compatibility.VB6 section is new.

I've got that on 2 machines using 2003 although the framework v2.0 is also
on both.

> 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.

It's best to avoid these really.

Michael

In article <eQCpoJCnHHA.716>,
rmorleyn says...
> > 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.

I imagine some of the object databases out there (as opposed to the
relational that we're all used to) would work this way. I've never
worked with any of them, though.

"Steve Gerrard" <mynamehere> wrote in message
news:nz2d
> 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.


strange though that when coding in what they tout as "VB" you have to
explicitly import VB to get anything at all that looks right (not that it
all works... IIRC the 'compatibility' module had functions that were
incompatible)

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

I don't need userdraw functionality in a listbox, so it's never been a
concern for me. As for what's better about them, I suppose it depends on
what you're trying to do. Certainly data binding's much easier in Access,
though that's to be expected. I think the biggest single thing that I find
useful in Access listboxes (though there are probably others if I go
looking) is that they can handle multi-column data, where a VB6 listbox
can't, AFAIK.

>> 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

Ah, yes, that would be a problem. They're almost certainly dropping the
connection, even if only momentarily, and Access' biggest single flaw is
coming into play (the previously-mentioned issue of an app terminating
unexpectedly, or in this case, the connection to it terminating
unexpectedly). In this sort of scenario, yeah, you'd want to avoid Access
at all costs! :-)

> 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.

It does? I've never had a database prompt me to upgrade, unless it was v2.0
or before...which is more than a little old at this point.

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

I suspect that comes back to what you're doing with it, and how you're doing
it. I've yet to see a VB6 app that I thought felt more professional than an
Access app (in fact, most that I've seen come across as dinky little flunky
apps...though I blame that entirely on their designers, not VB6 itself).
That said, I've seen a few that have come across as equal, and only rarely
one or two that I thought felt more professional, and those few were because
they were using snazzy outside controls and the like, that one normally
wouldn't think of in Access because their predecessors are available and
will get the job done...they just don't look/feel quite as nice.

>> 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 a few problems, as I understand it. Certainly since the release of
Vista, I've seen a lot of posts here talking about problems getting either
VB6 itself or a VB6 app running on Vista.

>> 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.

Which was sort of the point...migrate your apps to our new structure, or
continue to use the old one and just ignore the new one...but you can't use
your old stuff in our new stuff. (Or get bogged down in COM interop, but
that's a whole 'nother set of problems.)

>> 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.

It could, yes, but I'm not entirely sure if that would be a good thing or
not. I suspect that would be a very inefficient design at the low level,
and would cause a lot of slowdowns. Besides, when you get right down to it,
that's essentially what Views are for anyway. Your table is the "base
class", and the views allow you to inherit from it and expand it into
multiple different types of objects, each looking and behaving much the same
as the original, with the option to add new fields, override existing ones,
or hide them at will.

>> 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.

Yeah, I can see it adding up in some cases, but I'm surprised that that
would really be that big of an issue.

>> 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.

Wouldn't it, though!



Rob

"Robert Morley" <rmorley> wrote in message
news:3872
> I suspect that comes back to what you're doing with it, and how you're
> doing it. I've yet to see a VB6 app that I thought felt more professional
> than an Access app

I suspect it may be more what you learned first/best; I've rarely seen
anything done in access that looked at all professional. Most look to me
like a kindergarten attempt at an application.

On Mon, 21 May 2007 20:54:57 -0700, "Steve Gerrard" <mynamehere> wrote:


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

Just an FYI, it's been there since the first version but it was not intended to be long for the
future.


Paul
~~~~
Microsoft MVP (Visual Basic)

On Mon, 21 May 2007 06:46:11 -0700, "Bob Butler" <noway> wrote:

¤ Changing the underlying platform from COM-based to .Net-based is not
¤ justification for the language syntax changes that were made though. Things
¤ like changing Label1.Caption to Label1.Text, removing Gosub/Return, and
¤ renaming the enumeration constants (to take just a few simple examples) were
¤ simply gratuitous. When a VB coder writes "Text1.BackColor = vbRed" he
¤ doesn't care whether it uses COM, the win32 API or voodoo as long as the
¤ result is a red textbox on the screen. Even the issue of zero-based arrays
¤ could have been handled in .Net (perhaps with a performance penalty but
¤ telling me that my code will move forward and run but I may want to rewrite
¤ to get better performance would have been 1000% better than the current
¤ situation).

Of course a number of the changes weren't really language changes. Controls are part of the Forms
library and don't belong to the language. In any event, if you really want a Caption property for
your Label it would be rather easy to add.


Paul
~~~~
Microsoft MVP (Visual Basic)

HEhehe...yeah, that's exactly what I've seen in VB. Probably strictly a
case of the designer's skill, and has little to do with VB/Access issues.
:)


Rob

"Bob Butler" <noway> wrote in message
news:4896
[..]

Stefan Berglund <sorry.no.koolaid> wrote:
> 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.

That's a "no duh!" from this corner, too.

> Whoever wrote that article is blowing smoke - pure smoke.

Lessee... panopticoncentral, eh? Yeah, he does that for a living. He's the same
guy who decided to change the width of Integer and Long because -- yes, he told me
this -- because C programmers coming to VB couldn't be bothered to RTFM and were
constantly confused by the fundamental datatypes.

So, to be as clear as possible -- Paul Vick is the single person most responsible
for the destruction of the language. I'd call him a "lying dirtbag" but I'm sure
the accuracy of such a characterization (from either direction) is challengable.
Let's just leave this by pointing out that he holds the patent (on MSFT's behalf)
for iSnot.

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

That's Paul Vick's job, alright!

Michael C <nospam> wrote:
> 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.

Gee, SAFEARRAYs stored lbounds, and they seemed quick enough for most purposes.

> Let's just leave this by pointing out that he holds the patent (on MSFT's
> behalf) for iSnot.

iSnot? I'm sure it's supposed to be something else, but it's not coming to
me.


Rob

Bob Butler <noway> wrote:
> "Steve Gerrard" <mynamehere> wrote ...
>> 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.
>
> strange though that when coding in what they tout as "VB" you have to
> explicitly import VB to get anything at all that looks right

Only strange in the strictly *non-*Orwellian sense, ...

Robert Morley <rmorley> wrote:
>> Let's just leave this by pointing out that he holds the patent (on MSFT's
>> behalf) for iSnot.
>
> iSnot? I'm sure it's supposed to be something else, but it's not coming to
> me.

Google is your friend. ;-)

http://www.google.com/search?q=patent+isnot

Thanks. Didn't think to look on Google, cuz I assumed it was a deliberate
misspelling of something else, not just a mis-capitalization of it.



Rob

"Karl E. Peterson" <karl> wrote in message
news:3656
[..]

Robert Morley <rmorley> wrote:
> Didn't think to look on Google, cuz I assumed it was a deliberate
^^^^^^^^^^
> misspelling of something else, not just a mis-capitalization of it.

You misspelled "gratuitous" -- HTH! ;-)