Upgrading to VB.Net

  • Thread starter Thread starter Robert
  • Start date Start date
Goran,

Please don't tell in a newsgroup what I wrote, which you wrote in fact
yourself.

The way you do it by removing words in sentences other people wrote, you can
make from every sentence the oposite by instance by simply removing a word
as "not"

You was the one who wrote this the first time, as this is the idea from what
I told, then it comes from you. I tried explicitly not to write it in the
way you did, that you did not see that is not my fault.

Armin understood me, it is not something that comes from the way I wrote it.
Armin does natively not speak the same language as I. (I don't know what
your native language is, but I have the idea that it's like English in the
Germanic language space, like Armins and my native language)

Cor
 
Cor said:
Goran,

Please don't tell in a newsgroup what I wrote, which you wrote in fact
yourself.

The way you do it by removing words in sentences other people wrote, you
can make from every sentence the oposite by instance by simply removing
a word as "not"

You was the one who wrote this the first time, as this is the idea from
what I told, then it comes from you. I tried explicitly not to write it
in the way you did, that you did not see that is not my fault.

Armin understood me, it is not something that comes from the way I wrote
it. Armin does natively not speak the same language as I. (I don't know
what your native language is, but I have the idea that it's like English
in the Germanic language space, like Armins and my native language)

Cor
Click to expand...

I haven't removed any words in any sentences. I do not appreciate that
you are telling lies about me like that. Any quotes that I do are exact.
Let me quote you exactly:

"The Integer is a pseudo code for an Int16 on 16bit based processors
software (vb6) and Int32 on 32bit processor based computers."

Here you are saying that the Integer type is 16 bits on a 16 bit based
processor and 32 bits on a 32 bit processor. That clearly implies that
there is a connection between the Integer size and the processor
architecture. That is not true.

You are also saying that VB6 produces 16 bit software. That is not true.

Perhaps you didn't mean it that way, but that is what you wrote, and
that is what I objected to.
 
Goran,

Here you do it again, you write what you think, not what I wrote.

You show a piece of what I wrote and then you write (as example).

"You are also saying that VB6 produces 16 bit software".

I did not say it and I never will write that, you said it.

As this implies for you, that I write that you write lies, then it is again
your interpretation, I did not write that anywhere.

I think that you try to find more behind what I write then like it is and
therefore come with this kind not correct statements.

Armin has more then once completely correctly replied what he thought what I
was meaning in this thread.
There was for me not any reason to add something to that until he wrote that
I could do it better myself..

Cor
 
Yes, it does:
http://support.microsoft.com/kb/250673

Note that this applies to VB5 & VB6 according to the documentation, and
clearly states that GetSetting/SaveSetting write to
"HKEY_CURRENT_USER\Software\VB and VBA Program Settings".

MS never removed the restriction prior to .NET.
Click to expand...

It's not a restriction. It's a small convenience that MS
added to VB so that people wouldn't have to learn how
to access the Registry using the Win32 API. Normally VB
would use API calls, just as any other software except
..Net does. Robert's original post is concerned with problems
translating his API constant declarations to .Net.

As with .Net, Microsoft was aiming VB at a wide audience,
trying to provide a tool that people could use without
needing to understand or use the Win32 API. For those
people, GetSetting and SaveSetting provides a very simple
way to save program settings.

There may be things VB.Net can do that VB can't, but if
you think VB is really more limited then you've been misled by
marketing hype. Basic Windows software, written in VB, C++,
Delphi, etc. -- by Microsoft or by 3rd-party programmers --
is typically using the Win32 API. That's how Windows works,
after all. Some software may also use ActiveX controls. And
ActiveX, like .Net, is mainly just a set of wrappers around that
same Win32 API. So it all comes back to the Win32 API. To
criticize GetSetting/SaveSetting is saying "My wrapper/
training wheels is better than yours". That's probably true,
but they're still both just wrappers. And the wrappers in
..Net are so extensive that a comparison to VB is probably
not very relevant. .Net is not designed for Windows software.
If you want to compare pros and cons it might make more
sense to make your comparisons with Java than with a native-
compiling language used for writing Windows software.
 
Cor Ligthert said:
Goran,

Here you do it again, you write what you think, not what I wrote.
Click to expand...

Yes, he wrote what he thinks what you wrote meant. There's no problem
with that, it clarifies communication.
You show a piece of what I wrote and then you write (as example).

"You are also saying that VB6 produces 16 bit software".
Click to expand...

And he's right.

If you say "That couple just had a baby" then you're saying that they
are 2 of them, that they are male and female, that by default one
should assume they had sex and that some months later the female
delivered a child.

If what you really mean is that they are a couple of old men that just
ate a baby goat for dinner, well you need to use other words.

The correct response to what he did isn't to call him a liar or say
he's manipulating what you say to mean something else. Since you
didn't mean that, the correct response would have been to say thank you
for pointing out the implication of the sentence and then state that
isn't what you meant to imply.
 
This has nothing to do with Robert's post, this was Michael Cole implying
that the GetSetting/SaveSetting features in VB6 were not restricted to the
same base registry location that prior versions of VB were, and I was
pointing out that he was incorrect.

And convenience or not, most VB coders serious about writing reg settings
ended up using the Win32 API calls anyway.
 
Really, I never knew that.

Cor

Alex Clark said:
This has nothing to do with Robert's post, this was Michael Cole implying
that the GetSetting/SaveSetting features in VB6 were not restricted to the
same base registry location that prior versions of VB were, and I was
pointing out that he was incorrect.

And convenience or not, most VB coders serious about writing reg settings
ended up using the Win32 API calls anyway.
Click to expand...
 
Göran Andersson said:
No, it never was a native integer.
Click to expand...

Both of you are right.

In the 16-bit age VB's 'Integer' type matched the bit width of the "native
integer" type. However, this changed when the 32-bit age began and the
'Integer' type remained a 16-bit-type.
 
Göran Andersson said:
You use a class:

Class SecurityAttributes

Public Length As Integer
Public SecurityDescriptfor As Integer
Public InheritHandle As Boolean

End Class
Click to expand...

The class above is not a direct equivalent to Win32's 'SECURITY_ATTRIBUTES'
structure. You may want to use the structure definition below:

\\\
<StructLayout(LayoutKind.Sequential)> _
Public Structure SECURITY_ATTRIBUTES
Public nLength As Int32
Public lpSecurityDescriptor As IntPtr
Public bInheritHandle As Boolean
End Structure
///
 
Cor Ligthert said:
(with Net software)

Keeping the integer size the same as the register size was to get the
maximum performance in a program without that you had to rewrite your
program completely. Now it means to get the maximum performance on a 64bit
computer you have in fact to rewrite your program.

The argument to not make the integer the same as the register size as in
64bits environment was, that because the computers are today fast enough.
However the perfomance from a punchcard computer to a diskcomputer has
been much more and in those days this argument would been seen as complete
amaturisme.
Click to expand...

I would not overestimate the importance of performance. 16-bit integers had
a really small range of values, which was often not sufficient for everyday
operations. Even 16-bit Windows was very limited because of the small
domain of the 16-bit integer type.

That's not the case with 'Int32' any more. The maximum value of
2,147,483,648 is big enough for most everyday scenarios, even today.

Changing the width of integral types based on the target platform may lead
to problems if the type's numeric and arithmetic semantics are relevant.
It's not such big problem if the numbers are only used as distinct
identifiers (such as handles, ...).
 
Herfried,

Have once a look how registers are working.

When I was young that was the most important thing that we have learned
then, although it was about 8bit

Cor
 
Cor said:
Herfried,

Have once a look how registers are working.

When I was young that was the most important thing that we have learned
then, although it was about 8bit

Cor
Click to expand...

Come back when you have actually tested the speed of using 32-bit
integers v.s. 64-bit integers in a 64-bit application...
 
Goran,.
Come back when you have actually tested the speed of using 32-bit integers
v.s. 64-bit integers in a 64-bit application...
Click to expand...
What do you want to say with this message, it has the same meaning as from
people who told that a horse would always be faster then a steam engine,
simple because there were no sufficients road yet.

Cor
 
Cor said:
Goran,.

What do you want to say with this message,
Click to expand...

That you should test the speed of using 32-bit integers v.s. 64-bit
integers in a 64-bit application before saying that you get the maximum
performance by always using an integer that is the same size as the
registers.
it has the same meaning as
from people who told that a horse would always be faster then a steam
engine, simple because there were no sufficients road yet.
Click to expand...

And what do you want to say with that?
 
Back
Top