Outside The Box
Random thoughts about AutoCAD, ObjectARX, and the meaning of life.
All Original Content Copyright 2006 - 2008 Owen Wengerd, All Rights Reserved
2010-03-09
I saw in the March 8 edition of the TenLinks Daily newsletter that Alan Kalameja passed away at age 55. Condolences to his family. Alan hired me to write test questions for an AutoCAD certification exam in the early '90s (I don't recall which version, but probably either R12 or R13). That was one of my first real contracting jobs. Although it wasn't very glamorous, it made me feel important, and undoubtedly helped focus my fledgling consulting business on AutoCAD. Thanks, Alan, for giving me that opportunity.
2010-01-17
This post is inspired by a conversation I had with a nephew, and it hearkens to the same nostalgic emotions engendered by the first music video on MTV.
I was a young inquisitive child growing up in the 70s in an Amish household. Without access to modern technology, I struggled at age 11 to build an oscillator circuit by using sheet metal cut from an old stovepipe, a 9 volt battery fitted into a piece of 2x6 pine, dynamite wire scavenged from the nearby strip mine, and a speaker and 555 timer IC that I cut out of some electronic equipment dug out of the local garbage dump.
The achievement was incredible considering the circumstances, but thinking back, I have very little recollection of the actual consummation of the project. I assume I probably showed it proudly to my friends, who would have been awestruck, but completely ignorant of how it worked or why it was important to me. I simply don't remember what I did with the project after it was complete.
What I do remember fondly is the struggle to achieve; the thrill of the hunt. I struggled to get information. I had obtained a prized 555, but I had to wait for weeks until the next trip to the city so I could stop by Radio Shack to get a pinout of the 555 along with circuit diagrams showing how to use it. Then I had to find components. I had long since built a treasure trove of capacitors and resistors that I had salvaged from discarded electronics, along with a pot full of potentiometers that I could use to adjust the oscillator frequency, but I still had to scavenge for some missing components.
The challenges of the quest made the final result more satisfying. It was the search for the holy grail that etched itself into my memory; I barely remember the grail itself.
Over the holidays during a family gathering, one of my Amish nephews was anxious to pick my brain. He explained that someone had told him that it's possible to convert an electric motor into a generator, and so he set out on a quest to build a generator from an old electric motor and a small gasoline engine. The quest involved several letters mailed back and forth between people he knew that might have information about how to go about the task. He tried and tried, but could not get his generator to work.
I explained to him how he needed to remove the external circuitry from his motor so that it wouldn't foul up the results; how he can add a rectifier and a regulator to generate direct current output. The excitement over this new discovery was written all over the young man's face as he anticipated more adventure.
On the way home, I thought to myself that Google could quickly and easily have provided the answers that my nephew sought. But then it occurred to me that Google would also have deprived him of the struggle and adventure of discovery that motivates him to continue the quest.
I wonder how many young minds are missing out on the supreme adventure of discovery because we live in a modern culture where all the knowledge in the universe is seemingly already at our fingertips, just a Google search away.
I was a young inquisitive child growing up in the 70s in an Amish household. Without access to modern technology, I struggled at age 11 to build an oscillator circuit by using sheet metal cut from an old stovepipe, a 9 volt battery fitted into a piece of 2x6 pine, dynamite wire scavenged from the nearby strip mine, and a speaker and 555 timer IC that I cut out of some electronic equipment dug out of the local garbage dump.
The achievement was incredible considering the circumstances, but thinking back, I have very little recollection of the actual consummation of the project. I assume I probably showed it proudly to my friends, who would have been awestruck, but completely ignorant of how it worked or why it was important to me. I simply don't remember what I did with the project after it was complete.
What I do remember fondly is the struggle to achieve; the thrill of the hunt. I struggled to get information. I had obtained a prized 555, but I had to wait for weeks until the next trip to the city so I could stop by Radio Shack to get a pinout of the 555 along with circuit diagrams showing how to use it. Then I had to find components. I had long since built a treasure trove of capacitors and resistors that I had salvaged from discarded electronics, along with a pot full of potentiometers that I could use to adjust the oscillator frequency, but I still had to scavenge for some missing components.
The challenges of the quest made the final result more satisfying. It was the search for the holy grail that etched itself into my memory; I barely remember the grail itself.
Over the holidays during a family gathering, one of my Amish nephews was anxious to pick my brain. He explained that someone had told him that it's possible to convert an electric motor into a generator, and so he set out on a quest to build a generator from an old electric motor and a small gasoline engine. The quest involved several letters mailed back and forth between people he knew that might have information about how to go about the task. He tried and tried, but could not get his generator to work.
I explained to him how he needed to remove the external circuitry from his motor so that it wouldn't foul up the results; how he can add a rectifier and a regulator to generate direct current output. The excitement over this new discovery was written all over the young man's face as he anticipated more adventure.
On the way home, I thought to myself that Google could quickly and easily have provided the answers that my nephew sought. But then it occurred to me that Google would also have deprived him of the struggle and adventure of discovery that motivates him to continue the quest.
I wonder how many young minds are missing out on the supreme adventure of discovery because we live in a modern culture where all the knowledge in the universe is seemingly already at our fingertips, just a Google search away.
Labels: nostalgia
2010-01-11
Many of you use my VC Build Hook utility to target multiple versions of AutoCAD from a single solution in Visual Studio 2008. Visual Studio 2010 now includes a new feature called native multi-targeting that performs the same function as VC Build Hook. The new feature works great for using build tools back to VC 7.1, but it does not work with VC 7, which is required for targeting AutoCAD versions 2006 and earlier.
The problem is that VC 7 chokes on Unicode response files. In earlier versions of Visual Studio you could set a project property to select Unicode or ANSI response files, but that property has been removed in Visual Studio 2010. I have been told by a Microsoft engineer that the problem will be addressed in SP1, presumably by adding that project property back.
The moral of the story is that you'll need to wait for SP1 before you'll be able to use the VC 7 build tools from within the Visual Studio 2010 IDE. I am not planning to update VC Build Hook to support Visual Studio 2010.
The problem is that VC 7 chokes on Unicode response files. In earlier versions of Visual Studio you could set a project property to select Unicode or ANSI response files, but that property has been removed in Visual Studio 2010. I have been told by a Microsoft engineer that the problem will be addressed in SP1, presumably by adding that project property back.
The moral of the story is that you'll need to wait for SP1 before you'll be able to use the VC 7 build tools from within the Visual Studio 2010 IDE. I am not planning to update VC Build Hook to support Visual Studio 2010.
Labels: ObjectARX, programming, Visual Studio
2009-12-24
There are a myriad of ways to load AutoLISP applications in AutoCAD, including acaddoc.lsp, an .mnl file, the Startup Suite, and manually by various means. For application developers wishing to deploy their applications to others, all of these methods have drawbacks. The ideal solution should be easy to implement in an installation program, require minimal or zero changes to the user's AutoCAD configuration, work the same way across all versions of AutoCAD, and easily undone when the application is uninstalled.
ObjectARX application developers have long used registry demand loading to load their applications automatically, either when AutoCAD starts or when the user enters a command that the application defines. Registry demand loading is relatively easy to set up and meets the other requirements for an ideal solution, except for one problem: it works only with ObjectARX modules (or with .NET modules in AutoCAD 2006 and later).
Many years ago, I created a solution to this problem by building a small stub ObjectARX module that did nothing but load an associated LISP file. This effectively allows the registry demand loading mechanism to be used for loading a LISP file. If you develop AutoLISP applications that could benefit from registry demand loading, then I have a Christmas present for you: LspLoad.zip contains a complete suite of newly updated stub modules for all versions of AutoCAD from AutoCAD 2000 to AutoCAD 2010, plus modules for Bricscad 9 and 10, which also supports registry demand loading.
To use the stub modules, just rename them so that the base filename matches your application's main LISP filename, then install them in the same folder as the LISP file and create the registry demand load entries. The only work you have to do is to get the stub module to load. You can simply drag and drop the appropriate stub module into a running instance of AutoCAD in order to test it.
Creating the demand loading registry keys is not difficult, but it may require some programming. I write custom actions for my installation programs that enumerate all installed AutoCAD versions and flavors, and set up the demand load keys for every one. However you do it, the final result should look something like this (for AutoCAD 2010 on my system):
In this screen shot, I created an application called "!LspLoadTest" (the "!" was added just so it displayed at the beginning of the list). I added the minimum required subkeys. The LOADER string value is set to the complete path of the stub module, and LOADCTRLS is set to a value of 2, which means I want the application loaded when AutoCAD starts. LOADCTRLS is a bit coded value; for use with LspLoad, it's only useful values are 2 or 4. A value of 4 means "load when my command is invoked"; this mode requires a COMMANDS subkey that lists the defined commands.
The way it works is very simple. In the example above, you can see that I renamed the module (but left the ".18.x64.arx" so that I can tell it apart). I then added !LspLoadTest.lsp to the W:\LspLoad folder. That file contained the following:
Now when I start AutoCAD 2010, I see on the command line:
These files are free to use for any purpose. Have a great holiday, everyone!
ObjectARX application developers have long used registry demand loading to load their applications automatically, either when AutoCAD starts or when the user enters a command that the application defines. Registry demand loading is relatively easy to set up and meets the other requirements for an ideal solution, except for one problem: it works only with ObjectARX modules (or with .NET modules in AutoCAD 2006 and later).
Many years ago, I created a solution to this problem by building a small stub ObjectARX module that did nothing but load an associated LISP file. This effectively allows the registry demand loading mechanism to be used for loading a LISP file. If you develop AutoLISP applications that could benefit from registry demand loading, then I have a Christmas present for you: LspLoad.zip contains a complete suite of newly updated stub modules for all versions of AutoCAD from AutoCAD 2000 to AutoCAD 2010, plus modules for Bricscad 9 and 10, which also supports registry demand loading.
To use the stub modules, just rename them so that the base filename matches your application's main LISP filename, then install them in the same folder as the LISP file and create the registry demand load entries. The only work you have to do is to get the stub module to load. You can simply drag and drop the appropriate stub module into a running instance of AutoCAD in order to test it.
Creating the demand loading registry keys is not difficult, but it may require some programming. I write custom actions for my installation programs that enumerate all installed AutoCAD versions and flavors, and set up the demand load keys for every one. However you do it, the final result should look something like this (for AutoCAD 2010 on my system):
In this screen shot, I created an application called "!LspLoadTest" (the "!" was added just so it displayed at the beginning of the list). I added the minimum required subkeys. The LOADER string value is set to the complete path of the stub module, and LOADCTRLS is set to a value of 2, which means I want the application loaded when AutoCAD starts. LOADCTRLS is a bit coded value; for use with LspLoad, it's only useful values are 2 or 4. A value of 4 means "load when my command is invoked"; this mode requires a COMMANDS subkey that lists the defined commands.
The way it works is very simple. In the example above, you can see that I renamed the module (but left the ".18.x64.arx" so that I can tell it apart). I then added !LspLoadTest.lsp to the W:\LspLoad folder. That file contained the following:
(princ "\nThis test file loaded from ")
(princ (if GetPathOf!LspLoadTest (GetPathOf!LspLoadTest) ""))
(princ)
Now when I start AutoCAD 2010, I see on the command line:
This test file loaded from W:\LspLoad\
These files are free to use for any purpose. Have a great holiday, everyone!
Labels: AutoCAD, Bricscad, ObjectARX, programming
About Me
- Name: Owen Wengerd
- Location: Apple Creek, Ohio, United States
I'm a starving artist specializing in the programming genre. I work in my home office, where I am the owner and sole proprietor of ManuSoft as well as the President and chief software artist of CADLock, Inc.
Syndication
Archive
December 2006January 2007
March 2007
April 2007
May 2007
June 2007
August 2007
September 2007
November 2007
December 2007
January 2008
February 2008
March 2008
April 2008
May 2008
June 2008
July 2008
August 2008
September 2008
October 2008
December 2008
January 2009
February 2009
March 2009
July 2009
August 2009
September 2009
November 2009
December 2009
January 2010
March 2010
Recent Comments
:Owen,
You make some good points about the importance of "the struggle and adventure of discovery" (and I agree with you there), but what I'm hoping is that Google will expand the boundaries of what we know, so that new discoveries are of things that are outside the boundaries of what is commonly "known". You shouldn't have to struggle to relearn what everyone else knows.
@ January 17, 2010 2:48:00 PM EST
Owen Wengerd:I would not give Google credit for actually expanding the boundaries; I think people do that. I don't doubt that the commoditization of information can help move the starting blocks forward and make new frontiers more accessible. I wonder, though, if that dynamic doesn't also thin the ranks of explorers. Does today's generation take information for granted?
@ January 17, 2010 4:38:00 PM EST
Deelip Menezes:Owen: "I wonder, though, if that dynamic doesn't also thin the ranks of explorers."
Probably not. As in your case, you used knowledge/technology existing at that time and built upon it. If you had to sit and create each and every component that you found from scratch instead of picking of off the shelf, you may not have reached far. Similarly, the information on the web helps prevent the need of reinventing the wheel. But I don't think that makes us any less inquisitive about what we can do with that information.
If anything, the web has changed the way we solve problems. Previously we had to solve them ourselves. Now we do with along with others. I constantly use Google to find me bits of code. But that does not stop me from creating a new algorithm when I cannot find what I was looking for or am not happy with what I have found.
@ January 18, 2010 4:56:00 AM EST
:I don't think we need to worry that much, because Google isn't the panacea you've characterized it as.
The solutions to many of the problems I come up against while programming are not easy find, even with the 'search engine' that is dumb enough to serve up links pitching the sale of hemorrhoids (yes, it wasn't that long ago that typing that word into Google's search box would result in all manner of sponsored links with titles like "buy hemorrhoids online", "best prices on hemorrhoids", etc.). More recently I think they've fixed that, but it was great for a good laugh while it lasted.
I often find myself stymied by the results of Google searches, and think that's mostly a result of what we might call 'Google scraping' (although some might liken it to bottom-feeding), which are the seemingly countless number of 'content replicators' that do little other than replicate the content of resources like public newsgroups and so on, and merely redisplay that content along with lots of advertising.
The web sites that do that exist solely to get their advertising in front of Goggle users, and collectively make Google far less ueseful than it might otherwise be.
@ February 1, 2010 1:30:00 AM EST
:Owen, great story, I once set up a (I think it was) 555 timer in a match box with an led to make it blink..... spent hours figureing it out....
I recently heard a radio show talking about an experiment they did with kids, something about find a certain presidents birthday and something else about him..... The overwhelming majority of the kids failed as after looking at a couple pages of google results they came to the conlclusion the information did not exist and gave up. Sad for sure. I am sure the next thing on their minds was "whats next?" I think we have entered into an age where we do not know exactly what affects the current technology will have on us and our future. I think, and this is only my opinion, that imagination has (is going) gone out the windonw in exchange for millions of methods and sources of visual, and experiential stimulation. What this is doing for the future of science and technology is scarry. Just my thoughts.
I say this based partly on my own personal experience with programers, designers and social entrpeneurs. When faced with a problem how many people say "how doe we solve this" and how many people say "lets look up the solution on Google".... While we are teaching increasingly high levels of computer "classes" that is I mean more classed, not more in depth classes, we are not teaching our kids to think, to understand and to be inventive...
@ February 7, 2010 9:32:00 AM EST
:Very nice Christmas present Owen .. Thanks !!!
Regards
Kerry Brown
@ December 24, 2009 7:31:00 PM EST