UDTs (as was vb6)

[Cor]

"Mayayana" wrote in message <snipped message>
(One can see a humorous example of that
with Microsoft advertising. Big ads in places like the
NYT that drone on with undecipherable jargon about
leveraging next-gen solutions and the like. The
Microsofties don't seem to realize that outside of
their current developer clientelle those words are just
gobbledygook -- a semi-literate slang composed of
tech. words, strategic marketing valorization, teen-
speak, and rampant, random "verbification".)
<end snipped message>

Mayayana, in past I was often thinking like you seems to show here. However,
then I realise me that Microsoft is not one person who lives in Redmond. It
are many persons, who live all over the world and some of those, especially
the marketing guys take words, which sounds elite for them to use, but they
probably never will understand what they wrote.

They get them from those developer guys who like that jargon to put them on
a more elite place. All my life I've tried to avoid that and to speak and
write without that jargon.

That is probably also why I often dislike it to be active in C# forums or
newsgroups, where that is even more common, the major base of vb users (also
Net) seems to be more with their feet on the ground.

A culture you most probably don't know, is the culture outside the English
language world, where some think that using English (sounding) words makes
it more educated; Although I see often from (some) Americans that those
think that it is better to use an not ordinary French or Spanish derived
word in English than a common Anglo Saxon word, in my idea with the same
reason.

However, I try to avoid currently saying "Microsoft does" like I currently
avoid writing "Americans do" and then mean in fact only some persons in the
American government. At Microsoft are many who have probably the same
opinion like you and me about this.



Cor

 

[Cor]

Sorry for the double posts, seems to have some problems with my newsgroups
provider server or the Microsoft Live Mail I still use.

 

[Tom Shelton]

Mayayana formulated the question :

I have trouble with that, too. Language is often
not a strong suit with programmers. I'm guessing the
unfortunate choice of the term "namespace" is a
leftover from the 80s. ("I just moved into
a new space. I think there's room there for a workspace.
But it's not a very romantic space. I might be spending
more time at my girlfriend's space. Then again, maybe
not. I need more space."

I find this explanation in MSDN:

"A namespace declaration identifies and assigns a name to a declarative
region."

That's a very precise answer. The concept of namespaces is not new in
..NET. They are used in many object oriented languages - including C++,
which is why you have a similar concept in COM. They are sometimes
refered to by different names - for instance, Java calls them packages
- but, the idea is the same.

It is simply a way of creating a unique name for a class, so that you
can disambiguate your intention to the compiler in cases where you
might have multiple implementations with the same class name...

Even VB6 has this concept - it shouldn't be that new...

 

[Mayayana]

| then I realise me that Microsoft is not one person who lives in Redmond.
It
| are many persons, who live all over the world and some of those,
especially
| the marketing guys take words, which sounds elite for them to use, but
they
| probably never will understand what they wrote.
|
| They get them from those developer guys who like that jargon to put them
on
| a more elite place. All my life I've tried to avoid that and to speak and
| write without that jargon.
|

I suppose you're right that the marketing people
take programming jargon because it sounds
impressive, but I think it also goes the
other way. Marketing is basically amoral psychology.
They research and use whatever will affect people.
Much of the programming jargon originates with
the marketers. For instance: solution. Programmers
have been trained to use that to mean a coding
project. It's not a solution until it solves a problem.
Calling it a solution lends a positive spin to something
that is neutral.

Likewise with application. It's use is the application.

Both words imply that the software is inherently helpful.

Then there's "developer". A developer is someone who
builds housing projects and highrises. First it was software
author. But that sounds "artsy" rather than classy. Then
"architect" became popular, which is a ridiculous term
for someone who writes software. Then people realized
that the architect just designs the building, while the
developer controls the whole project, so "developer"
came into vogue. I suspect those terms came about through
some combination of vain programmers and clever managers
who were handing out "status upgrades" in lieu of pay
raises.

As a non-native English speaker I expect there are
subtleties of such word associations that are predictable
in their affect on the American listener, while being invisible
to you.

Actually I found Armin's explanation to be fairly
clear and helpful. But it's hard to follow because
it assumes prior knowledge, and many of the terms
we use -- like namespace -- are not intuitive. It's
difficult to understand things without knowing the
why and how of them.

On the bright side, I read recently that the HTML5
DOCTYPE tag is:

<!DOCTYPE HTML>

which replaces muck like this:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html>

So there's hope.

 

[Tom Shelton]

It happens that Mayayana formulated :

I suppose you're right that the marketing people
take programming jargon because it sounds
impressive, but I think it also goes the
other way. Marketing is basically amoral psychology.
They research and use whatever will affect people.
Much of the programming jargon originates with
the marketers. For instance: solution. Programmers
have been trained to use that to mean a coding
project. It's not a solution until it solves a problem.
Calling it a solution lends a positive spin to something
that is neutral.

Likewise with application. It's use is the application.

Both words imply that the software is inherently helpful.

To be honest, and I don't mean any disrespect, but I think both you and
Cor are out in left field here....

These are not marketing terms - but, generally accepted terms in the
software development industry. And they aren't even new. The concept
of namespaces is older then even your beloved VB6 (which in fact, has
the same concept).

These terms did not come about in an attempt at arrogance, but as a way
of communicating complex meanings in a simple manner between
professionals. This is happens in all industries. For instance, when
one learns basic OOP principles and the concept of patterns, you can
almost envision how something was implemented if the developer where to
tell you that they implemented some functionality using a Template
Method Pattern. Or maybe, Chain of Responsiblity...

The problem is that MOST vb developers even now are ignorant of these
common industry concepts and terms. I remember even back in the VB6
days, there were studies that showed that something like 70% of vb devs
had never written their own class - even though classes had been
available since vb4. And that even more had no concept of an
interface. There is a reason that VB is generally looked down upon in
the industry - it's not because their is anything really wrong with the
language, but the practitioners tend to be less informed, and seemingly
unwilling to learn new concepts.

 

[Armin Zingler]

Am 04.01.2011 17:47, schrieb Mayayana:

Actually I found Armin's explanation to be fairly
clear and helpful. But it's hard to follow because
it assumes prior knowledge, and many of the terms
we use -- like namespace -- are not intuitive. It's
difficult to understand things without knowing the
why and how of them.

If saying putting classes into namespaces is like putting
files into folders is assuming too much, then I don't know
how else to describe it.
But yes, you're right if I read it that one article doesn't qualify
for teaching everything-and-all. It was just one approach where
to start. However, I'm not sure if the OP is really interested
in learning it or in complaining about it.

 

[Cor]

Tom,

You are the first one who calls me a VB6 developer and even a lover of that.
However, before you tell something about me, than invest about what I was
writing.

I seldom do that in newsgroup messages, but to avoid this kind of messages,
I've snipped and quoted in your kind of way the text from Mayanama, where I
was writing about.

To repeat it even snipped more Mayayana's text in a shorter way to make it
even easier to read for you:
<>
that drone on with undecipherable jargon about
leveraging next-gen solutions and the like
<>
I was nowhere writing about namespaces, solutions, development so leave
generic judgement about my knowledge please out of messages.

Probably also because of the fact that my native language is the most
cognate one to the English language, it is easily to understand the deeper
intention of Mayayana message, an intention about which I gladly agree.

However, to surprise you, I've the idea to know what OOP is and even OOD
without confusing those two.

To make the intention clearer, it is not about the meaning of the words, but
the way those words are used by those who have not the slightest idea what
they mean.

Thanks,

Cor

"Tom Shelton" wrote in message

It happens that Mayayana formulated :

I suppose you're right that the marketing people
take programming jargon because it sounds
impressive, but I think it also goes the
other way. Marketing is basically amoral psychology.
They research and use whatever will affect people.
Much of the programming jargon originates with
the marketers. For instance: solution. Programmers
have been trained to use that to mean a coding
project. It's not a solution until it solves a problem.
Calling it a solution lends a positive spin to something
that is neutral.

Likewise with application. It's use is the application.

Both words imply that the software is inherently helpful.

To be honest, and I don't mean any disrespect, but I think both you and
Cor are out in left field here....

These are not marketing terms - but, generally accepted terms in the
software development industry. And they aren't even new. The concept
of namespaces is older then even your beloved VB6 (which in fact, has
the same concept).

These terms did not come about in an attempt at arrogance, but as a way
of communicating complex meanings in a simple manner between
professionals. This is happens in all industries. For instance, when
one learns basic OOP principles and the concept of patterns, you can
almost envision how something was implemented if the developer where to
tell you that they implemented some functionality using a Template
Method Pattern. Or maybe, Chain of Responsiblity...

The problem is that MOST vb developers even now are ignorant of these
common industry concepts and terms. I remember even back in the VB6
days, there were studies that showed that something like 70% of vb devs
had never written their own class - even though classes had been
available since vb4. And that even more had no concept of an
interface. There is a reason that VB is generally looked down upon in
the industry - it's not because their is anything really wrong with the
language, but the practitioners tend to be less informed, and seemingly
unwilling to learn new concepts.

 

[Mayayana]

I'd make a distinction between poorly defined
technical terms (namespace) and marketing
terms (solution / developer / architecting). I don't
know how long "solution" has been around, but
it's nonetheless a marketing term. Those 3 words
are all designed to glorify the original meaning
in some way.

I'd agree about VBers, though. Learning VB is
starting at the top and going down. As is the
case with .Net. I found it very difficult to understand
the meaning of variable at first. x = x + 1 didn't
seem to make sense. It wasn't until I had some
understanding of the underlying hardware that I
could see why programming works the way it does.

I think the problem with something like "namespace"
is that it doesn't really say anything. It means context,
but that means nothing without knowing the context
of what. Just as COM's CreateObject(server.class) is
hard to understand until one knows the basic layout
of COM, with DLLs, typelibs, and classes/objects.
Shelton is a namespace. Tom is a class. Shelton
"disambiguates" the Tom class. Try telling that to
your kids.

Actually, reading Armin's explanation, wouldn't
it be accurate to say that importing a namespace
is equivalent to VB6 referencing a typelib?
It's hard to grasp referencing in VB6 until one understands
that these are COM libraries and that, for instance,
to reference Shell Objects is to load the Shell32.dll
COM objects. Likewise, a DotNetter encounters the
ability to import without necessarily getting an
explanation of the underlying libraries. And it doesn't
help that terms get changed around willy nilly.
(One of the best examples I know of is INI/Registry,
where section/key/value became key/value/data for
no reason.)
To some extent namespace/class/server/object are
synonymous.

 

[Mayayana]

|
| If saying putting classes into namespaces is like putting
| files into folders is assuming too much, then I don't know
| how else to describe it.

I don't think that's a workable analogy. The only
shared aspect is hierarchy. Files-and-folders works
as a metaphor in Explorer because it mimics a known
physical relationship. And the metaphor works. One
doesn't need to know how files are stored on disk.

Otherwise I found your explanation clarifying. I can see
how .Net is just using different terms to describe abstract
contexts, references and scope. But I don't think I'd be able
to follow the explanation if I didn't already understand
those things.

| However, I'm not sure if the OP is really interested
| in learning it or in complaining about it.
|

Maybe both.

 

[StrandElectric]

Absolutely right on! Nearly all of the discussion here is way above my head
(and so is the Dummies book!) because it is not practical; it's too
abstract. The very first exercise in the Dummies book shows that
extraordinary syntax of code you get when eg you create a command button and
does not even say something like 'Don't worry about those lines yet; we'll
explain them later but in the meantime they are put automatically at the
start and finish of every routine.' Bang. They are just there. Even the
operation of the IDE is not really explained (thankfully I was familiar with
it from vb6)

Another thing that puzzled me, even in vb6, was the use of Capitals and
lower case letters in eg a variable like SmithAndSons, until I figured out
for myself that it is just a convention to help you make long words out of
short ones, and generally that capitals are optional. Nowhere have I read
that.

I don't think I'm exceptionally dim. I have qualified in a number of
professions throughout my life, and have built a working accounts suite with
vb6 that WORKS. It uses such practical things as UDTs to read old random
access files and also prints meaningful accounting reports. I use it live
every day to manage my existing business (in the educational field!). Yet
could I get straight answers to my queries about how to do either with
dot.net? Could I ever?

Even the vb6 books (I have a heap of them) did not cover printing. It took
an excellent ex-MVP to teach me that in a few well-pitched sentences!

I will persevere for now but I am beginning to think that the dot.net
developers have disappeared up....[substitutes civilised terminology] a
self-sustaining world of theoretical abstraction where nothing practical is
achieved without deliberate obfuscation.

It seems as though Micro$oft, heving created a superb tool in vb6 (which I
have only scratched the surface of) sat down and said 'This is no good.
We've made something practical and although there are some airy fairy
concepts, a reasonably competetent person can USE this. So let's scrap it
and substitue something that we've dreamed up for ourselves for internal use
without any regard for those fools in the outside world. Don't make anything
intuitive, or straightforward, whatever we do. And, by the way, let's keep
on changing it so that people have to buy upgrades or new packs every year
or so. And when the idiots have struggled with that, let's ditch it and go
for something even more obscure'

Yesterday I had to replace the thermostat on my 1987 Jag. The procedure was
something like

Wait for coolant to cool if the car has been used in the last couple of
hours.
Drain coolant, by unscrewing lower radiator plug (see Fig 1)
Remove the two thermostat cover bolts (Fig 2) loosening evenly across the
two
Knock the thermostat cover with a wooden or soft hammer to break any
previous gasket seal
Place the new thermostat in the housing, with a new rubber 'O' ring on the
top (Fig 3)
Replace the thermostat housing and evenly tighten the two securing bolts
Finally, torque up the bolts using a torque wrench set to xyz Newtons
(sorry, Ft/lbs!)
Replace radiator drain plug
Refill with Bloggins ABC coolant.

The non-mechanic would have to read the leaflet that came with the torque
wrench. The rest is intuitive.

What would the vb.net developers have made of that?

Analyse, using spectrum chromatography, the chemical consituents of the
coolant. Convert any anomalies arising using regression analysis
Consider the stresses in a molecular enviroment of the fasteners in
aluminium to aluminium joints
Remember that the hammer is of a class of devices that extend the user's arm
so that more force can be applied to the workpiece BUT do not allow an
entity with more molecular density to come into contact with one of less, in
order to avoid displacing the molecular boundaries
Examine the user documentation that came on the new thermostat (careful!
this is verging on the hypocrisy of practically) and reparse the sentences
in order to change the passive to the active and precis accordingly
Apply the annular ring as appropriate but only in a way that allows closing
of the active internal space to prevent migration of the heat-transferring
substance (or better still the class or namespace encsapsulating the
substance -- note this is not reusable except in emergency)

....and so on

Actually, those statements, with a couple of exceptions, are not nonsense
but the effect of giving them to someone who needs to change a thermostat
(to DO it, as well as pick up background on the way) is totally
counterproductive and plain stupid.

A wag once claimed that much of etiquette (eg some types (classes?)
(namespaces?)) of table manners) were a device intended by those in the know
to make those not in the know uncomfortable. Although I happen to find gross
table manners well... gross, even such things as chatting on a mobile phones
during meals, there is some truth in the assertion.

A simple practical example in the frenzy of making everything more
complicated than it needs to be is the current Australian 'police-speak'. It
goes like this... Instead of 'The man was allegedly murdered overnight' we
hear that 'The man has been allegedly murdered overnight'

Well I must terminate this discourse. I am about to cause molecular motion
in the coffee jug as my wife has returned from somnabulance to a state of
consciouness and is applying force to her vocal cords, setting up pressure
waves which my aural apparatus has intercepted. She has detected an internal
need (in her namespace, perhaps?) for the effect of Caffeine

Come back Dr David Lien. Now *there* was an educator!

I feel better now...

 

[Tom Shelton]

Mayayana wrote :

I'd make a distinction between poorly defined
technical terms (namespace)

I would disagree that it is poorly defined... It maybe implemented
differently by differnt languages - but the concept is the same for all
of them.

and marketing
terms (solution / developer / architecting). I don't
know how long "solution" has been around, but
it's nonetheless a marketing term. Those 3 words
are all designed to glorify the original meaning
in some way.

I wouldn't agree with those terms being marketing terms either. They
have specific meanings in this industry. An architect has a very
specific job in a team/project. You may not like the term, but it's
been around for a long time now.

I'd agree about VBers, though. Learning VB is
starting at the top and going down. As is the
case with .Net. I found it very difficult to understand
the meaning of variable at first. x = x + 1 didn't
seem to make sense. It wasn't until I had some
understanding of the underlying hardware that I
could see why programming works the way it does.

I think the problem with something like "namespace"
is that it doesn't really say anything. It means context,
but that means nothing without knowing the context
of what. Just as COM's CreateObject(server.class) is
hard to understand until one knows the basic layout
of COM, with DLLs, typelibs, and classes/objects.
Shelton is a namespace. Tom is a class. Shelton
"disambiguates" the Tom class. Try telling that to
your kids.

Actually, reading Armin's explanation, wouldn't
it be accurate to say that importing a namespace
is equivalent to VB6 referencing a typelib?

Not exactly. You can reference a library, but not import the
namespace. If you don't import the namespace (basically, add it to
your current namespace) then you have to fully qualify any objects you
use from that library... So, for example, if I define the following in
my library:

Namespace FireAnt.Util
Public Class FileSystemUtils
...
End Class
End Namespace

And then compile that into an dll - FireAnt.Util.dll

I can reference FireAnt.Util in another project (add references dialog)
- but, unless I add it to the global imports in the project settings, I
would have to type:

Dim fsu As New FireAnt.Util.FileSystemUtils

every single time I wanted to create the object. Alternatively, I can
simply add:

Option Strict On
Option Explicit On
Option Infer On

Imports FireAnt.Util


At the top of my file, and then I can just use:

Dim fsu As New FileSystemUtils

That's assuming of course that you don't have a reference to another
dll with a class called FileSystemUtils. If that was the case, then
you might have to do something like:

Option Strict On
Option Explicit On
Option Infer On

Imports FA = FireAnt.Util
Imports SO = SomeOther.Util ' also has a FileSystemUtils class

And then you could use both in the same code:

Dim fafsu As New FA.FileSystemUtils
Dim sofsu As New SO.FileSystemUtils

You could fully qualify both - but, I like to use namespace alias's,
much less typing that way

It's hard to grasp referencing in VB6 until one understands
that these are COM libraries and that, for instance,
to reference Shell Objects is to load the Shell32.dll
COM objects.

Even in com your essentially dealing with namespaces. The naming
convention for com servers - Excel.Applicaton - helps distinguish
Word.Application.

Likewise, a DotNetter encounters the
ability to import without necessarily getting an
explanation of the underlying libraries.

Huh? it's called documentation - which can be generated with various
tools form code comments. Not sure what you mean here.

And it doesn't
help that terms get changed around willy nilly.
(One of the best examples I know of is INI/Registry,
where section/key/value became key/value/data for
no reason.)

Other the the structure of an INI and the Registry are completely
different?

To some extent namespace/class/server/object are
synonymous.

They are essentially the same - because namespaces are a major concept
in C++ which com is based on (yes, you can do com in straight C - but,
it is a pain because really com was based on a basic set of OOP
principals.)

 

[Tom Shelton]

Cor presented the following explanation :

Tom,

You are the first one who calls me a VB6 developer and even a lover of that.
However, before you tell something about me, than invest about what I was
writing.

I seldom do that in newsgroup messages, but to avoid this kind of messages,
I've snipped and quoted in your kind of way the text from Mayanama, where I
was writing about.

To repeat it even snipped more Mayayana's text in a shorter way to make it
even easier to read for you:
<>
that drone on with undecipherable jargon about
leveraging next-gen solutions and the like
<>
I was nowhere writing about namespaces, solutions, development so leave
generic judgement about my knowledge please out of messages.

Probably also because of the fact that my native language is the most cognate
one to the English language, it is easily to understand the deeper intention
of Mayayana message, an intention about which I gladly agree.

However, to surprise you, I've the idea to know what OOP is and even OOD
without confusing those two.

To make the intention clearer, it is not about the meaning of the words, but
the way those words are used by those who have not the slightest idea what
they mean.

Thanks,

Cor

<snip>

Cor, you misunderstand - I was not commenting on your knowledge at all.
I did make comments about vb users in general - and it is absolutely
true, and born out not only in real life experience, but by actual
studies.

I simply don't agree that the terms Mayayana is stuck on are
"marketing" terms. They all have specific meaning in the industry.

 

[Tom Shelton]

Mayayana submitted this idea :

I don't think that's a workable analogy. The only
shared aspect is hierarchy.

Which is the only part that matters - it implies a hierarchy. And why
the file-folders analogy IS relavent.

Files-and-folders works
as a metaphor in Explorer because it mimics a known
physical relationship. And the metaphor works. One
doesn't need to know how files are stored on disk.

In fact, some languages such as Java, actually enforce the hiearchy on
the physical code files.

Otherwise I found your explanation clarifying. I can see
how .Net is just using different terms to describe abstract
contexts, references and scope. But I don't think I'd be able
to follow the explanation if I didn't already understand
those things.

..NET is using different terms the VB6 - yes, but all are very well
known and well defined terms in the OOP community at large. Again,
namespace's are used in many languages, not just .net lanugages. The
term namespace predates .NET by quite some time.

 

[Tom Shelton]

StrandElectric expressed precisely :

Absolutely right on! Nearly all of the discussion here is way above my head
(and so is the Dummies book!) because it is not practical; it's too abstract.
The very first exercise in the Dummies book shows that extraordinary syntax
of code you get when eg you create a command button and does not even say
something like 'Don't worry about those lines yet; we'll explain them later
but in the meantime they are put automatically at the start and finish of
every routine.' Bang. They are just there. Even the operation of the IDE is
not really explained (thankfully I was familiar with it from vb6)

Another thing that puzzled me, even in vb6, was the use of Capitals and lower
case letters in eg a variable like SmithAndSons, until I figured out for
myself that it is just a convention to help you make long words out of short
ones, and generally that capitals are optional. Nowhere have I read that.

I don't think I'm exceptionally dim. I have qualified in a number of
professions throughout my life, and have built a working accounts suite with
vb6 that WORKS. It uses such practical things as UDTs to read old random
access files and also prints meaningful accounting reports. I use it live
every day to manage my existing business (in the educational field!). Yet
could I get straight answers to my queries about how to do either with
dot.net? Could I ever?

Hmmm... I gave you actual code using a random file and a udt in
VB.NET... What more do you want? I did suggest you convert your
program to not do it that way, for very good reasons. Those FileXXX
methods are very slow. They suck. And there are much better and
easier alternatives - once you spend a bit of time with the language.

As for printing... Sorry, just not my thing. I've never had any call
to do anything with it.

Even the vb6 books (I have a heap of them) did not cover printing. It took an
excellent ex-MVP to teach me that in a few well-pitched sentences!

I will persevere for now but I am beginning to think that the dot.net
developers have disappeared up....[substitutes civilised terminology] a
self-sustaining world of theoretical abstraction where nothing practical is
achieved without deliberate obfuscation.

LOL.. Abstraction is how modern software is developed for a very good
reason. It comes down to one of the first design principals of OOP:

Code should be closed to modification, but open to change.

It's the seperation of what is likely to remain static, from what is
likely to change. You may think it's diliberate obfuscation, but, it's
really cya for future change requests.

It seems as though Micro$oft, heving created a superb tool in vb6 (which I
have only scratched the surface of) sat down and said 'This is no good. We've
made something practical and although there are some airy fairy concepts, a
reasonably competetent person can USE this. So let's scrap it and substitue
something that we've dreamed up for ourselves for internal use without any
regard for those fools in the outside world. Don't make anything intuitive,
or straightforward, whatever we do. And, by the way, let's keep on changing
it so that people have to buy upgrades or new packs every year or so. And
when the idiots have struggled with that, let's ditch it and go for something
even more obscure'

LOL... Let me guess, you don't use classes and interfaces in your VB6
code. You have no concept of OOP, or you wouldn't feel this way.
VB.NET simply adds full OOP to what you had in VB6 - but, see most vb
developers don't understand that for some reason.

<snip more ranting nonsense>

Stick to vb6, but good luck in the future - if the rumors are true,
windows may not be x86 forever

 

[Armin Zingler]

Am 04.01.2011 19:50, schrieb Mayayana:

I think the problem with something like "namespace"
is that it doesn't really say anything. It means context,
but that means nothing without knowing the context
of what.

It's the space where names (mainly class names) reside.
Therefore, IMO, the term fits very well. But even if you don't like the
term, after an explanation it should be clear. And if one still doesn't
understand it, he can ask. Individual care is hard without knowing
the prior knowledge.

Actually, reading Armin's explanation, wouldn't
it be accurate to say that importing a namespace
is equivalent to VB6 referencing a typelib?

No, importing means adding the namespace to the name resolution
path. But I explained this too.

It's hard to grasp referencing in VB6 until one understands
that these are COM libraries and that, for instance,
to reference Shell Objects is to load the Shell32.dll
COM objects. Likewise, a DotNetter encounters the
ability to import without necessarily getting an
explanation of the underlying libraries.

In order to keep it simple, I didn't mention how to reference libraries
This prior knowledge is not necessary for importing a namespace.

 

[Armin Zingler]

Am 04.01.2011 20:20, schrieb StrandElectric:

Absolutely right on! Nearly all of the discussion here is way above my head

[my own text dropped]

As I take it from your other posts, you are just here to complain, bemoaning
the loss of the good old times. You are refusing to learn something new because
of the complot Micro$oft stages against you and the whole world. At least
it would have been nice of you if you had addressed my questions and attempts
of introduction.

Good luck!

 

[StrandElectric]

Am 04.01.2011 20:20, schrieb StrandElectric:

Absolutely right on! Nearly all of the discussion here is way above my
head

[my own text dropped]

As I take it from your other posts, you are just here to complain,
bemoaning
the loss of the good old times. You are refusing to learn something new
because
of the complot Micro$oft stages against you and the whole world. At least
it would have been nice of you if you had addressed my questions and
attempts
of introduction.

Good luck!

No, I'm not. But I can appreciate why you thought that. In fact, I love new
stuff, and was viewing Vb.net as a challenge and would dearly like to port
my accounts app to it, or preferably (I hear you say) rewrite it using
vb.net principles. I haven't understood your solutions (they are the wrong
level for this beginner) or I would have gladly tried them. (many thanks for
trying, BTW, and I'm sure I *have* thanked you before!)

Amongst the usual entry screen controls and general business logic (which
continue to be straightforward), my application makes use of these things:

1 random access file using UDTs
2 printing variables in formatted columns to a series of tabulated
reports
3 and in passing, nicely graduated colour screens (ie gradients).

1 and 2 were simple in interpreted BASIC, fairly straightforward in vb6 and
completely obscure and incomprehensible (to me anyway) in vb.net.

The last of the three is the least important, but as it happens I have
managed to unravel it and the vb.net code is far better, smaller (making use
of course of the NET framework) and works exceedingly well. So I had high
hopes for the others. Sadly, apparently without justification.

I'm still trying. That's why I'm here. I don't expect to influence any of
you of course. You are presumably 'in the know'. What I am trying to is
convey some of my frustration. Do not mistake a certain fluency with words
(I write and edit) with any kind of in depth knowledg of vb.

I repeat my requests. Is there a beginner's ng for vb.net? Is there a truly
basic book that anyone recommends? Is there someone out there with the time
to spend trying one-to-one to impart the necessary degree of knowledge for
me to at least achieve the aims above? And before I forget, NOTHING in any
of my so-called beginner's books explains in practical terms exactly how to
use a form of standard library (re-using code) which I have as a 'module' in
my vb6 apps ('module' meaning a section of code (is *that* a 'namespace'?)
as distinct from a form in vb.net? I have developed code for a number of
repetitive things that all my apps use in vb6 (like report headers and
tails, gradient screens, traps for non-number input and some sound effects)
in my 'library' module (don't even know if that is the right name) which I
use in vb6, and I call them from my user forms. How exactly is this done in
vb.net? 2008 Express for dummies has a whole eloquent chapter about
reusability of code and never says a practical word of how to implement it.
I suppose my diatribe is dirceted at that book more than anything else.

I realy must stop for now and get back to work analysing the results of an
exam I set in completely different discipline. You'll all be relieved to
know that it has nothing whatsover to do with programming!

Thanks again Armin.

Strand

 

[StrandElectric]

and my usual apology for typos!

 

[Armin Zingler]

Am 05.01.2011 00:45, schrieb StrandElectric:

Am 04.01.2011 20:20, schrieb StrandElectric:

Absolutely right on! Nearly all of the discussion here is way above my
head

[my own text dropped]

As I take it from your other posts, you are just here to complain,
bemoaning
the loss of the good old times. You are refusing to learn something new
because
of the complot Micro$oft stages against you and the whole world. At least
it would have been nice of you if you had addressed my questions and
attempts
of introduction.

Good luck!

No, I'm not. But I can appreciate why you thought that. In fact, I love new
stuff, and was viewing Vb.net as a challenge and would dearly like to port
my accounts app to it, or preferably (I hear you say) rewrite it using
vb.net principles. I haven't understood your solutions (they are the wrong
level for this beginner) or I would have gladly tried them. (many thanks for
trying, BTW, and I'm sure I *have* thanked you before!)

I didn't say you're not thankful, but it seemed you've started getting angry and
inadequate about the matter. Anyway, see below.

I repeat my requests. Is there a beginner's ng for vb.net?

No, not specialized on beginners. (not that I know of)

Is there a truly
basic book that anyone recommends?

I can't answer this. I don't have a VB.Net book. I always recommend reading
the manual first, but from a didactic point of view, I wouldn't call it
perfect.

Is there someone out there with the time
to spend trying one-to-one to impart the necessary degree of knowledge for
me to at least achieve the aims above?

Yep, for example here or in the MSFT community. I gave you the link.

And before I forget, NOTHING in any
of my so-called beginner's books explains in practical terms exactly how to
use a form of standard library (re-using code) which I have as a 'module' in
my vb6 apps ('module' meaning a section of code (is *that* a 'namespace'?)
as distinct from a form in vb.net?

I've explained it, but to understand it, you first must understand basic concepts.
Are you willing to learn them? I don't bother you with them this time, I just say
that Modules can be used like in VB6 but I don't recommend their usage.

I have developed code for a number of
repetitive things that all my apps use in vb6 (like report headers and
tails, gradient screens, traps for non-number input and some sound effects)
in my 'library' module (don't even know if that is the right name) which I
use in vb6, and I call them from my user forms. How exactly is this done in
vb.net? 2008 Express for dummies has a whole eloquent chapter about
reusability of code and never says a practical word of how to implement it.
I suppose my diatribe is dirceted at that book more than anything else.

I realy must stop for now and get back to work analysing the results of an
exam I set in completely different discipline. You'll all be relieved to
know that it has nothing whatsover to do with programming!

Thanks again Armin.

Ok, let's press the reset button and we try again, ok? Pick out one _small_ subject
that you want to know because I'd probably start at the wrong end again. Keep your
question short, I keep the answer short. If you don't understand it, please ask.
If you don't understand a detail of my answer, please ask again. If I were to make
a suggestion, I'd learn what a class is. (I assume that you know the real basics,
i.e. what variables, loops, if-then, procedures, etc are.) Namespaces come later.

 

[StrandElectric]

Ok, let's press the reset button and we try again, ok? Pick out one
_small_ subject
that you want to know because I'd probably start at the wrong end again.
Keep your
question short, I keep the answer short. If you don't understand it,
please ask.
If you don't understand a detail of my answer, please ask again. If I were
to make
a suggestion, I'd learn what a class is. (I assume that you know the real
basics,
i.e. what variables, loops, if-then, procedures, etc are.) Namespaces come
later.

Yes, I know those basics.

Try this for a start: What and where should the syntax be placed (there are
going to be whole host of forms accessing this) that will enable me to read
a legacy Random Access File called Bloggs. Assume it is made up of records
that are first an integer (1 byte long), second a name string that is 20
chars long. Third an address string that is 30 chars long. I want to read
record no. 6. Then I want to write to record 40 with (from the entry screen)
variable aa for the integer, bb for the first string and cc for the next.