Pointers

  • Thread starter Thread starter HardySpicer
  • Start date Start date
H

HardySpicer

Any way of converting this to vb.net?

// Calculate white pixels
private int CalculateWhitePixels( Bitmap image )
{
int count = 0;

// lock difference image
BitmapData data = image.LockBits( new Rectangle( 0, 0, width,
height ),
ImageLockMode.ReadOnly, PixelFormat.Format8bppIndexed );

int offset = data.Stride - width;

unsafe
{
byte * ptr = (byte *) data.Scan0.ToPointer( );

for ( int y = 0; y < height; y++ )
{
for ( int x = 0; x < width; x++, ptr++ )
{
count += ( (*ptr) >> 7 );
}
ptr += offset;
}
}
// unlock image
image.UnlockBits( data );

return count;
}
}
 
Am 30.09.2010 04:29, schrieb Michael Cole:
Armin Zingler wrote on 30/09/2010 :

Where does Microsoft want to allow you to go today?
Click to expand...

They allow you to use a C# assembly from a VB.net application. Safely.
 
| >> No, because it is
| >>> unsafe
| >
| > Where does Microsoft want to allow you to go today?
|
| They allow you to use a C# assembly from a VB.net application. Safely.
|

So VB.Net can't even access a pointer? I didn't
realize that. It's strange that MS bills .Net as
a "common" runtime for an unlimited number
of languages, yet those languages can't all function
equally. (Presumably that's mainly a device to get
the C++ snobs to use C#?)

It's also a rather interesting system of propaganda
that you've adopted as your own opinion. Not
sandboxed has been redefined with a value judgement:
unsafe. So if I download a VB.Net program that changes
Registry settings related to Internet security, that's
safe. But if I use a C#.Net image viewer it's "unsafe".
Egads! Come to think of it....Windows is not "safe".

Not that I really disagree with sandboxing... in
security-risky situations where that's appropriate. But
Microsoft is sandboxing at the same time that they're
encouraging people to write Desktop software in .Net.
It doesn't add up.

Last week I had someone write to me
because he was translating my VB code for reading type
libraries to VB.Net. ...Type libraries...pointers...Win32 API
..... there seem to be an awfully lot of people trying to
squeeze full Windows programming ability into .Net,
unaware of what sort of Java clone they've accidentally
stepped into ...so to speak. :)
 
Am 30.09.2010 15:29, schrieb Mayayana:
| >> No, because it is
| >>> unsafe
| >
| > Where does Microsoft want to allow you to go today?
|
| They allow you to use a C# assembly from a VB.net application. Safely.
|

So VB.Net can't even access a pointer? I didn't
realize that. It's strange that MS bills .Net as
a "common" runtime for an unlimited number
of languages, yet those languages can't all function
equally. (Presumably that's mainly a device to get
the C++ snobs to use C#?)

It's also a rather interesting system of propaganda
that you've adopted as your own opinion. Not
sandboxed has been redefined with a value judgement:
unsafe. So if I download a VB.Net program that changes
Registry settings related to Internet security, that's
safe. But if I use a C#.Net image viewer it's "unsafe".
Egads! Come to think of it....Windows is not "safe".

Not that I really disagree with sandboxing... in
security-risky situations where that's appropriate. But
Microsoft is sandboxing at the same time that they're
encouraging people to write Desktop software in .Net.
It doesn't add up.

Last week I had someone write to me
because he was translating my VB code for reading type
libraries to VB.Net. ...Type libraries...pointers...Win32 API
.... there seem to be an awfully lot of people trying to
squeeze full Windows programming ability into .Net,
unaware of what sort of Java clone they've accidentally
stepped into ...so to speak. :)
Click to expand...


Don't know what you are mixing. As to the pointers: In
99.99999% of my code lines I didn't need pointers. But I
can only speak for the past 24 years. I don't care about
propaganda. I use VB.Net because it's the language I like
most, and I add "pointer functionality" by adding a C++
project if I really need it. I don't have a problem with
that, and I'm happy with the managed (safe) .Net environment
even though there's always space for improvements.
 
Mayayana explained :
So VB.Net can't even access a pointer?
Click to expand...

You have as much pointer access in VB.NET as you did in VB6 - more
even. Event C#'s explicit pointers have limitations, when compared to
C++ or C style pointers.
I didn't
realize that. It's strange that MS bills .Net as
a "common" runtime for an unlimited number
of languages, yet those languages can't all function
equally. (Presumably that's mainly a device to get
the C++ snobs to use C#?)
Click to expand...

Running on the runtime does not mean that. Explicit pointers have
never been part of VB - why would you think they would now. The
runtime supports multiple languages - by providing a broad set of
features... Not every language has to take advantage of them how ever
:)
It's also a rather interesting system of propaganda
that you've adopted as your own opinion. Not
sandboxed has been redefined with a value judgement:
unsafe. So if I download a VB.Net program that changes
Registry settings related to Internet security, that's
safe. But if I use a C#.Net image viewer it's "unsafe".
Egads! Come to think of it....Windows is not "safe".
Click to expand...

I've always thought tat was a bad choice of working actually :) What
it's really saying is that the code is not verifiable as being safe by
the runtime...
Not that I really disagree with sandboxing... in
security-risky situations where that's appropriate. But
Microsoft is sandboxing at the same time that they're
encouraging people to write Desktop software in .Net.
It doesn't add up.
Click to expand...

In what way... In my mind, it's your lack of understanding of .NET.
I'm not trying to be insulting with that comment, but, I believe it to
be true.
Last week I had someone write to me
because he was translating my VB code for reading type
libraries to VB.Net. ...Type libraries...
Click to expand...

It's actually fairly trivial - all of the interfaces and types are
already part of the runtime. The hardes part of it is knowing how to
use them:

System.Runtime.InteropServices.ComTypes (ITypeLib, ITypeLib2,
ITypeInfo, etc, etc).

pointers...
Click to expand...

Again, superior access compared to what VB6 has - through use of the
System.Runtime.InteropServices.Marshal class. Besides, I can do native
cdecl calls - no third party class needed.
Win32 API
Click to expand...

And? VB.NET is better then straight vb6 at making api calls:

Unicode apis natively supported - no need for typelibs or strptr hacks.
Unions - natively supported for interop, no need to do byte array hacks
Cdecl - natively supported.

In fact, VB.NET is actually better at com then vb6 in some ways...
.... there seem to be an awfully lot of people trying to
squeeze full Windows programming ability into .Net,
unaware of what sort of Java clone they've accidentally
stepped into ...so to speak. :)
Click to expand...

LOL... You know that little exercise I helped you with - trivial in
VB.NET.
 
| LOL... You know that little exercise I helped you with - trivial in
| VB.NET.
|

:) Well I guess you shoulds explain that to
HardySpicer, then. To hear Armin Zingler tell
it, VB.Net can't do anything outside the
framework. Your two posts are saying opposite
things.
 
:) Well I guess you shoulds explain that to
HardySpicer, then. To hear Armin Zingler tell
it, VB.Net can't do anything outside the
framework. Your two posts are saying opposite
things.
Click to expand...

No there not... VB.NET - just like VB6 - does not have direct memory
access. C# does - though, in a more limited way then C/C++.

I could convert that code, but the fact is I don't know enough about
image processing and image formats :)

The major difference is that you would have to use System.IntPtr and
the Marshal class to copy the data from the memory location to an array
and then look at the bits in the array. It would end up being slower,
then the C# code - but, still doable.
 
?You could've heard that, but you did not listen well.

Armin did nowhere write that, while he has even explained that so named
unsafe code for virtual memory manipulation is not in managed VB.

The Unsafe code part is showed during the life time of managed code
languages by persons who think that C# is better than VB and use that than
as argumentation.

Almost nobody from VB really wants this legacy part from C#


"Mayayana" wrote in message
| LOL... You know that little exercise I helped you with - trivial in
| VB.NET.
|

:) Well I guess you shoulds explain that to
HardySpicer, then. To hear Armin Zingler tell
it, VB.Net can't do anything outside the
framework. Your two posts are saying opposite
things.
 
| Almost nobody from VB really wants this legacy part from C#
|

That's your opinion and should be stated as
such. Armin was also pretending that his opinion
was fact. The OP was asking for facts and was
being deliberately misled. Armin also answered
me in an evasive, misleading way. If someone
just answered the question I wouldn't have
stepped in, but I hate to see people waste time
and get confused due to wrong, stingey and/or
arrogant answers.
 
Am 01.10.2010 15:38, schrieb Mayayana:
| Almost nobody from VB really wants this legacy part from C#
|

That's your opinion and should be stated as
such. Armin was also pretending that his opinion
was fact. The OP was asking for facts and was
being deliberately misled. Armin also answered
me in an evasive, misleading way. If someone
just answered the question I wouldn't have
stepped in, but I hate to see people waste time
and get confused due to wrong, stingey and/or
arrogant answers.
Click to expand...


I've waited because I don't understand what has been
misunderstood. The question was if these pointer operations
on the bitmap are also available in VB. The short answer is: No.
That's no opinion. I intentionally didn't mention IntPtr etc because
it doesn't provide what you can do with language-native pointers, and
to me it seems that that's exactly what the OP was asking for
So, where is the problem with my answers?
 
Armin Zingler submitted this idea :
Am 01.10.2010 15:38, schrieb Mayayana:


I've waited because I don't understand what has been
misunderstood. The question was if these pointer operations
on the bitmap are also available in VB. The short answer is: No.
That's no opinion. I intentionally didn't mention IntPtr etc because
it doesn't provide what you can do with language-native pointers, and
to me it seems that that's exactly what the OP was asking for
So, where is the problem with my answers?
Click to expand...

There was no problem. Joe, just likes to misrepresent .net when the
chance is presented. Usually, that involves some twisting of meaning
to justify his, untenible possitions...

Particularly telling is his constant avoidance of the fact that it can
easily be demontrated that VB.NET is actaully superior to vb.classic
when it comes to interoperating with windows.... Though, he would like
you to think it's the other way around...
 
Am 01.10.2010 17:06, schrieb Tom Shelton:
Armin Zingler submitted this idea :

There was no problem. Joe, just likes to misrepresent .net when the
chance is presented. Usually, that involves some twisting of meaning
to justify his, untenible possitions...

Particularly telling is his constant avoidance of the fact that it can
easily be demontrated that VB.NET is actaully superior to vb.classic
when it comes to interoperating with windows.... Though, he would like
you to think it's the other way around...
Click to expand...

Just want to add that I don't have a problem with you mentioning IntPtr
and Marshal etc. If the OP would have asked if there are other ways
to achieve the same result (with different means) I would have said the
same. But as he didn't and you already replied, i stayed calm. :)
 
Back
Top