Printable View
why we need to declare API functions, types, constants every projects? in fact, we do the same thing but not a easy one.
why can't we remove API declarations from our projects forever?(such as vc++, it have many many head files to replace declare by copy texts from API Viewer.)
You are going to have to better explain this one...
VB does not implicitly support API calls but by adding explicit API declarations VB can support them.
I don't think so, download the file:Quote:
VB does not implicitly support API calls but by adding explicit API declarations VB can support them.
http://upload.programfan.com/upfile/200701151627498.rar
Extract to you hard disk, and then open a new vb project, click the menu item:project -> reference , browse the file which be extracted. and then enter code:
run it, you will find that "MessageBox" and "MB_OK" are not declare but can be used normally.vb Code:
We need to declare it because it's not included in VB package. I think the dll are written in C++. We are just borrowing or using the functions inside the dll to be use in VB. OK im not good at explaining.
Yes. But not all of them. There are 900+ API calls even more advance than that. I see no point in arguing about this wherein you definitely need to declare it whether you like it or not.Quote:
Originally Posted by tanchuhan
No, it was not a dll which be written by vc++, it was written by myself.
before anything you said, please do anything you need.
in fact, I do it. I am writting it now, and I will try to include all the API function, constants, types(as I can)Quote:
Yes. But not all of them. There are 900+ API calls even more advance than that. I see no point in arguing about this wherein you definitely need to declare it whether you like it or not.
I believe we are talking about native Win32 API calls not custom written ones. Plus, there are 2000+ APIs now when you include the new ones used in Vista.
yes, maybe you are right, but now I include a API I would no longer need to declare 1 API. if I include 1000 APIs, I would no longer need to declare 1000 APIs, why not do it?
you must know that it was not a plus or other else, it was a type library(such as the "Dir" was the function of VBA type library(in fact, we can declare it as a dll function).
type library was not a plus, it was only used to declare functions, constants, types and interface.
Now this is interesting. Can you send me samples of that?
I said it in #4, you only need to do as I said.
I have no idea what this thread is even about...:confused:
This thread is about why we need to declare APIs in a project.
tanchuhan is talking about creating a dll including all of them so just a reference to the dll and your able to use the API function calls implicitly.
Wow, is this a real thing? Will it include all API function calls in a single DLL?
Oh that makes much more sense. :)Quote:
Originally Posted by RobDog888
Edit: Although, personally, I usually use APIs to prevent from referencing another DLL to begin with or by adding another dependency to my project. :p
Yup, same here. Its not really hard at all to declare an API and allot less work then creating a dll that will need updating every so often. There are about 1,100 - 1,200 VB 6 APIs before Vista and Vista added about another 900 I believe.
a vb6 project's Package/Deployment footprint is already ~1.5MB for "Hello World." I cannot imagine intentionally inflating this size simply to avoid declaring a few APIs and Constants.
No, you don't need to bring this type library file when you publish you application.
As I said before, it was only used to "declare APIs"!
And not just that API's can be declared differently depending on how you want to use them, RtlMoveMemory for example.Quote:
Originally Posted by RobDog888
I missed that nugget.Quote:
No, you don't need to bring this type library file when you publish you application.
As I said before, it was only used to "declare APIs"!
How would this be updated? How would you to keep it current?
How would you ensure that this support info is complete and accurate? (ha ha more accurate than API Viewer:eek: )
How do you handle multiple declarations to the same function? (Milk used the RTLMoveMemory example)
[ More To Come...]
I'm with DigiRev and RobDog888....what you are proposing sounds like more work than reward. If an app uses two APIs, why ship it with 1000+ API declares?
OH! MAN!
Hack, I wish that you had been on the MSVBVM60.DLL dev team.
Those Redmond jokers should have broken that file into bits!
in vc++, when you do this:#include <windows.h>, there are more than 1000 APIs will be declared, even if you only used "MessageBeep()", so why?Quote:
I'm with DigiRev and RobDog888....what you are proposing sounds like more work than reward. If an app uses two APIs, why ship it with 1000+ API declares?
please read this:
(Bruce McKinney
April 18, 1996)
Quote:
For example, WIN32API.TXT contains about 1500 Declare statements, most of which you would never use from Visual Basic even in your wildest dreams. The hardest of hardcore Visual Basic programmers would be lucky to use 100 in a single project. If you were foolish enough to load WIN32API.TXT into a project, you would pay a memory penalty of about 20 bytes minimum for each Declare in the file—and that's not even counting the constants. So nobody actually loads the more-than-30,000 bytes of WIN32API.TXT data directly into their programs. Instead, they cut and paste the parts they need for each project.
WIN32.TLB isn't nearly as comprehensive as WIN32API.TXT. It contains about 475 function entries focused specifically on those that Visual Basic programmers are most likely to need. You'll pay about the same memory price for the functions you use from a type library, but if you only use three, you only pay for three. If this sounds too good to be true, well, it is. Type libraries have some significant limitations that make it impossible to provide some of the most useful API functions. We'll get to those limitations later.
So then why would you want to make a dll containing all api calls?
Quote:
So nobody actually loads the more-than-30,000 bytes of WIN32API.TXT data directly into their programs. Instead, they cut and paste the parts they need for each project.
you should read this:
special:Quote:
WIN32.TLB isn't nearly as comprehensive as WIN32API.TXT. It contains about 475 function entries focused specifically on those that Visual Basic programmers are most likely to need. You'll pay about the same memory price for the functions you use from a type library, but if you only use three, you only pay for three. If this sounds too good to be true, well, it is. Type libraries have some significant limitations that make it impossible to provide some of the most useful API functions. We'll get to those limitations later.
Quote:
You'll pay about the same memory price for the functions you use from a type library, but if you only use three, you only pay for three.
I'm sorry but you do not understand how much work you are doing by creating a dll, having to distribute the dll in addition to your other files, and maintaining dll versions for updates/additions to the declarations, etc.
Bottom line is its not worth doing and if it was, someone would have done it about 10 years ago when VB 6 came out.
Later
yes, someone had done it. Do you know Bruce McKinney, he is the master of microsoft vb5/6 group, he had done it in vb5 times.Quote:
someone would have done it about 10 years ago when VB 6 came out.
I am not sure if you view my type library file in #4, in fact, it's not a dll, it's a type library. Do you know type library? It's created by mktyplib.exe or midl.exe. the type library which I created was make by mktyplib.exe. It consist of many ODL(Object Define Language) files.Quote:
I'm sorry but you do not understand how much work you are doing by creating a dll, having to distribute the dll in addition to your other files, and maintaining dll versions for updates/additions to the declarations, etc.
I had done it ago, but it had some bugs, such as pointer, string(UNICODE and ANSI), and different declaration of a function. so I write it again now, and I will test every function, every types strictly as I can.
now I have completed these sections: Atom, Menu. not too much but only pay 2 days.
If it was such a great accompishment utilities like the API Viewer would not be so vastly popular.
You spent 2 days already on it, I probably never have spent 2 days adding declares to all my projects I have written over the past 10 years. It only takes a second or two to add one and not complicated at all. I can see you are stuck with this thinking as other members have all told you the same things and you have not listened. If you want to have functionality as VC++ has then perhaps you should write in VC++ instead. :rolleyes:
I still don't really see the point? Even if it doesn't add a dependency. The time it takes to download/reference the TypeLib I could have already added the necessary API functions. Even if I was making a large project that required a lot of APIs/Constants, I'd rather only add the necessary ones.
Maybe that's just me though.
I'm not THAT lazy to open the API viewer. ;)
But this is coming from someone who prefers not using code written by other people anyway. Nothing wrong with it. But I have an OCD about perfect code that is neat and clean and I have my own way of doing things. I would probably reformat the existing code and rename all variables to the way I do it because I have a problem.
So yea...
I don't want to talk too much again.
in fact, I am so tired to run vb. what's vb? basic? simple? or not a good language?
people alway look down at vb, they think vb was not a complex language, so it must be not a good language.
when so one who ask me question:"which language do you use best?" if I answer:"vb". he will say:" haha, a simple language."
I had learnt vb for 4 years, I know almost things in vb6, I am so tied to face vb that now I write application in vc++2005 almost.
If I want to find a good job, I can't say:"I am good at vb.", I must say:"I am good at c#/c++".
It's not so good but fact.
I don't understand why the big fuss. If you want to easily use C headers, use C or C++. It's not about any language being 'better' than another, just the right tool for the job and all that...