Saturday, January 20, 2007
I once had an opportunity to write one of those Teach Yourself <Something complicated> in 21 Days books, or it might have been 24 Hours, or A Weekend, I forget. I was overloaded with work at the time and didn't write it. One of the things about writing those books is that nobody actually expects the reader to learn what they need in 21 days or 24 hours or whatever. It's basically the number of chapters. And if you processed one chapter a day, I guess you would cover the book in three weeks, but you wouldn't be a <Something complicated> programmer at the end of that, would you? Some folks might do 5 chapters a day, others might do a chapter a week. It depends on where you're starting from.
I came across a few interesting blog posts on this topic. Peter Norvig found hundreds of such books on programming languages or frameworks, and proposes instead Teach Yourself Programming in Ten Years. He has a point. Jasmine refines the point a bit, saying that if you're already a good developer you probably can pick up a new language or framework in a matter of days, and that if you don't have what it takes to be a good developer, ten years of plugging away at it won't make you good enough.
I've been getting paid to program since 1979, and I learn new things all the time. But I try to learn new languages no more than once a year -- and I wouldn't be able to invest 21 days in learning a language, either. More importantly, I've invested quite a lot of time and effort into spotting those who will be good developers some day, and trying to speed the process of making them better. I think the emphasis on debugging and on reading or fixing the code of others is appropriate. It's tempting to have the newbies work on little projects alone since they can't understand your big complicated project with difficult code written by the really smart people. But trying to understand that project and that code is what will make that newbie a developer -- or show you both that it's a hopeless cause .
Friday, January 19, 2007
I do my searching these days at www.live.com -- the ads are less obtrusive or easier to ignore or something and on the occasions I've done the same search in two places, I like my Live results better. But for the next little while I'm going to use a slightly more complicated URL: http://click4thecause.live.com/Search/Charity/Default.aspx?locale=en-us&source=msnhp. I know, that's a mouthful, but here's the thing - it searches the same, but it also donates to charity. Really! I know we've all seen those "if you forward this to 40 people Microsoft will know and they will give money to charity" emails, but this is different. After all, counting web hits is something that can really be done.
Education and sports programs for refugee youth around the world? Sounds like a good cause to me. Check it out, and make it your new search page, won't you?
Thursday, January 18, 2007
Rory interviews Kam VedBrat about glass, composition, DWM, and other ways to stray from the gray-buttons-and-white-textboxes-on-a-big-gray-background that is the UI most devs naturally create. Watch it!
Wednesday, January 17, 2007
Try this. Open up Visual Studio and make yourself an MFC app. It doesn't really matter what kind of application it is - a dialog app is probably the quickest to create but you could use some more complex MFC app that you happened to have lying around if you preferred. Build the app and run it to prove to yourself that it's fine.
Now bring up the project properties, and under Configuration Properties, General set Common Language Runtime Support to Pure MSIL Common Language Runtime Support.
Click OK and build the application. Blam! Errors everywhere. My little nothing dialog application got 18 and they all look like this:
1>C:\Program Files\Microsoft Visual Studio 8\VC\atlmfc\include\afxv_w32.h(242) : error C3641: 'DrawState' : invalid calling convention '__stdcall ' for function compiled with /clr:pure or /clr:safe
1>C:\Program Files\Microsoft Visual Studio 8\VC\atlmfc\include\afxv_w32.h(260) : error C3641: 'DrawStatusText' : invalid calling convention '__stdcall ' for function compiled with /clr:pure or /clr:safe
1>C:\Program Files\Microsoft Visual Studio 8\VC\PlatformSDK\include\winbase.h(1849) : error C3641: 'FreeResource' : invalid calling convention '__stdcall ' for function compiled with /clr:pure or /clr:safe
What does this mean? Well, every function has a calling convention. These include __stdcall, __clrcall, __cdecl, and so on. Many of the functions in the MFC libraries (look at the include files for which these errors occur) are declared to be __stdcall, meaning that they are common-or-garden native C++ functions. But when you compile your application /clr:pure, you are saying "I don't have any common-or-garden native C++ functions in here. Everything is managed."
Since you can't change MFC, you have to change your compiler options. Change the CLR support to just "Common Language Runtime Support (/clr)" and build again. All the errors go away.
Tuesday, January 16, 2007
Thottam R. Sriram has an article in the January MSDN Magazine called CLR Inside Out: Introduction to COM Interop. As the introduction says:
COM is a wonderful technology. One aspect of the common language runtime (CLR) that makes it an extremely powerful platform is that it allows seamless interactions between Microsoft® .NET applications and unmanaged COM components. However, when I searched the Web, I found few working samples demonstrating the very basic concepts of COM interop. The purpose of this column is to illustrate those basic concepts in order to provide solid working examples that can jump-start users in this technology.
I'll start off with a simple Active Template Library (ATL) COM server and try accessing methods in this server using an unmanaged COM client, then do the same thing with a managed client. I'll walk through the various DLLs to illustrate the translation from unmanaged to managed, and I'll show how to access an exported method in an unmanaged DLL using P/Invoke. The toughest part of this is to figure out marshaling of complex structures, which I don't cover exhaustively in this column-it would be a complete column (or book) on its own. I'll show you how unmanaged code can call back into managed code using interfaces. (You could do this with delegates as well, but I won't cover that in this column.)
Finally, I'll discuss debugging your COM interop project using public symbols. This will give you very basic introduction to WinDbg.exe, unmanaged debugging, and managed debugging using SOS. I'll demonstrate the stack from managed to unmanaged as calls are made in either direction.
The managed client is in C# -- when you write your clients in C++/CLI you don't have to figure out how to declare and marshal complex structures, after all. And seeing how to call back from native code to managed code is helpful indeed. I'm not sure if Reverse P/Invoke is the official name for this, but it works for me. You set up an interface in your C# code and decorate it with attributes for COM. Then you implement that interface in your code and use tlbexp to make a COM Callable Wrapper around your .NET object. Then you hand-define the same interface as a COM interface in your native code and you're all set. The .NET code can P/Invoke some native function and pass in a reference to the .NET interface. By the time it's unmarshaled over in the native world, it's become a smart pointer to that COM interface and you can invoke the method from the native code. It's a little tricky, but it's not hard - once you've seen it done.
Since the article wraps up by touching on Windbg, there's something for everyone. Check it out!
Monday, January 15, 2007
I read an interesting blog entry at Dumb Little Man. Essentially, the story goes like this. A guy is fed up with his job, doesn't like it, is ready to quit. Instead he throws himself whole-heartedly into it and gives it his all. He does the tasks he dislikes, he does tasks he isn't asked to do, he speaks up and speaks out, and he becomes so much happier in the job. And if that wasn't enough, he gets a two-layer promotion and a $15,000 a year raise.
His list may not precisely work for you. You may not be asked to do TPS reports, whatever they are. You may live a life like mine where no one can give you a promotion. You may not think that working long hours is important to success at your company, or worth what you have to give up in your private life. But look past the details of his particular list. What would happen if you totally threw yourself into what you are doing now and really really did it?
Sunday, January 14, 2007
Here's another reason to install Visual Studio SP1 - it fixes one class of "intellisense stops working" problems. Intellisense stops working a lot for C++ developers. It doesn't happen very often for me, but people mention it quite often when I speak and some of my coworkers are less lucky than I am because it happens in their day to day work.
If Intellisense stops working for you and you're working on a C++ project, the workaround is to close Visual Studio, find and delete the .ncb file, and re-open Visual Studio. As you can imagine, that cuts into flow quite a bit. Now a KB article mentions that SP 1 fixes "In a Microsoft Visual C++ 2005-based solution that includes multiple projects, the IntelliSense of a project does not work correctly if the project references types from another Visual C++ or Visual C# project." Cool!
Saturday, January 13, 2007
Jeff Atwood has a fun post explaining how much more quickly he finds things now that he can once again just type the names of programs. It's so true. Instead of clicking Start, All Programs, Microsoft Office, Microsoft Word Whatever, with the attendant pauses while the menus come up and the pauses while I desparately scan the huge list looking for the thing I know has to be there somewhere, it's just press the Windows key and type word, then press enter. Or perhaps type w if I'm lucky enough. The search is blazing fast and there's the application I want, or the file I want, or the control panel sub-thingy that has a new name now so I can't see it. Ah, typing. I never really gave up on typing. And now it's once again one of the main ways we'll interact with the operating system.
And not just because of the way cool search thing. There's the UAC aspect to this too. Open yourself an elevated command prompt, and everything you launch from that command prompt will be elevated -- no manifest, no right-click Run As Administrator, just run your utility so you can do whatever administrative tasks you need to do in relative peace. Small price to pay: you have to type the names of those apps (possibly with their full paths) into the command prompt.
And that's not the only deja vu I get as a Vista user and developer. Does anyone remember making Windows applications before, say WinForms? OK, before VB or before MFC? Before there was a framework that gave you an object called Button that had a property called Text or Caption or the like, how did you set the text on a button? You sent it a Windows message (WM_SETTEXT) with a parameter of "Save" or whatever you wanted. Well you don't have to do that any longer, but how do you arrange for the shield icon to appear on a button? (It's a convention that if clicking a button is going to pop up an elevation consent dialog, you put the shield on the button.) By sending it a BCM_SETSHIELD message, of course!
The longer you've been programming, the less jarring these things are. Soon enough the tools will catch up and it will be all drag-drop, set properties etc. If that's all you've ever known, you might feel like Vista has dropped you through the looking glass. But if you have some memories of the old days, you're going to be on more solid ground. And you probably still type really fast.
Friday, January 12, 2007
Eric Appel recommends installing SP1 for Visual Studio 2005 and the Visual Studio 2005 SP1 Update for Windows Vista Beta. Let's drill into that name a little bit more. Starting at the end, it's a Beta of Visual Studio 2005 SP1 Update for Windows Vista. That is in turn an "Update for Windows Vista" of "Visual Studio 2005 SP1". You have to start with SP1 first. But SP1 has nothing to do with Vista.
SP1 is a common-or-garden service pack for Visual Studio. It fixes a pile of little things that were found in Visual Studio. Some are just syntax colouring, some are real issues. And it can be argued that you should only install it if you need it. There are some issues with the service pack itself: Heath Stewart has a summary with workarounds where they are known. It can take a long time to install, and you should make sure you have enough disk space, because if the install fails the rollback is a little overenthusiastic ... you might have to reinstall Visual Studio 2005 to make sure certain libraries are in place. That said, lots of people are glad they installed it.
If you want to install the update for Vista, then you need to install SP1. And once you've done that, you'll find many things both simpler and faster. Happy me.
© Copyright 2022 Kate Gregory
Theme design by Bryan Bell
newtelligence dasBlog 2.3.9074.18820
| Page rendered at Thursday, August 11, 2022 7:01:51 AM (Eastern Daylight Time, UTC-04:00)
On this page....
Pluralsight Free Trial