Trying to understand API calls

[Peter Newman]

Im running vb.net 2003.

Im still on a big learning curve with .net and like most people have great
ideas on what id like a peice of software to do.... but lack the knowledge
to do it

I have looked at the createwindowex function an have to admit ... im
baffled. What id like to do is run a function or proc that will pop up a
dialog box with a progress bar on and be able to pass values to the
progressbar, then distroy the dialog box after use. IS this possible using
the createwindowex function and if so how?

I know the easy route is to add a form to the project and a progress bar to
the form, but that i already know how to do

Thank you in advance for any help on this

[Cor Ligthert [MVP]]

Peter,

I see using API calls forever as those who were in past addressing the
memory addresses which did reflect the monitor.

Using Net classes can mean that you with a new OS in future have the highest
chance not to come in trouble. They use maybe API's but that can be changed
for you on a new operating system.

The API is related with the OS so at the moment WIN32 for current Windows
Systems.

Therefore I try to avoid API's.

Cor

"Peter Newman" <Pe*********@discussions.microsoft.com> schreef in bericht
news:78**********************************@microsof t.com...

Im running vb.net 2003.

Im still on a big learning curve with .net and like most people have great
ideas on what id like a peice of software to do.... but lack the
knowledge
to do it

I have looked at the createwindowex function an have to admit ... im
baffled. What id like to do is run a function or proc that will pop up a
dialog box with a progress bar on and be able to pass values to the
progressbar, then distroy the dialog box after use. IS this possible
using
the createwindowex function and if so how?

I know the easy route is to add a form to the project and a progress bar
to
the form, but that i already know how to do

Thank you in advance for any help on this

[Peter Newman]

Cor,

As a novice at this really, i am open to all suggestions and opinions, and
lets face it i can learn more from people that have applied their ideas and
code than from a book

"Cor Ligthert [MVP]" wrote:

Peter,

I see using API calls forever as those who were in past addressing the
memory addresses which did reflect the monitor.

Using Net classes can mean that you with a new OS in future have the highest
chance not to come in trouble. They use maybe API's but that can be changed
for you on a new operating system.

The API is related with the OS so at the moment WIN32 for current Windows
Systems.

Therefore I try to avoid API's.

Cor

"Peter Newman" <Pe*********@discussions.microsoft.com> schreef in bericht
news:78**********************************@microsof t.com...

Im running vb.net 2003.

Im still on a big learning curve with .net and like most people have great
ideas on what id like a peice of software to do.... but lack the
knowledge
to do it

I have looked at the createwindowex function an have to admit ... im
baffled. What id like to do is run a function or proc that will pop up a
dialog box with a progress bar on and be able to pass values to the
progressbar, then distroy the dialog box after use. IS this possible
using
the createwindowex function and if so how?

I know the easy route is to add a form to the project and a progress bar
to
the form, but that i already know how to do

Thank you in advance for any help on this

[bob]

Peter,

I'm new at vb.net too, and am not an "expert" programmer anyway. But as
I understand it, vb.net encapsulates a lot of the old API calls into
the language, so you just don't need most of the API calls now -- the
various classes in vb.net, as organized in the various Namespaces,
perform the API calls for you.

An example is the API call "ShellExecute", which I used to have to use
a lot, and would include a Declare statement for it in my programs.
Now, you just call a vb.net command (I think its
System.Diagnostics.Process) which does all the work for you without you
having to "Declare" anything.

Good luck!

Peter Newman wrote:

Cor,

As a novice at this really, i am open to all suggestions and opinions, and
lets face it i can learn more from people that have applied their ideas and
code than from a book

"Cor Ligthert [MVP]" wrote:

Peter,

I see using API calls forever as those who were in past addressing the
memory addresses which did reflect the monitor.

Using Net classes can mean that you with a new OS in future have the highest
chance not to come in trouble. They use maybe API's but that can be changed
for you on a new operating system.

The API is related with the OS so at the moment WIN32 for current Windows
Systems.

Therefore I try to avoid API's.

Cor

"Peter Newman" <Pe*********@discussions.microsoft.com> schreef in bericht
news:78**********************************@microsof t.com...

Im running vb.net 2003.

Im still on a big learning curve with .net and like most people have great
ideas on what id like a peice of software to do.... but lack the
knowledge
to do it

I have looked at the createwindowex function an have to admit ... im
baffled. What id like to do is run a function or proc that will pop up a
dialog box with a progress bar on and be able to pass values to the
progressbar, then distroy the dialog box after use. IS this possible
using
the createwindowex function and if so how?

I know the easy route is to add a form to the project and a progress bar
to
the form, but that i already know how to do

Thank you in advance for any help on this

[GhostInAK]

Hello bo*@datasync.com,

I can't answer your question about CreateWindowEx(). I simply have never
used it. But to comment on the issue of .NET vs. Win32 API I have two thoughts:

First, learn the Win32 way of doing things so that you have the background
and knowledge to understand what VB/C#/.NET/et al is doing under the hood.
After you have that knowledge, don't ever use it if you don't have to.
ALWAYS, in production code, use the Framework equivalent. The reason being
is that .NET high-level language code is easier to read than Win32 P/Invoke
code. And as I have ranted about many times before, we write code for humans,
not for computers.

-Boo

Peter,

I'm new at vb.net too, and am not an "expert" programmer anyway. But
as I understand it, vb.net encapsulates a lot of the old API calls
into the language, so you just don't need most of the API calls now --
the various classes in vb.net, as organized in the various Namespaces,
perform the API calls for you.

An example is the API call "ShellExecute", which I used to have to use
a lot, and would include a Declare statement for it in my programs.
Now, you just call a vb.net command (I think its
System.Diagnostics.Process) which does all the work for you without
you having to "Declare" anything.

Good luck!

Peter Newman wrote:

Cor,

As a novice at this really, i am open to all suggestions and
opinions, and lets face it i can learn more from people that have
applied their ideas and code than from a book

"Cor Ligthert [MVP]" wrote:

Peter,

I see using API calls forever as those who were in past addressing
the memory addresses which did reflect the monitor.

Using Net classes can mean that you with a new OS in future have the
highest chance not to come in trouble. They use maybe API's but that
can be changed for you on a new operating system.

The API is related with the OS so at the moment WIN32 for current
Windows Systems.

Therefore I try to avoid API's.

Cor

"Peter Newman" <Pe*********@discussions.microsoft.com> schreef in
bericht news:78**********************************@microsof t.com...

Im running vb.net 2003.

Im still on a big learning curve with .net and like most people
have great
ideas on what id like a peice of software to do.... but lack the
knowledge
to do it
I have looked at the createwindowex function an have to admit ...
im
baffled. What id like to do is run a function or proc that will
pop up a
dialog box with a progress bar on and be able to pass values to the
progressbar, then distroy the dialog box after use. IS this
possible
using
the createwindowex function and if so how?
I know the easy route is to add a form to the project and a
progress bar
to
the form, but that i already know how to do
Thank you in advance for any help on this

[Cor Ligthert [MVP]]

GhostInAK,

Would it than not be better following your advice to learn first WinFX
API's?.

I have seen to many OS's.

This is exactly why I don't agree with you your first part and completely
agree the last part of your message.

But just my opinion feel free to have yours.

Cor

"GhostInAK" <gh*******@gmail.com> schreef in bericht
news:be*************************@news.microsoft.co m...

Hello bo*@datasync.com,

I can't answer your question about CreateWindowEx(). I simply have never
used it. But to comment on the issue of .NET vs. Win32 API I have two
thoughts:

First, learn the Win32 way of doing things so that you have the background
and knowledge to understand what VB/C#/.NET/et al is doing under the hood.
After you have that knowledge, don't ever use it if you don't have to.
ALWAYS, in production code, use the Framework equivalent. The reason
being is that .NET high-level language code is easier to read than Win32
P/Invoke code. And as I have ranted about many times before, we write
code for humans, not for computers.

-Boo

Peter,

I'm new at vb.net too, and am not an "expert" programmer anyway. But
as I understand it, vb.net encapsulates a lot of the old API calls
into the language, so you just don't need most of the API calls now --
the various classes in vb.net, as organized in the various Namespaces,
perform the API calls for you.

An example is the API call "ShellExecute", which I used to have to use
a lot, and would include a Declare statement for it in my programs.
Now, you just call a vb.net command (I think its
System.Diagnostics.Process) which does all the work for you without
you having to "Declare" anything.

Good luck!

Peter Newman wrote:

Cor,

As a novice at this really, i am open to all suggestions and
opinions, and lets face it i can learn more from people that have
applied their ideas and code than from a book

"Cor Ligthert [MVP]" wrote:

Peter,

I see using API calls forever as those who were in past addressing
the memory addresses which did reflect the monitor.

Using Net classes can mean that you with a new OS in future have the
highest chance not to come in trouble. They use maybe API's but that
can be changed for you on a new operating system.

The API is related with the OS so at the moment WIN32 for current
Windows Systems.

Therefore I try to avoid API's.

Cor

"Peter Newman" <Pe*********@discussions.microsoft.com> schreef in
bericht news:78**********************************@microsof t.com...

> Im running vb.net 2003.
>
> Im still on a big learning curve with .net and like most people
> have great
> ideas on what id like a peice of software to do.... but lack the
> knowledge
> to do it
> I have looked at the createwindowex function an have to admit ...
> im
> baffled. What id like to do is run a function or proc that will
> pop up a
> dialog box with a progress bar on and be able to pass values to the
> progressbar, then distroy the dialog box after use. IS this
> possible
> using
> the createwindowex function and if so how?
> I know the easy route is to add a form to the project and a
> progress bar
> to
> the form, but that i already know how to do
> Thank you in advance for any help on this
>

[Jim Wooley]

Good observations. In addition to recommending the framework version of a
API call for readability sake, the framework has checking it to avoid buffer
overflows and other type conversion issues that are easily overlooked when
calling the native API's directly.

Jim Wooley
http://devauthority.com/blogs/jwooley/default.aspx

Hello bo*@datasync.com,

I can't answer your question about CreateWindowEx(). I simply have
never used it. But to comment on the issue of .NET vs. Win32 API I
have two thoughts:

First, learn the Win32 way of doing things so that you have the
background
and knowledge to understand what VB/C#/.NET/et al is doing under the
hood.
After you have that knowledge, don't ever use it if you don't have
to.
ALWAYS, in production code, use the Framework equivalent. The reason
being
is that .NET high-level language code is easier to read than Win32
P/Invoke code. And as I have ranted about many times before, we write
code for humans, not for computers.

-Boo

[Herfried K. Wagner [MVP]]

"Jim Wooley" <ji*************@hotmail.com> schrieb:

Good observations. In addition to recommending the framework version of a
API call for readability sake, the framework has checking it to avoid
buffer overflows and other type conversion issues that are easily
overlooked when calling the native API's directly.

Well, most of the .NET Framework's IO functionality is based on the Win32
API's file I/O functions too, so they could suffer from the problem too. I
don't see any disadvantages of a Win32 API-based solution that is used to
archieve things not exposed by the .NET Framework if it has been implemented
by somebody who is an expert in using the Win32 API from within .NET-based
projects.

--
M S Herfried K. Wagner
M V P <URL:http://dotnet.mvps.org/>
V B <URL:http://classicvb.org/petition/>

[Cor Ligthert [MVP]]

Herfried,

Well, most of the .NET Framework's IO functionality is based on the Win32
API's file I/O functions too, so they could suffer from the problem too.
I don't see any disadvantages of a Win32 API-based solution that is used
to archieve things not exposed by the .NET Framework if it has been
implemented by somebody who is an expert in using the Win32 API from
within .NET-based projects.
I could have written it so unreadable is it.

:-)

However it did me remember those guys who were telling me all the time that
direct addressing the memory of the Dos monitor area was better than using
the API's for that.

:-)

Cor

"Herfried K. Wagner [MVP]" <hi***************@gmx.at> schreef in bericht
news:%2******************@TK2MSFTNGP03.phx.gbl... "Jim Wooley" <ji*************@hotmail.com> schrieb:

Good observations. In addition to recommending the framework version of a
API call for readability sake, the framework has checking it to avoid
buffer overflows and other type conversion issues that are easily
overlooked when calling the native API's directly.

Well, most of the .NET Framework's IO functionality is based on the Win32
API's file I/O functions too, so they could suffer from the problem too.
I don't see any disadvantages of a Win32 API-based solution that is used
to archieve things not exposed by the .NET Framework if it has been
implemented by somebody who is an expert in using the Win32 API from
within .NET-based projects.

--
M S Herfried K. Wagner
M V P <URL:http://dotnet.mvps.org/>
V B <URL:http://classicvb.org/petition/>