UDTs (as was vb6)

[StrandElectric]

Yes, I know the reasons for keeping the scope as narrow as possible, but the
reason for 'Public' is that this code was to go in a module to be available
to about a dozen different forms. This is how it works in the vb6 app.

It does occur to me that my questions may be too basic -- indeed
irritating -- for this group. Is there another for real beginners or vb6
'converters' in waiting? BTW I have devoured 2008 express for dummies, and
this does not of course address either UDTs or printing!

 

[Cor]

Strand,

Do you also use still some of these, all your replies looks if you do that.

http://en.wikipedia.org/wiki/IBM_405

You get fine answers here and from all you tell that they did not have that
IBM 405 behaviour which VB6 had.

Did you know users want currently for instance true type fonts, but much
more which was not done with the 405.

Just my impression when I was going through this thread.

And the funniest thing is, you still can do what you want with .Net, but
there are fewer and fewer persons like Tom and Jason who can understand what
you mean with your IBM 405 style questions.

Cor

"StrandElectric" wrote in message
Yes, I know the reasons for keeping the scope as narrow as possible, but the
reason for 'Public' is that this code was to go in a module to be available
to about a dozen different forms. This is how it works in the vb6 app.

It does occur to me that my questions may be too basic -- indeed
irritating -- for this group. Is there another for real beginners or vb6
'converters' in waiting? BTW I have devoured 2008 express for dummies, and
this does not of course address either UDTs or printing!

 

[StrandElectric]

Hilarious Cor!

I'm not quite that old but will be 71 this year, so perhaps I learn more
slowly!

I started with Interpreter Basic in 1980 (all self taught) and moved on to
use QuickBasic. I had a struggle with VB6 when I changed up to that but have
a very respectable accounts suite up and running. I am now trying to adjust
my thinking to vb.net. Excat syntax and clear instructions is (are) what I
need. The replies so far have assumed knowledge...

 

[Tom Shelton]

It happens that StrandElectric formulated :

Yes, I know the reasons for keeping the scope as narrow as possible, but the
reason for 'Public' is that this code was to go in a module to be available
to about a dozen different forms. This is how it works in the vb6 app.

It does occur to me that my questions may be too basic -- indeed irritating
-- for this group. Is there another for real beginners or vb6 'converters' in
waiting? BTW I have devoured 2008 express for dummies, and this does not of
course address either UDTs or printing!

On UDT's, it's probably because they are almost never used in vb.net -
except for interop or legacy code

 

[StrandElectric]

It happens that StrandElectric formulated :

On UDT's, it's probably because they are almost never used in vb.net -
except for interop or legacy code

Thanks Tom

I think I've gathered that. But I have a very old random access file (that
in fact was originally in use in a full blown commercial application written
originally in QuickBasic. For historical (not hysterical!) reasons I want
to access that file. I am also much more comfortable working with random
access files in my accounting suite, and these were fine using UDTs in vb6.

A couple of my questions: Should the proposed UDT (format of which has been
provided, complete with compulsory continuation characters which seem to
have no logical reasons) go in a module, and does module mean the same as in
vb6, ie it is a unit of programming that is separate to a form? Then should
the name of the UDT be declared using the dim (or public) expression in the
module? Comments have been made that in my fragment of code I only show eg
30 bytes whereas the random records I am accessing have 255. I was just
trying to read the first 30 of them until I get the hang of it, rather than
coding a great big UDT with multiple types and substrings. Is that not
possible?

So far I have been able to open the file, read the length and close it, so I
have at least achieved something.

Some of the replies I've had seem to be repeating links found on Google.
I've already tried Google and found the replies there incomprehensible
because they assume a standard of vb.net knowledge. I need someone who has
*actually done* the things that I'm trying to do. For now, 1) use UDTs 2)
print formatted reports using variables (not printing forms).

As you can all see, I am far from the standard at which you are pitching
your kind replies, so I have an easier question which will alleviate your
frustration at this hopeless beginner. As I recently said, I have devoured
VB2008 for Dummies# without any success, also VB2008 Step by Step. Can
anyone suggest a really good book for *absolute* beginners, or for vb6
people of beginner standard. Or can anyone suggest a newsgroup for it?

Unless of course someone is willing to teach me one-to- one off group
(someone like Mike Williams of vb6 fame -- patient and not assuming
anything).

(#BTW It was my frustration at the Dummies products which led to my writing
a true beginners book for another technology in 1996 (published by Hodder)).

Thanks all.

 

[Armin Zingler]

Am 01.01.2011 12:23, schrieb StrandElectric:

Hilarious Cor!

I'm not quite that old but will be 71 this year, so perhaps I learn more
slowly!

I started with Interpreter Basic in 1980 (all self taught) and moved on to
use QuickBasic. I had a struggle with VB6 when I changed up to that but have
a very respectable accounts suite up and running. I am now trying to adjust
my thinking to vb.net. Excat syntax and clear instructions is (are) what I
need. The replies so far have assumed knowledge...

I was also a big fan of VB6 (BTW, my BASIC history is Locomotive Basic
(on Schneider/Amstrad CPC 464), gwbasic, qbasic, quick basic, vbdos,
vb 3-6, VB.Net). Though I'm convinced of the overall package that
I have when using VB.Net. It's not just because "it's newer" and "we have
to use newer stuff". There are drawbacks, I know. Printing is one of the
"most different" aspects. Congrats, you've found it! BTW, printing and
drawing code is the code that is not upgraded by the upgrade wizard.

I don't know _why_ printing (using the PrintDocument object and it's
PrintPage event) has been designed the way it is. I haven't read an official
statement or blog entry about it (and didn't search for it). But the
reason why painting on a Graphics objects is IMO the better approach, is because
it's the better encapsulation of the OS (drawing on a device context).
You can now write common code that paints on a Graphics object without
knowing if it's the printer, a Bitmap or the Screen. Can you use the _same_
methods to paint on a Bitmap as on the Printer in VB6? No, you can't.
Back to printing: As a Graphics object does and can not have a
"NewPage" method, the developers had to find another way to print pages,
each represented by a Graphics objects. Maybe that's the reason for the
current design of the PrintDocument object and it's PrintPage event.

So, a helpful attitude with VB.Net is: "How do I...?" instead of "How do I translate
it line by line?". And, like in (the rest of) real life, if you want translate
from one language to the other, you _first_ must learn _both_ of them.

One more words about attitude: As Cor and Tom knows, one of my favorite
topics is called "Option Strict On". Or call it early binding. It makes a lot
of sense. Why? Take a step back and look what you/we are doing: We are dealing
with data all day long. You know that we must handle it safely. Everything must
match exactly. We are designing plugs and sockets to make them fit.
Now, you belong to one of two groups of persons: In one group the world is
open for plugging every jack into every socket - they may match; but you
won't know before powring it on. If you did it wrong, it was your fault.
In the world of the other group, only matching jacks and sockets fit together.
It's sometimes a little more work because you have to create the matching
plug first. To which group do you belong? If you want it safe, then I say
welcome to the second group (labeled "Option Strict On")!

I mean, as we, nowadays, have all the tools to design our software in a way
that it fulfils the needs on one side and is also (type) safe on the other side,
it would be irresponsible to make it unsafer than necessary, wouldn't it? Again,
there are 1000 chances to fail each day. I don't want to take them anymore.
So, please give the compiler the chance to create a 100% bullet proof
application at compile time - there are sufficient other chances left to fail.

 

[StrandElectric]

Thanks for That Armin

At present I'm unconvinced by the print agument you've put. What could be
simpler than (vb6) printer.print BloggsVariable? (when you've calculated
perhaps the total of a number of variables?)

Re Option Strict on, are you saying that this should be placed at the very
top of every form?

 

[Armin Zingler]

Am 01.01.2011 19:34, schrieb StrandElectric:

Thanks Tom

Hi Mr. StrandElectric,
hi Tom, (I'm making a gaming break so I answer)

I think I've gathered that. But I have a very old random access file (that
in fact was originally in use in a full blown commercial application written
originally in QuickBasic. For historical (not hysterical!) reasons I want
to access that file. I am also much more comfortable working with random
access files in my accounting suite, and these were fine using UDTs in vb6.

If there are reasons to stick with VB6, it can be done.

A couple of my questions: Should the proposed UDT (format of which has been
provided, complete with compulsory continuation characters which seem to
have no logical reasons) go in a module, and does module mean the same as in
vb6, ie it is a unit of programming that is separate to a form?

Well, first you should have a look at the structure of a VB.Net project:
(not intended to be complete!)

First you have Namespaces. That's like directories on your hard disk.
Like I wouldn't want to put all files into the root directory of my HD, I group
classes into Namespaces to have a better (structured) overview, and to avoid
duplicate names that have different meanings in different contextes. By default,
everything is put into the Namespace as set in the project properties. It's like
the home directory of the project's classes etc. Figuratively spoken, they reside
in "C:\RootNamespace". You could even delete the project's root name space, so
everything is put into "C:\" (figuratively again) - but I wouldn't do this.

Within the Namespaces, you can put types (Classes, Structures, Enums) (figuratively
these are the files within the directories), or nested Namespaces for the same
reason why you create sub directories.

Within Classes/Structures you have fields and methods.

Classes can have shared members, i.e. they do not refer to an instance of the
class and they always exist. You access them by naming the class. (in opposite
to naming a variable pointing to an instance of the class in order to access
an instance member).


That's the basic structure. Now, within the code, if you want to refer to any
name declared within the project, you must know how name resolution works.
Names are always resolved inside out. That's not different to VB6. First,
local names, then at class level, and so on. But, as we have the possibility
to built a more complex structure, it can be bothersome to access a specific
name within the structure. For example, accessing System.Windows.Forms.Cursor.Current
is a lot to type. Every time. For this reason, "Imports" are available. Importing
a Namespace just means that, in addition to the normal resoultion path of the
compiler, the imported Namespaces are sought. It just saves typing. You can add
Imports per file or at project level. So you can write this:

Imports System.Windows.Forms

class c
sub bla
cursor.current = ....
end sub
end class

The name "cursor" is not found inside Sub bla, not inside class c, but inside the
namespace System.Windows.Forms. That's why and how it works.

You can also import a Class like you import a Namespace. What? Yes, it's in order
to access the shared members of the Class without typing the full qualified Class
name every time.



So, back to Modules: There are no Modules in the .Net type system. A Module in VB.Net
is just a class with all shared members, and the Class is imported at project level.
This simulates the behavior of Modules as in VB6. I don't use Modules because
it neutralizes the project structure. I mean, like files in C:\, they are simple to
access, but structure gets lost. And due to how name resolution works, you may accidently
pick out an item from that global pot instead of accessing a local variable that is
spelled similarily. Yes, it would be your fault, but creating less risks should
be an objective. So, keep the big black pot as small as possible.

Then should
the name of the UDT be declared using the dim (or public) expression in the
module?

I didn't follow every message in the thread, but the answer depends on where
you intend it to use. If outside the Module, you must declared it Friend
or Public. Otherwise Private is sufficient.

As you can all see, I am far from the standard at which you are pitching
your kind replies, so I have an easier question which will alleviate your
frustration at this hopeless beginner. As I recently said, I have devoured
VB2008 for Dummies# without any success, also VB2008 Step by Step. Can
anyone suggest a really good book for *absolute* beginners, or for vb6
people of beginner standard. Or can anyone suggest a newsgroup for it?

I can't make a suggestion but I hope I could make a little contribution with
regard to content.

 

[Armin Zingler]

Am 01.01.2011 20:45, schrieb StrandElectric:

Thanks for That Armin

At present I'm unconvinced by the print agument you've put. What could be
simpler than (vb6) printer.print BloggsVariable? (when you've calculated
perhaps the total of a number of variables?)

It was also so simple with my CPC 464: I could start typing one second after
powering it on. Nowadays, I have to wait one minute. Your conclusion is that
nowaday's machines are 60 times slower than those of '86? ;-)

No, you were right. At first sight. But programming is also about code
reusage. A higher level of abstraction helps. If I write a Sub that
draws on whatever, I pass a Graphics object and don't care about the target.
The code can be reused.

This point I didn't make clear enough: Dealing with data also means being aware
of data types. This is absolute basic knowledge for every programmer.
I think you know this. The compiler is there to resolve speaking names to memory
address. Those names are only there for us humans while writing the source
code. I expect the compiler to reject names that do not exist. Don't you, too?
It can check it because it has all the information available.

If it wouldn't reject invalid names, you get late binding. I don't want late binding
(with very few exceptions) because of three reasons: It is slow, it is unsafe, and it
is not required. As to the latter:

In (VB).Net, there are other means for building types and a type system,
e.g. by using inheritance or interfaces. In VB6, the Printer and a Form
did not have a common base class or a common interface. That's why it was
just necessary to go the unsafe way if you didn't want to write everything
twice. Not talking about Bitmaps. In VB.Net, you can just write

g = Graphics.FromImage(myBitmap)

retrieving a Graphics objects, pass it to a method expecting a Graphics
object, and draw on the bitmap just like the same method draws on the
printer or the screen. And again, a Graphics object is just an encapsulation
of an OS device context. That's why there is no need to distinguish between
different devices related to drawing on them. I consider this a step forward.

I do understand that you'd like to have a Printer object like in VB6. I didn't
need it personally, but I can imagine that it can be helpful. I'd say they just
haven't added it (I don't know what the VB PowerPacks contain). But if they did,
it would be based upon the facts above. This means, you are still free to simulate
the VB6 behavior in your own Printer class. But I guess there is already something
out there in the world wide web.


So, having a common type system that allows us to do everything _safely_, why
would you want to directly draw on a Form, Bitmap, Printer using their individual
drawing methods instead of making use of one more abstraction layer (the Graphics
object) that enables us to handle them equally?

Re Option Strict on, are you saying that this should be placed at the very
top of every form?

Menu Tools -> Options -> Projects and solutions -> VB default: Option Strict On

That's the default for new projects you will create in future. For existing
ones, you can set it in the project's properties on the compile tab. Or, as you
wrote, in every file. And, in advance, don't get scared: as you know that a Single
variable has a different memory format from an Integer variabl, you won't be able
to assign the former to the latter anymore. Yes, you must start thinking about what you
are doing with your data. No implicit (narrowing) conversions anymore without
thinking about decimal places, value ranges, and rounding rules.
This is just an example of what awaits you if you switch Option Strict On.
Generally speaking, the plugs and sockets must always match. That's good
for a working machine. It doesn't mean the machine will work flawlessly,
but if it's excluded to connect things inappropriately, there is a much
higher chance.

 

[StrandElectric]

Am 01.01.2011 19:34, schrieb StrandElectric:

Hi Mr. StrandElectric,
hi Tom, (I'm making a gaming break so I answer)


If there are reasons to stick with VB6, it can be done.



Well, first you should have a look at the structure of a VB.Net project:
(not intended to be complete!)

First you have Namespaces. That's like directories on your hard disk.
Like I wouldn't want to put all files into the root directory of my HD, I
group
classes into Namespaces to have a better (structured) overview, and to
avoid
duplicate names that have different meanings in different contextes. By
default,
everything is put into the Namespace as set in the project properties.
It's like
the home directory of the project's classes etc. Figuratively spoken, they
reside
in "C:\RootNamespace". You could even delete the project's root name
space, so
everything is put into "C:\" (figuratively again) - but I wouldn't do
this.

Within the Namespaces, you can put types (Classes, Structures, Enums)
(figuratively
these are the files within the directories), or nested Namespaces for the
same
reason why you create sub directories.

Within Classes/Structures you have fields and methods.

Classes can have shared members, i.e. they do not refer to an instance of
the
class and they always exist. You access them by naming the class. (in
opposite
to naming a variable pointing to an instance of the class in order to
access
an instance member).


That's the basic structure. Now, within the code, if you want to refer to
any
name declared within the project, you must know how name resolution works.
Names are always resolved inside out. That's not different to VB6. First,
local names, then at class level, and so on. But, as we have the
possibility
to built a more complex structure, it can be bothersome to access a
specific
name within the structure. For example, accessing
System.Windows.Forms.Cursor.Current
is a lot to type. Every time. For this reason, "Imports" are available.
Importing
a Namespace just means that, in addition to the normal resoultion path of
the
compiler, the imported Namespaces are sought. It just saves typing. You
can add
Imports per file or at project level. So you can write this:

Imports System.Windows.Forms

class c
sub bla
cursor.current = ....
end sub
end class

The name "cursor" is not found inside Sub bla, not inside class c, but
inside the
namespace System.Windows.Forms. That's why and how it works.

You can also import a Class like you import a Namespace. What? Yes, it's
in order
to access the shared members of the Class without typing the full
qualified Class
name every time.



So, back to Modules: There are no Modules in the .Net type system. A
Module in VB.Net
is just a class with all shared members, and the Class is imported at
project level.
This simulates the behavior of Modules as in VB6. I don't use Modules
because
it neutralizes the project structure. I mean, like files in C:\, they are
simple to
access, but structure gets lost. And due to how name resolution works, you
may accidently
pick out an item from that global pot instead of accessing a local
variable that is
spelled similarily. Yes, it would be your fault, but creating less risks
should
be an objective. So, keep the big black pot as small as possible.



I didn't follow every message in the thread, but the answer depends on
where
you intend it to use. If outside the Module, you must declared it Friend
or Public. Otherwise Private is sufficient.




I can't make a suggestion but I hope I could make a little contribution
with
regard to content.

Thanks Armin for your obviously sincere and reasoned reply. But
unfortunately, most of it is too abstract and therefore above my head. When
I said I was a real beginner I meant it. I suppose my next step migh be to
write a little program in vb6 that includes the UDT as well as the print
issue, and then invite specific comments?

 

[Armin Zingler]

Am 02.01.2011 04:52, schrieb StrandElectric:

Thanks Armin for your obviously sincere and reasoned reply. But
unfortunately, most of it is too abstract and therefore above my head. When
I said I was a real beginner I meant it.

Understanding the project structure is one good beginning.
The key point was only about putting classes into Namespaces, to
say it in short. As you were already programming in VB6 and before,
I thought that's the first bigger change to VB6, and I explained it
because you were unsure about Imports.

I suppose my next step migh be to
write a little program in vb6 that includes the UDT as well as the print
issue, and then invite specific comments?

If you want to get into VB.Net anyway, or if you want to upgrade code,
learn VB.Net. If you don't want or need to, and if you feel more comfortable
in VB6 and just want to write the code that does what you need, then you
may use VB6 only. So, you must decide.

Anyway, you're welcome to the group with the left over lone fighters
that keep this dead group alive.

 

[StrandElectric]

Am 02.01.2011 04:52, schrieb StrandElectric:

Understanding the project structure is one good beginning.
The key point was only about putting classes into Namespaces, to
say it in short.

That sentence is way above my head!

As you were already programming in VB6 and before,

I thought that's the first bigger change to VB6, and I explained it
because you were unsure about Imports.


If you want to get into VB.Net anyway, or if you want to upgrade code,
learn VB.Net. If you don't want or need to, and if you feel more
comfortable
in VB6 and just want to write the code that does what you need, then you
may use VB6 only. So, you must decide.

Well, I'm very happy with vb6, and I am looking at vb.net for two reasons.
1) In case my vb6 projects will not work with future Windows versions and 2)
as a challenege. 1 is more important by a long way.

Anyway, you're welcome to the group with the left over lone fighters
that keep this dead group alive.

But there may be millions of puzzled beginners. Where do they all go.? Or do
they all give up vb.net...It seems to be a long way from the natural
progressionof the basic language as many of us have known it. I thought vb6
was absolutely brilliant. Why did Microsoft pull the plug on it? vb.net
seems so obscure from a user point of view. Almost as though a team
deliberately and peversely made the concepts as indirect as possible.

 

[Armin Zingler]

Am 02.01.2011 18:14, schrieb StrandElectric:

That sentence is way above my head!

But you do understand why files are put into directories and sub directories?

Well, I'm very happy with vb6, and I am looking at vb.net for two reasons.
1) In case my vb6 projects will not work with future Windows versions and 2)
as a challenege. 1 is more important by a long way.

If you will learn it, you should learn the new concepts without comparing.
Then you might understand why things have been done this way. There is always
something improvable, and I also disagree with some solutions. Sometimes you will
stumble upon things that look more difficult than in the past, but the first sight
should not make the decision. As I already said in my other post, nowadays computers
are not all worse than the old ones because you can't use them after 1 second.


I also noticed that learning programming became more complex than it was in
the good ol days because there are more concepts to learn first. But we can't
forswear new concepts because they are helpful. I'm teaching programming
now and then, and I attach great importance to confronting the learner only
with tasks that are completely solvable wit the subject matter learned so
far. If one is _really_ aware of this, "Hello world!" is not the first
application.

But there may be millions of puzzled beginners. Where do they all go.? Or do
they all give up vb.net...

"Dead" was only related to this group. Microsoft shut down their public news servers
and we were to move to their community where we must register and agree to
their terms: http://www.microsoft.com/communities/forums/default.mspx
That doesn't match the spirit that I support and the spirit of newsgroups.
Luckily, several other news servers still have the microsoft.public groups,
but most people aren't here anymore. So, VB.Net is not dead, just MSFT's
newsgroup support.

Beginners can ask where every other VB.Net programmer asks.

It seems to be a long way from the natural
progressionof the basic language as many of us have known it. I thought vb6
was absolutely brilliant.

I felt limited with it. Today I'm (partially) throwing my hands up in horror when
I look back at it.

Why did Microsoft pull the plug on it?

They didn't. VB6 was an isolated solution. Keeping all old things would have been a
millstone around MSFT's neck. Luckily, they made a complete redesign based upon the
..Net Framework while keeping the language characteristics. The _alternative_ would have
been letting it die. Everyone has a different opinion about how drastic this cut was
or should have been. Therefore, pleasing everybody was impossible for MSFT. Anyway,
for me it's pointless discussing about it in 2011.

vb.net seems so obscure from a user point of view.

I wouldn't judge before knowing it. Moreover, the .Net Framework sets the specifications.
What is wrong with the Framework? Do you have a problem with the type system, memory management
or the class library and it's namespace structure? I think you don't know it good enough to
criticize it.

Almost as though a team
deliberately and peversely made the concepts as indirect as possible.

This sentence is above my head.

 

[Cor]

I've actually worked with the IBM business machines, although not with the
405. But I could not get a description on Wikepedia for the newer ones but
they did not change much I saw in 25 years and the plug in boards you see on
the picture I've used endless times.

However, there were changes in the about 30 years when I started using those
after 1938. And suddenly around 1980 the microprocessor became from a part
of a central heating system, the main part for desktop computers (first like
toy ware and then as business tool, while it is now even in cell phones to
use those as computers). For most persons, who like me were busy on
mainframes, that stayed of course toys.

Programming had to change for that, we could not use anymore the way of
thinking, I did not take that tabulating machine for nothing as sample to
you. We kept in business using that non true type font or like Tom wrote a
non graphical way of printing. Why do it difficult as it could be so easy
done like it had always been with the printing wheels of a tabulating
machine.

In our business are always persons, who think, what those oldies did we can
do better. And they are right, I've the bad habit that I compete with those
youngers and behave in this subject the same.

Somehow you are in my idea the same, I really go along in the changes, I
don't buy anymore a book, I watch on Internet and in past for this kind of
information mainly newsgroups (currently forums), where guys like Tom, Jason
and Armin showing to write from knowledge.

Do you think why newsgroups and forums, that is because if Armin or Tom
writes something foolish, they know that I try to correct them in a friendly
way and so I expect they do to me.

Be aware that on Internet is as much grab as there are currently grab books.
I sometimes have the idea to write a book myself, but the turnaround time to
the newer versions is currently less than a year and makes writing books
almost impossible.

(Hey!!!! Tom and Armin, did you know that the byval has become default in
version 2010 SP1 beta?)

So either you try to take a next step in thinking or become old. I'm not
direct like Armin(the first time I saw his replies I thought he was a kind
of East German Policeman (I've been often in the DDR)) or Tom (who goes to
the ultimate bit in my idea in investigating how things are going).

I had in past big discussions with Armin about Option Strict On, because I
found it something the computer had to do. After that I (based on my
discussions with Armin) understood more about Option Strict, I have endless
times written on more places, that the compiler should find from the code we
write the correct type like at spell checking (because for instance the
representation of the string is never an integer). Now we have Option Infer
which makes Option Strict Off in fact not so much needed anymore. Option
Infer is standard default On. It looks to the signature of the data you use
in a declaration and defines than fixed the type of the data at design time
(the name of that is strongly typing). In C# it is named Asynchronous type
but in fact it is the type which is inferred in VB at Dim. C# has in version
2010 by the way also the Option Strict way. To say it in VB6 words, option
strict off can results in a kind of variant type which gives errors for
instance if that is seen as a string while you are calculating (in C# 2010
the keyword is for the VB6 variant "dynamic" the interfered dim is named in
C# the Var), the VB6 Variant does not exist anymore in VB for Net. To be
before Armin, Infer does not work on global level only inside a method,
while option strict off does.

I think I write to much so I stop.

Cor




"StrandElectric" wrote in message

Thanks Armin for your obviously sincere and reasoned reply. But
unfortunately, most of it is too abstract and therefore above my head. When
I said I was a real beginner I meant it. I suppose my next step migh be to
write a little program in vb6 that includes the UDT as well as the print
issue, and then invite specific comments?

 

[StrandElectric]

(Hey!!!! Tom and Armin, did you know that the byval has become default in
version 2010 SP1 beta?)

That's what worries me! Are Micro$oft determined to force incessant
obsolescence!

 

[Jason Keats]

That's what worries me! Are Micro$oft determined to force incessant
obsolescence!

I don't know why Cor mentioned the above. The default has always been
ByVal in .NET. It was ByRef in VB6.

 

[Cor]

You don't have to write it anymore and it is not anymore added by the
designer

Cor

"Jason Keats" wrote in message

That's what worries me! Are Micro$oft determined to force incessant
obsolescence!

I don't know why Cor mentioned the above. The default has always been
ByVal in .NET. It was ByRef in VB6.

 

[Armin Zingler]

Am 04.01.2011 09:33, schrieb Cor:

I'm not
direct like Armin(the first time I saw his replies I thought he was a kind
of East German Policeman (I've been often in the DDR))

Maybe because I sometimes find the right words in the dictionary, but putting
them together gives sometimes a different meaning or a different impression than it
was actually meant. (I _still_ don't understand why "please turn to group XY"
is considered impolite... I said "please" ^^ I'll never forget this.).
I know I sometimes articulate intricately, but as I'm also not a native English
speaker, you know, and I have never lived in an English speaking country, I'm
trying hard.

Now we have Option Infer
which makes Option Strict Off in fact not so much needed anymore. Option
Infer is standard default On. It looks to the signature of the data you use
in a declaration and defines than fixed the type of the data at design time
(the name of that is strongly typing). In C# it is named Asynchronous type
but in fact it is the type which is inferred in VB at Dim. C# has in version
2010 by the way also the Option Strict way. To say it in VB6 words, option
strict off can results in a kind of variant type which gives errors for
instance if that is seen as a string while you are calculating (in C# 2010
the keyword is for the VB6 variant "dynamic" the interfered dim is named in
C# the Var), the VB6 Variant does not exist anymore in VB for Net. To be
before Armin, Infer does not work on global level only inside a method,
while option strict off does.

Well, (you knew I will answer this, huh?) it's less the variable type, it's more
that accessing none-existing members must not work (as I said with few exceptions
like Office Automation).

I think I write to much so I stop.

Hey, it's ok, we must produce some traffic here! Saying this, I keep on doing so...:

(I'm mainly talking to Mr. StrandElectric here, trying to do convincing.)

Let's start with classes, the main building brick. Anyone says that they should
be cancelled? In don't think so. It was always a programmer's need to put associated
data together (also like UDTs), so why not call them "classes"!? Then came
OOP and we've put the code also into the class. It makes sense for known reasons.

Then we have Structures/UDTs. Almost the same, just a different memory management
and what we can do with them, so usable in other situations. I rarely write
them because I know from experience that I _will_ want to set a reference to the
object later (other than ByRef).

Do we still agree with these basics?

Overview gets lost the more classes we have. To avoid this, we (at least I) always
feel the need to arrange things. Voilá, we have namespaces. Thanks for them. That's
all necessary to say about them. Just open the object browser, look at the Framework
classes grouped by namespace, and you'll see it. At the latest if you start counting
the classes, you will understand why namespaces make a lot of sense.

That's the whole structure of the "type system" explained. Uhm, almost, but everything
further doesn't change the "big picture". Done.

Sure, there are more things, like "inheritance" and "interfaces". Right, we could do at
least without one of them, but they came from the practical programming requirements
saying "this is like that" or "this must match that". It's a programming pattern or way
of thinking that programmers came across very frequently. So, wouldn't it be nice if the
language would support this? Don't worry, I won't elaborate on the two terms in detail.
That's been done a million times. If you don't understand their usefulness, just leave it.
Really, then I'm running out of arguments. Your problem then.

So, this chapter one was about the concept. VB is a multi-purpose language that implements
this concept. No Printer object here, right? Absolutely, this is the reason: VB is a
multi-purpose language - I must repeat this - and therefore it does not have a built-in
Printer object. Where should it be? There is not place for it "in the language". The
language has keywords and a syntax and whatever. It is a tool for using existing code and
creating new code.


Chapter II is the .Net Framework class library. The class library is the "existing code"
part from the last sentence in the previous paragraph. _That_ is the place where a
Printer object/class _could_ be located. The class library is a huge collection of classes
etc that we can make use of. Don't forget that VB6 had to use references (even to
VB/VBRUN/VBA) to be able to do basic things, too.

There are some namespaces in the Framework class library that start with "Microsoft.VisualBasic".
But this does not mean, they can only be used from VB.Net. As they meet the same standard
as all other libs, they could be used from any other language, too. If you look at them,
you'll notice that most things are dispensable. Why? a) Because some parts are only for
people that are unable to find the straight way in the rest of the Framework, or for
nostalgic reasons. BTW, I'm still using "Msgbox" instaed of "Messagebox.Show" because I'm
used to it and I don't care, but that's probably the only old-style function I use from
there. b) Other parts are newer and support something that I call My.Crap. Not elaborating
on this, too.



Conclusion: the whole thing about learning VB.Net is understanding the two main parts:
The _common_ type system (common to multiple un-isolated langauges) on one hand, and getting
into the .Net Framework class library on the other hand.


Maybe you can make a suggestion at https://connect.microsoft.com/VisualStudio/Feedback
and ask them to implement the VB6-style printer object in the next version of the Framework.
By then, you must be satisfied with what is currently offered, namely the PrintDocument class.


The common language specification has been built from scratch (of course with many
influences and experiences from wherever) to come up with the requirements of nowadays
programming. VB.Net is one implementation of that standard with many language characteristics
(keywords) well-known from previous versions. If you don't understand the new concept, you
won't get along with VB.Net very well.

 

[Mayayana]

| >
| > Understanding the project structure is one good beginning.
| > The key point was only about putting classes into Namespaces, to
| > say it in short.
|
| That sentence is way above my head!
|

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

The US tax code is usually easier to figure out.
But all they're really talking about is defining
contexts, as object declarations in VB/COM define
contexts. COM is full of such things. Each COM
object has a server and class: Word.Application.
Shell32.Folder. Using the Shell32 server name
avoids conflicts with other instances of "Folder"
classes from other servers. It defines a context of
the class that Folder is a property of. (As opposed
to, say, the FileSystemObject.Folder.)

In fact, if you look up namespace at wikipedia
it sounds very similar to the definition of a COM
server. But I suppose that's really only half of it,
which is what makes it confusing. A COM server
is an actual library file. One needs to know about
the design of COM DLLs and they're objects/classes
in order to make sense of why there are servers
and classes and server.class declarations. I guess
one could say that a server is a namespace, but that
doesn't really say anything.
I don't know what *really* constitutes a .Net
namespace, or an XML namespace, for that matter.
That would be the *relevant* definition you're looking
for.

I hope that's helpful. Ironically, I always found
the ...dummies books helpful with that sort of
thing. They answer the questions that the experts
don't answer -- because the experts have got so
comfortable with the topic that they simply forget
that everyone doesn't know the basics and the
jargon. (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".)

 

[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