|
Jason Bock Visual Basic 6 Win 32 API Tutorial Interview Questions
Sometime during the summer of 1998, I received an e-mail message from Wrox's server telling me that I had to update my username and password. When I went to Wrox's site, there was a link for "Authors Wanted." For some reason, I decided, hey, why not? What do I have to lose? I haven't really pursued writing as a career (much less a hobby), but I figured it's worth a shot. So I contacted the VB person at Wrox, and the rest is history. My primary goal is that they'll be able to look at any API call from any DLL, and be able to figure out how to use it effectively. It's becoming impossible to know how to use every call that's available, so it's more important to be able to read the call syntax and translate the data types to VB.
I think the question can be generalized to, "What is a good function?" Three primary points come to mind: The purpose of the function should be reflected in the function's name, the number of arguments should be small, and the argument declarations should be clear. These are relative rules-of-thumb and there are many more, but I know that if I can look at a function's signature and know already what the call is going to do, that's made my job much easier. For example, here are two fictitious functions that return the clock speed of your processor. Which one makes more sense? Declare Function GetProcessorSpeed Lib "ChipLib.DLL" () As Long Declare Function PrcsrSpd Lib "Cp.DLL" () As Long I'd rather see the first one myself. The function name clearly states what this API call will do. The second one has an abbreviated name that doesn't make a whole lot of sense on its' own. Good question! I don't think I can say there's one call that stands out in my mind, but here are some that I use quite often: CopyMemory CreateFile CreateThread (which doesn't work in 6.0, ouch!) Speed is definitely a factor, although just because you use an API call does not guarantee that your VB program will scream. I also think that having the ability to access services and functionality at a lower level is a tool that every VB programmer should have. Plus, as I demonstrate in the book, you simply can't do in VB what you can do with API calls in some situations (menu functionality is a good example of this). Absolutely. Again, no matter what you're using VB for, whether it's creating components that run under MTS, or designing front-ends for n-tier applications, the bottom line is that your code is running on Microsoft's OS. Therefore, I believe that the VB programmer who invests the time reading more advanced Windows OS books and COM programming issues is far ahead of the game. I'm not suggesting that you have to be an expert, but the more time you try to gain a comprehensive understanding of COM, MTS, ASP, NT, etc., you're much better off. Then, by having this knowledge, you might be able to make your VB programs run even better. I strongly suggest saving your work, but that applies for any kind of development (be it writing a VB program or a Word document), because you never know when the OS may decide to take a trip to la-la land. I believe that it's even more important to research the call that you're trying to use before you hit the "Run" button in VB. That alone will save you a lot of debugging time and pain in the long run. Microsoft has all of the APIs documented online, and I always use their site as a starting point. Play a lot of PlayStation games. No, seriously, I'm an avid reader of just about anything - science fiction, philosophy, religion, etc. I try to make time to read about more than programming issues. I also like golfing, biking and weightlifting, and tennis. Oh yes, I like spending time with my wife - that's #1 on the list! It's kind of weird. Although I do buy a fair amount of books online, I still visit the local bookstores. So far, I haven't seen my book on the shelf yet because it just came out, but it's going to be strange if I walk into the computer section and see someone perusing my book. If they look at the cover, and then at me, and the realization comes across their face … that's a situation I've never dealt with before! Oh yes, it's going to be all the rage at every VB conference in 1999! It does look rather hideous, doesn't it? I can't take credit for that idea. It's a good one, though. I guess someone at Wrox said, "Well, he's using API calls, and they can be mysterious at times. He's also creating an encryption program throughout the book, and that's mysterious as well. So why don't we use the Holmes silhouette in the book?" Plus, as you know, Sherlock Holmes is A Private Investigator (A.P.I.). Wow, the list could get quite long indeed! There are so many people that I respect for what they've done in their life, but I'll try to keep it short: Roger Penrose, Stephen Lawhead, Frank Herbert, Philip Yancey, Russell Banks, Douglas Hofstadter, and Neil Peart. Spaghetti would have to be on the menu - it's my favourite dish. There'd have to be a lot of bread around as well. I'd also like Newcastle Brown Ale for my beer selection. And I'd hope that both Pat McCurdy and StreetLife were playing at the party. I'd want Pat because I met my wife at one of his shows and StreetLife because they played at my wedding. They're two local acts in Milwaukee that are always entertaining. I went into the process without a lot of preparation, and that resulted in a lot of late nights in my den wondering why something wasn't working. Just like we've all seen in the computing industry, if you spend time analyzing the problem before you jump into the code, it will make the process cleaner. I'd also let the first-time author who is also working full-time at another job (like I am) to become acquainted with caffeine, if s/he hasn't already. Even when some chapters were completed without a lot of problems, I still had some late nights just typing away or trying to figure out what I wanted to say. Again, preparing yourself before you write one chapter will help in eliminating some of the late nights. Finally, be honest with your work. If you done everything you can in the time allotted for the chapter and you just can't figure out why something doesn't work, just admit it. For example, I ran into a weird issue with UDTs and the LenB function in VB - it acted differently from version 5.0 to 6.0. After tearing whatever hair is on my head out, I resigned myself to the fact that I just won't figure it out, and I talk about this problem in the book. Sometimes, the answer you get is, "Sorry, come back later." There's nothing wrong with that, and it's far better to admit your lack of knowledge on a topic than to do a bunch of hand waving. That may fly with some programmers, but the hard-core ones will not take kindly to smoke and mirrors!
|
Quick searches: Site Search | Advanced Site Search |
|
By using this site you agree to its terms and conditions VB Explorer and VBExplorer.com are trademarks of Exhedra Solutions, Inc. |