June 2003 - Posts
I ran into what seems
to be a bug in AXIMP.EXE (and the corresponding process in Visual Studio .NET)
recently. I tried using one of our older, MFC-based ActiveX controls in
Visual Studio .NET toolbox. It barfed generating the interop DLLs, giving the
error "Cannot apply indexing with [] to an expression of type <classname>.
AxImp.exe generated the same error.
Looking at the generated source code for the wrapper control
(which AxImp is kind enough to keep around for you) revealed the problem. The
AxImp process generates two DLLs - an interop DLL for the types in the COM type
library (the equivalent of doing a tlbimp.exe), and a control DLL which
contains Windows Forms control wrappers. The control wrappers delegate their
calls to a contained instance of the interop type. So if you have an
ActiveX control called MyControl, two classes are generated - an interop
class MyControl, and a wrapper Windows Forms control called AxMyControl.
AxMyControl basically delegates most of its work to a contained instance of the
interop class MyControl.
Well, in this case apparently the code that generates the
interop dll and the code that generates the wrapper control disagree on how to
interpret the type library. Our ActiveX control has a property on it called
Item. The wrapper control was converting that call into an indexer (this[]) -
presumably based on the name. But the interop dll doesn't - it leaves it has
get_Item(). This seems to be because the Item property doesn't have a DISPID of
DISPID_VALUE (don't ask why, it's a weird historical quirk). If I change the
DISPID to be DISPID_VALUE, everything works.
I guess it's a pretty
obscure case, but it's a pain.
I was able to hand
edit the generated wrapper control source to get it to compile. Unfortunately, I
then discovered the second bit of silliness - if you run AxImp by
hand, it doesn't add the ToolboxItem attribute to the generated controls. It
seems that you have to add it by
hand, which isn't required when using Visual Studio .NET. That makes the
standalone tool a lot less convenient to use.
When I first saw Reflector for .NET, I though it was a nice little tool, but the VS.NET object browser handled most of what I needed.
When I first saw Reflector with the built-in decompiler, I thought it was a very cool idea, and may be useful some day.
After using it do solve a problem I was struggling with, I now think Reflector is god-like.
I was trying to figure out how an ASP.NET server control could present a drop-down list of other components on the web form (including not just controls but components in the tray as well, and in this case filtered to just those that implement a certain interface). I knew the DataGrid did it, so I knew there had to be a way, but couldn't find any information about how to do it. Even the server control bible (Kothari) didn't seem cover it.
A little Reflector'ing answered the question. First a peek at the DataSource property attributes pointed me to the DataSourceConverter. And voila, there was the answer. Right there in beautifully readable source code (goto statements aside).
That is just so freakin' cool.
If you're curious about the answer, the ITypeDescriptorContext passed into TypeConvert.GetStandardValues has a Container property. The Container has a Components collection which has all the components on the page - it's even in a flat list, so you don't need to worry about walking down the control hierarchy.
Sweet.
I recently posted two
.NET related blog entries - one on ASP.NET request validation, the other on
framework version numbers. As usual, I got a couple of comments about the posts
- no surprise there. What did surprise me was that both posts had comments
from Microsoft employees (BradA and ScottGu). Two comments about
this:
1) It's unbelievably cool that
some of the Microsoft crew are venturing forth into the community and addressing
real developer questions and issues. This is really unprecented access to people
who have both knowledge and influence.
2) Despite what some of my friends would say about the
size of my ego, I have no illusions that these guys actually subscribe to my
blog. So I'm guessing that they are actually reading weblogs.asp.net aggregate
feed. To that I can only say - wow. That's a lot of stuff to slog through, and a
big time suck. I can barely keep up with the feeds on my blogroll, never mind
the rest of them.
So hats off to those guys. That kind of stuff will
score big points in the developer community.
For some reason I had
it in my head that the next version of the .NET Framework would be 2.0. I'm not
sure why - maybe the stream of references to Whidbey/2.0 in various blogs. But
recently I've seen mention of .NET 1.2 pop up in a couple of 'softies' blogs -
but no where else. Anyone know what gives?
Is it my imagination,
or does the shuffling algorithm in Media Player 9 suck beyond belief? Of about
1200 MP3s, I feel like I listen to the same 150 or so over and over again.
Speaking of MP3
players, is WinAmp toast? It was my favorite MP3 player for years, but it seems
to be moldering.
I recently tried
running one of our web applications on ASP.NET 1.1 for the first time. This
is a sample app that we ship to customers to show them how to interact with our
web service. There's one page in the app that constructs some XML on the client
side and submits it to the server in a hidden form field. The new ASP.NET
request validation feature didn't like that too much, and threw up an error. A
quick Google pointed me at two different ways to disable this option - a page
directive to disable it at the page, and a web.config setting to disable it for
the app.
Great, I thought, I'll
just disable the check for that page. I tried the page directive on
ASP.NET 1.1, and it worked fine. I tried it on ASP.NET 1.0, and it barfed.
Apparently it doesn't like directive attributes that it doesn't know
about.
Next I tried the
web.config setting. Same deal. ASP.NET barfs on a web.config setting that it
doesn't know about. I guess MS doesn't buy into the whole "ignore what you don't
understand" philosophy of forward compatibility.
So I'm stuck. The web
app doesn't require 1.1, but I can't have the same code that works on both 1.0
and 1.1. I guess I have to just document that if they are running the app on
1.1, they need to manually edit the page and add the
directive.
That stinks.
There have been various
stories
about Microsoft pushing back the release date of Yukon to the 2nd half of 2004.
The question is, does that mean they're pushing back the release date of Whidbey
as well? Microsoft seems to talk a lot about these two releases coinciding. And
one of those articles implies this as well, but I haven't seen anything
definitive. Anyone know?
That would
suck.
More Posts