I have two assemblies, X and Y. Y defines a class X.Foo X references Y. In X I have the following: System.Type t = System.Type.GetType("Y.Foo"); This fails. If instead I write: System.Type t = System.Type.GetType("Y.Foo,**Y**"); it works. I was expecting that the explicit assembly specifier should not be required given that I am referencing the assembly allready. Can somebody explain the subtleties of GetType in this situation? cheers, -=jarl=-

Can someone please point me towards resources on how to use Microsoft COM objects from a Java app ? -=jarl=-

Thank you very much! -=jarl=- Laird Of Glenmore

I hope this is my last MC++ newbie question for a while... ( btw, thanks to previous answers I've got my cross platform, C++ & MC++ agnostic threading code running. Thanks! :) ) Is there any way to use templates for subclassing with managed classes ? As in; template<typename T> struct foo { ... }; ... __gc class bar : public foo<bar> { ... }; ..which doesn't compile. Adding a __gc to the foo-template doesn't help either. So, is there any way to do this, at all ? cheers -=jarl=-

...ah....I see...;P -=jarl=-

Ok, thanks! -=jarl=-

Ok, yes, I am waiting impatiently for my books, so in the meantime I'm abusing the nice people at CodeProj... ;) Ok, you've answered my question; You can only contain a managed structure in another managed structure. cheers -=jarl=-

Is this; void bar( data_struct_t * structure ) { stuff_handle_ = GCHandle::Alloc( structure ); data_struct_t * tmp = static_cast<data_struct_t*>(stuff_handle_.Target); tmp->data_ = 1; } effectively as safe as, or the same as, this ? void bar( data_struct_t * structure ) { data_struct_t __pin * pinned = structure; pinned->data_ = 1; } -=jarl=-

..sorry, the question wasn't really in there now, was it...? my question is: why doesn't this work ? ...I have feeling I might have asked a completely stupid question here.... ;P -=jarl=-

I think this overlaps somewhat with the general problems people seem to have with mixing C++ and MC++ code when pointers enters the equation, but anyways, here it the problem: I have an unmanaged struct like so: __nogc struct foo { int data_; }; and then I have a managed struct like so: __gc struct bar { foo is_this_unmanaged_still; }; And...this doesn't compile. : error C3633: cannot define 'is_this_unmanaged_still' as a member of managed 'bar' I don't have my MC++ books yet, so excuse me if this is a bit of a naff question, but I am in the middle of porting some C++ code to be cross-C++/MC++ compatible and these little diddlers are causing me some immediate headaches...;P cheers -=jarl=-

inline might be your culprit... -=jarl=-

We have been using this sort of setup for a few years now, and it is very usefull indeed. In fact, we usually have more than just debug,release and the one you call "rebug". We also have Debug Optimised, ( "Derel" ? :) ), which is the full debug-build with optimisation turned on. When you have something which only crashes in release, it can be good to go backwards towards the normal debug build through these two extra targets. The only problem with the scheme is that multiple configurations like these are poorly supported by VC...well, at least VC 6. It's a hassle to maintain and there are bugs which will mess up your configurations when you alter options in the menus. The configuration manager in VC 7 seems better. -=jarl=-

I am almost willing to bet that it is because you haven't specified /Mt or /Mtd, ( or whichever it is for your version of VC ), to enable multithreading. The Microsoft headers have a nifty ( not ;) ) set of defines which undef the multithreading functions if the _MT define, ( which comes through the /M... compiler switches ), aren't set. -=jarl=-

aaaarghhh....i hate this... the < typename T > bit keeps getting lost in the wash.... oh well, we now know what we're both trying to say. :) -=jarl=-

...right, so reading, my reply again I realise that it might not be entirely clear....;P What I was trying to say was; Member function templates are poorly supported by VC 6 Member function templates are supported by VC 7, however... Member function template specialisation is not, ( not properly, anyways ), What you are trying to do, ( splitting template declaration and definition into separate files ), is the subject of the mysterious export keyword, which for numerous reasons has been deemed a red herring. Unfortunately (?), the only solution is to keep the declaration and definition in the same header file. If you want to make sure that the linker has a single instance of a template somewhere, ( and not rely on client code usage patterns ), you can instantiate it using the template keyword on its own, like so; in some cpp files somwhere... template MyTemplatedClass; this will generate all the code for MyTemplatedClas in the cpp file for the linker to use. HOWEVER....this doesn't work for template member functions, only for the whole class, ( or perhaps for free functions. ) So...'tis a bit messy... -=jarl=-

Firstly, the declaration you have there is not correct. ( or is it just formatting which removes the < typename T > bit ? ) Anyways, ( assuming it is not ), to declare a template member function you have to do this; in header: template< typename T > void MyFunction( T& ); ... template< typename T > void MyClass::MyFunction( T & param ) { ... } The point is that you can't define a templated method outside of the header-file where it is declared. ( The compiler might not complain, even 7 doesn't, but the linker looses it... ) Secondly, this will only partly work if you have anything earlier than VC 7. VC 6 will do it, however it might fail silently on certain cases which can cause you grief later. ( In particular if you try to specialise the member templates ) -=jarl=-

I'll go an shoot myself now.... This is just too stupid..... I had a name...a const char*...and I used it...twice....and you can all figure out the rest from there and tell me I'm a monkey...thanks, I knew that... X| oh...well.. -=jarl=-

And, the one thing which annoys me the most, is the knowledge, ( or assumption ), that there is going to be some exceedingly stupid thing somewhere which is causing this... X| Anyways, let me get on with isolating this in some form or other so that I can share my grief in a more concrete form. :) cheers! -=jarl=-

Actually...there is a concrete problem here.... I have threads A, B, C and D and signals 1, 2, 3 and 4. A waits for 1, B for 2, C waits for 3, D for 4 I set signal 2 from thread A and....C wakes up! This is why I would like to be able to know for certain that signal 2 is actually set. (From the windows kernel's point of view ) Currently I have a debug-info structure stored with each signal, and set/reset/create/wait wrappers which update this information. Such as; waiting-thread id number of waiting threads, ( is allways 1 in this case ) id of thread which last set this signal id of thread which last cleared this signal etc. Imagine my frustration.... I know for certain that the two signals 2 and 3 are distinct. I know for certain that C is waiting for 3, ( and not for 2 ). I know for certain that I am going mad. Any ideas, inspirational thoughts, haiku's or anything such which might give me a push in the right direction would be much appreciated. p.s. Signal = Event, in Windows speak p.p.s ProcExp from the Sysinternals homepage doesn't do what I need. I am concerned now that I have found out that the Windows Native API doesn't have any methods for monitoring signals... -=jarl=-

ah......hello there! :cool: Ok, I'll check out sysinternals... ;) No, can't do. Nope. Nada. No-one does it right...( however, if I was evil overlord.... ) Well, actually, I used to work for a company which had their own "os" which supported multithreading on a host of platforms. They had an internal suite of tools which provided such things as; - global signal monitoring - signal/mutex/sem usage logging - priority inversion workarounds that worked... - break on set/reset - break on multiple threads waiting on same signal etc. Since the "os" was custom, ( based on the Amiga OS, will you believe it...? ), this was possible. I think Microsoft and its brilliant programmers...( cough ;) ), should be able to provide the same.... Anyways...moving on.... :-D -=jarl=-