 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
VB Forum / Win API / June 2008TLB or not TLB
Have a VBA and VB6 project with some 140 different Windows API calls plus all the corresponding structures, constants and enums. As it looks neat and as I understand there might be some performance gain (on startup) I had a go at putting all these API's in a typelib. For this I use the typelib editor from Matthew Curland as this looks the simplest way. Still, the whole undertaking is not that simple and I can see pro's and con't and wonder if there is any general or majority opinion amongst the users of this group as to if an API typelib is worth the effort, compared to just using Declares. Thanks for any insight in this. RBS > Have a VBA and VB6 project with some 140 different Windows API calls > plus all the corresponding structures, constants and enums. [quoted text clipped - 8 lines] > Declares. > Thanks for any insight in this. Using a pre-existing typelib, like the WindowsAPI one, is a godsend. (Of course, it doesn't have ALL functions/constants/types in it, so a few declares/constants/typelibs are always required.) Creating a custom tlb for specific applications/projects....not worth the effort, IMO. > like the WindowsAPI one Is this the one from Bruce McKinney? RBS >> Have a VBA and VB6 project with some 140 different Windows API calls >> plus all the corresponding structures, constants and enums. [quoted text clipped - 15 lines] > Creating a custom tlb for specific applications/projects....not worth the > effort, IMO. >> like the WindowsAPI one > > Is this the one from Bruce McKinney? > > RBS It may be. I've used it a long time and don't recall where it came from originally. > Have a VBA and VB6 project with some 140 different Windows API calls plus > all the corresponding structures, constants and enums. [quoted text clipped - 8 lines] > Declares. > Thanks for any insight in this. Performance-wise, I dunno if it really make any difference. After all, Declare statements are not executable code, so that's certainly not an issue. IMO, all you'd really gain by using a type library is "ease of use". IOW, you can just reference the type library and you've got all those API functions, structures, and constants without having to copy and paste them all. I created a type library containing all the common controls API functions, structures, and constants and use that in most of my projects that use any of Windows' common controls (treeview, listview, etc.). But for pretty much any other API-related thing, I just add the needed declarations, etc.  SignatureMike Microsoft MVP Visual Basic > Performance-wise, I dunno if it really make any difference. After all, > Declare statements are not executable code, so that's certainly not an > issue. I read somewhere that it would make a difference, maybe it was McKinney. Then there is the difference about VB and VBA, VBA being un-compiled. My main use will be in VBA. Would that make a difference. Final answer will be testing it out and I am not far off doing that. RBS >> Have a VBA and VB6 project with some 140 different Windows API calls plus >> all the corresponding structures, constants and enums. [quoted text clipped - 20 lines] > of Windows' common controls (treeview, listview, etc.). But for pretty > much any other API-related thing, I just add the needed declarations, etc. RB Smissaert <bartsmissaert@blueyonder.co.uk> schrieb im Beitrag <uiJK2tZ0IHA.1240@TK2MSFTNGP02.phx.gbl>... > I read somewhere that it would make a difference, maybe it was McKinney. > Then there is the difference about VB and VBA, VBA being un-compiled. > My main use will be in VBA. Would that make a difference. > Final answer will be testing it out and I am not far off doing that. The only purpose and use of both the Declare statement and the type library is to make functions, structures, etc. known to the VB interpreter/compiler. Since both are resolved at compile time there shouldn't be any difference in performance. The main differences are: - It is much easier to edit a Declare statement than a type library - A type library entry is of project global scope; Declare statements may be used with module global scope which allows different Declare statements for the same external procedure in one project (e.g. different SendMessage() declarations) - Declare statements are more flexible in that they allow a declaration "As Any" - Type libraries are more flexible in that they allow also the definition of data types, structures, etc. which is not possible with declare statements, and in that they allow to use data types which are not known to VB. Which one to use depends on nothing else but your personal preferences. I myself prefer Declare statements because they are so easy to edit. Signature---------------------------------------------------------------------- Thorsten Albers albers(a)uni-freiburg.de ---------------------------------------------------------------------- > Since both are resolved at compile time there > shouldn't be any difference in performance. But I have definitely noticed a performance gain in VBA. So, moving all Declares and structures and enums and constants to a .tlb speeds up startup time of the VBA project. > - Declare statements are more flexible in that they allow a declaration > "As Any" .tlb can do that as well by declaring as void in the .tlb. > which allows different Declare statements for the same external procedure > in one project > (e.g. different SendMessage() declarations) Can do that with a .tlb as well. > prefer Declare statements because they are so easy to edit. With the TypeLib editor from Matthew Curland it is very easy as well. It really is a good bit of software. As you say pro's and con's and still not sure what the best way is. As I have done the hard work now and made the .tlb for all my 140 or so API's plus related structures etc. I think I will stick with it. RBS > RB Smissaert <bartsmissaert@blueyonder.co.uk> schrieb im Beitrag > <uiJK2tZ0IHA.1240@TK2MSFTNGP02.phx.gbl>... [quoted text clipped - 24 lines] > Which one to use depends on nothing else but your personal preferences. I > myself prefer Declare statements because they are so easy to edit. > RB Smissaert <bartsmissaert@blueyonder.co.uk> schrieb im Beitrag > <uiJK2tZ0IHA.1240@TK2MSFTNGP02.phx.gbl>... [quoted text clipped - 7 lines] > interpreter/compiler. Since both are resolved at compile time there > shouldn't be any difference in performance. One difference comes from the fact that behind the scene VB sets up the 'call' differently for a Declare Directive compared to a TypeLib definition. For example, it does a runtime check on the parameters for a Directive, but not for a Typelib. Another, (which is likely why start-up is a bit quicker for a TypeLib) is that VB for a directive needs to do a text search on the export list to find the offset/progid/etc, where with Typelib all that is already provided. > The main differences are: > - It is much easier to edit a Declare statement than a type library > - A type library entry is of project global scope; Declare statements may > be used with module global scope which allows different Declare statements > for the same external procedure in one project (e.g. different > SendMessage() declarations) I don't consider either of these to be a benefit for a major project. <g> True. Declare statements can be changed easily during normal editing, but this also makes it is easy to accidently (or deliberately) insert variations at different locations. This IMHO is a prescription for trouble. One can easily provide multiple TypeLibs (yech! But possible. <g>), ie: JunkStrAPI.Routine() JunkLngAPI.Routine() or what I prefer: JunkAPI.RoutineStr() JunkAPI.RoutineLng() A typelib, on the other hand, is essentially 'hidden' away during development and only modified through a specific process. (ie, I treat IDLs and TypeLibs as separate projects and track through VSS.) Using a typedef for the WinAPI or any other common libraries will insure consistent results (ie, no surprises) across modules, components, and suites. > - Declare statements are more flexible in that they allow a declaration "As > Any" While it often makes the more deterministic among us to squirm a bit - "As Any" has been a ghod-send on occasion. <g> [Note: a Declare directive will over-ride any Typelib definition.] > - Type libraries are more flexible in that they allow also the definition > of data types, structures, etc. which is not possible with declare > statements, and in that they allow to use data types which are not known to > VB. Definitely agree with that. > Which one to use depends on nothing else but your personal preferences. I > myself prefer Declare statements because they are so easy to edit. Certainly agree with that. I would also add: A Declare statement takes a minimum of 16 bytes each, and usually a lot more. Typelibs add no overhead to the finished product. [This was probably a consideration once upon a time, but in this day of gigabyte applications - I doubt the 'size' overhead would ever be noticed. <g>] A Declare statement causes the addition of extra code to do parameter checking at runtime. With a typelib VB will do type checking during syntax-checking, before the compile. Again no extra overhead in the released version. And you get Intellisense. With a Declare statement there is no Intellisense. Many errors are not discovered until runtime. -ralph > One can easily provide multiple TypeLibs (yech! But possible. <g>), > ie: JunkStrAPI.Routine() > JunkLngAPI.Routine() > or what I prefer: > JunkAPI.RoutineStr() > JunkAPI.RoutineLng() It's easy to provide several aliases for the same entry point using a TLB. You don't need multiple TLBs for that (assuming you know the ordinal). > While it often makes the more deterministic among us to squirm a > bit - "As Any" has been a ghod-send on occasion. <g> > [Note: a Declare directive will over-ride any Typelib definition.] Not sure what your point is here, but As Any is certainly possible in a TLB using void *. And you have to be careful when overriding a TLB entry, because you can do things in a TLB that you can't in a Declare (e.g. BSTR/LPSTR). Which brings up another benefit of TLBs -- one of the biggest, IMO. You can directly access the -W versions of APIs without StrPtr hoops (full type checking). Unicode access to the WinAPI (and your own functions) can give a big performance boost in many cases. One odd restriction in a TLB, and this is a VB problem only, is that you can't #define a constant As Double. It gets completely wacked by VB. So, no Pi for you. > And you get Intellisense. With a > Declare statement there is no Intellisense. Many errors > are not discovered until runtime. You don't get Intellisense with your Declares? I do...? -- Jim Mack MicroDexterity Inc www.microdexterity.com > > One can easily provide multiple TypeLibs (yech! But possible. <g>), > > ie: JunkStrAPI.Routine() [quoted text clipped - 30 lines] > > You don't get Intellisense with your Declares? I do...? All good points. My "multiple TypeLibs" comment was purely flippant and not meant to be taken that seriously, only addressing an implication of separate 'api sets'. As for an Intellisense. I wasn't very clear and deserve to be taken to task. (My only excuse is the time of posting.) What I was trying to convey was more related to the convenience of Intellisense during development, which is just a repeat of what I already had said. If I reference a typlib - bang I got Intellisense for all the methods along with a help string (viewable in Object Browser). If I use Declares I only get Intellisense for the Declare statement, in scope, that I typed in. If I make a mistake with the Declare - I get 'mistaken' Intellisense. In other words - sure I get something that puts up while I type - but it will only be what I already typed before? The only thing Intellisense does in that case is insure I'm consistently wrong. <g> As for the "As Any" comment. That is perhaps more supersition than anything else. "Void *" while functionally equivalent to my mind as well, but, (purely anecdotal) while playing around with writing a Type Library I have found it to fail, while using a Declare with "As Any" worked until I found a data type both parties could agree on. Anyway, there's my excuse, but all your admonishments are justified. <g> -ralph > RB Smissaert <bartsmissaert@blueyonder.co.uk> schrieb im Beitrag > <uiJK2tZ0IHA.1240@TK2MSFTNGP02.phx.gbl>... [quoted text clipped - 21 lines] > Which one to use depends on nothing else but your personal preferences. I > myself prefer Declare statements because they are so easy to edit. Calls in a TypeLib can also be used from another thread when doing "evil things" :) In may case, it was an asynch callback from WinInet when I need to reset an event and close a few handles. SignatureDean Earley (dean.earley@icode.co.uk) i-Catcher Development Team iCode Systems I like MikeD's idea of TLBs for controls. Those constants can be a pain to track down. Aside from that, I usually avoid TLBs unless I absolutely need them. The reason for that is because people who have written them tend to dump "everything but the kitchen sink" into a single TLB. Often when working with Shell, OLE, etc. I find that I'm faced with needing two TLBs, neither of which have all that I need but both of which have their own style of declaring CopyMemory, SendMessage, etc. And often those styles will conflict with my own habits. That can get confusing. Ironically, the only time I've actually edited a TLB myself was when working on code to read TLBs. :) I did so at that time because I only needed the interfaces ITypeLib and ITypeInfo, and those interfaces had been dealt with differently by various people. I needed to create consistency in my own code. > Have a VBA and VB6 project with some 140 different Windows API calls plus > all the corresponding structures, constants and enums. [quoted text clipped - 7 lines] > worth the effort, compared to just using > Declares. I just about never use typelibs. The only common exception is if I want to specifically override VB's insistence on calling GetLastError on every API call. (This may be the efficiency you said you had read about?) Otherwise, I find typelibs just ghastly to work with, compared to the efficiency of each module having its own tested declares. Don't overlook reusability in your calculations! Signature.NET: It's About Trust! http://vfred.mvps.org Still not sure about this one. > I find typelibs just ghastly to work with Could you elaborate a bit? RBS >> Have a VBA and VB6 project with some 140 different Windows API calls plus >> all the corresponding structures, constants and enums. [quoted text clipped - 15 lines] > efficiency of each module having its own tested declares. Don't overlook > reusability in your calculations! > Still not sure about this one. > >> I find typelibs just ghastly to work with > > Could you elaborate a bit? I dunno. Ghastly is clearly a subjective description. I find next-to-no benefit to typelibs, in nearly every case, and plenty of problems. Declares are just downright comfortable, like an old worn tshirt or your favorite robe. Typelibs are like polished shoes a size too small. Weddings or funerals only! If that. Signature.NET: It's About Trust! http://vfred.mvps.org > > Still not sure about this one. > [quoted text clipped - 9 lines] > .NET: It's About Trust! > http://vfred.mvps.org What kind of problems? Having made the .tlb (which wasn't that simple and took a bit of time) I haven't seen any problems with it yet. RBS |
Reply to this Message |
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2009 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.