Ah. Glad I haven't lost my mind. Thanks for link. Deja View - the feeling that you've seen this post before.

I'm not entirely sure, but I think your problem lies in the fact that you need to produce separate static libraries built to link to the various types of run-time libraries (static and dynamic). You need to produce a library with different warts for each of the different linker options (/MD /MDd /ML /MLd ) and Unicode options if applicable.. This makes about 8 libraries you need to compile for completeness. It's a real pain... however you can make it so the users of the libraries are not too inconvenienced by using the #pragma comment(lib, _libraryName_) compiler directive. Good luck. //.ichael

You can use the Win32 resource editing trick for the version of the executable, but not the assembly. Doing this will also invalidate signature if you use signed assemblies (and you should be, especially since it makes versioning easier via config files and policy assemblies, which must be in the GAC and assemblies in the GAC must be signed). Even if you did change the version and resign the assembly, it still wouldn't be an easy task. You would have to emit an assembly based on a template (the existing assembly). Frankly, IMO, just implement a policy whereby your developers put the appropriate assembly version into the [assembly: AssembyVersionAttribute] when compiling for the last time. Or, if you have a build master, he or she could either do it (or use a macro to change the AssemblyInfo.cs file (or wherever you put it) to make it quick) and then compile under a release build. Just remember that the version number in the VersionInfo block of the executable's .rsrc section has little to no bearing on the assembly itself. The AssemblyVersion attribute is what matters, and that's in the MANIFEST for the assembly. One example: Infragistics commonly updates their assemblies while leaving the AssemblyVersionAttribute with the same value, but changes the executable image's VersionInfo block so that the FileVersion is different. While this makes updating your applications without recompiling easier, it totally screws-over touchless deployment over the Internet because Fusion (the assembly binder) caches assemblies based on their strong name in the temporary assembly cache. Since the assembly version didn't change, the new code isn't always downloaded! (The cases where it is depends on Internet Explorer's cache settings.) -----BEGIN GEEK CODE BLOCK----- Version: 3.21 GCS/G/MU d- s: a- C++++ UL@ P++(+++) L+(--) E--- W+++ N++ o+ K? w++++ O- M(+) V? PS-- PE Y++ PGP++ t++@ 5 X+++ R+@ tv+ b(-)>b++ DI++++ D+ G e++>+++ h---* r+++ y+++ -----END GEEK CODE BLOCK-----

Because "Field" property gives an object (some interface like IField or IDispatch), the VB makes some additional action. fld = "blah" This always works because the VB cannot assign the string value to the object variable. He should call some method(property) for this. And this action is a calling of property-by-default (with dispid=0) if this property is presented by the object. msg.Segment.Field = "blah" This never works because the VB will call the "Field" property of msg.Segment object with parameter which equals to "blah". It gives the compilation error because probably the "Field" property does not have the parameters. Try the following construction msg.Segment.Field() = "blah" With best wishes, Vita

Thanks Dave http://www.cloudsofheaven.org

I didn't think it was easy... The reason i wanted one was because i have two tree controls next to each other and i'm drawing lines between them - the scrollbar is sort of in the way. Dave

Seems to...well, to an extent: class Test { int x_; public: Test() : x_(0) {} template set(T t) { x_ = sizeof(T); } }; { Test t; t.set(int(3)); // OK t.set(4.0); // OK t.set(4); // Compile error :-( } i.e. explicit instantiation doesn't work - think it should do, as it does for non-member function templates. Hope this helps. Stuart Dootson 'Java, Basic, who cares - it's all a bunch of tree-hugging hippy cr*p'