Trying to understand API calls

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

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,

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
 
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
 
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!
 
Hello (e-mail address removed),

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
 
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
 
Jim Wooley said:
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.
Click to expand...

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.
 
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.
Click to expand...

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
 
Back
Top