C# Discussion Boards - CodeProject

System.Diagnostics.Process.Start

20-Jan-04 5:30

There is no build-in support for this in the .NET base class library (BCL). This actually requires a lot of COM and native functions. Your best bet is to consult the Windows Driver Development Kit (DDK). Essentially, each device class has an associated CLSID for the property pages it supports. The client application creates a property sheet, adds-in default property pages for all devices, and queries the device class for additional property pages to include, similar to how shell property page extensions work, except in that case default property pages are added and the file's associated property sheet handlers are queried.

The Platform SDK does contain some information about this, but the DDK will provide much more specific information about device property sheets.

elena1234520-Jan-04 4:22

elena12345

20-Jan-04 4:22

I am trying to bring up a directory in the Windows Explorer.

System.Diagnostics.Process.Start("Explorer.exe") brings up Windows Explorer just fine

System.Diagnostics.Process.Start("Explorer.exe", dirPath) brings up the directory in a regular window (with no folder tree on the left)

How do I get the directory to come up in Windows Explorer?

Thanks,

Elena

Re: System.Diagnostics.Process.Start

Heath Stewart20-Jan-04 4:36

20-Jan-04 4:36

Process.Start("explorer.exe", string.Concat("/e,", dirPath);

If you want the directory to be the root of the explorer window, use "/e,/root," instead of just "/e,". See http://support.microsoft.com/default.aspx?scid=kb;en-us;152457[^] for more information and options.

COM Interop

Ungi.20-Jan-04 3:47

20-Jan-04 3:47

I have a big Problem:

I want to use a OCX in my C# Application.

To achive this I used the Project/Add Reference... menu and browsed for the Component in the COM Tab.

There are no problems on viewing the component in the Object Browser or to instance any class of the component. But if I try to call a method or set any property of any instanced class I get the following error:

An unhandled exception of type 'System.Runtime.InteropServices.COMException' occurred in mscorlib.dll
Additional information: Catastrophic failure

Does any one of you know, what that could be?

Heath Stewart20-Jan-04 4:24

20-Jan-04 4:24

Could be many things. If you're not running the application on the same machine, make sure the target machine has the OCX and any of its dependencies installed (making sure that its dependencies are installed is required on the development machine as well). The threading model of the COM control might be a factory, too, but since the extension is OCX I'm guessing you used VB to create it and could never stomach getting deep enough into it many years ago to know if you can control the thread model.

To better assist you, could you perhaps post a short code snippet of how you're instantiating the control and calling the method?

Also, the object browser only views Type information. If you want to test the initialization of the control without factoring in your code (not saying that you did something wrong, but you must eliminate that possibility first), use the ActiveX Control Test Container, which should be in your tools menu. Add an instance of the control and try running a few methods on it to make sure that it's working correctly.

Ungi.20-Jan-04 18:04

20-Jan-04 18:04

Thank you for your answer!

The component is running on the same machine.

The threading model could really be a factory. A colleague created the component with C++/MFC. What could there be a problem?

I instance the class like:
MasDspMetadata.MasDspClass mMasDsp = new MasDspMetadata.MasDspClass();
mMasDsp.Connect (strHostname,dPort,dTimeout); //raises the error

With the ActiveX Control Test Container I have no problems on calling methods.

Heath Stewart21-Jan-04 3:42

21-Jan-04 3:42

It doesn't really matter in what language a COM component was written, so long as the runtime for the language exists on the target machine, so it wouldn't be a problem if it was written in MFC (in fact, most components are written in C++, of which MFC is just a wrapper).

Take a look at tlbimp.exe in the .NET Framework SDK. It imports a typelib to an interop assembly (Runtime Callable Wrapper, or RCW). Perhaps by manually creating this assembly you can set some additional options. If this is an ActiveX control, you can also use aximp.exe to not only generate an RCW but also the source that would be compiled. I'm wondering if that string parameter (judging by your Hungarian notation) isn't being marshaled correctly. Remember that strings can be either ASCII or Unicode, and that Windows only natively supports ASCII (as opposed to Windows NT, which uses Unicode but can use ASCII). You can control how the string should be marshaled using the MarshalAsAttribute (see docs for details). If the MFC COM component only handles ASCII or Unicode, you should use UnmanagedType.LPStr or UnmanagedType.LPWStr respectively. If the guy built two COM components for Windows and Windows NT and they both support native strings, then you can use UnmanagedType.LPTStr.

The only other thing I can think of is the threading model (a factory merely creates components). Is this single-, apartment-, or free-threaded (or both latter models)?

Ungi.21-Jan-04 20:23

21-Jan-04 20:23

I tried to use tlbimp before and it took the same error.

I don't think that it is an error on marshalling because the same error is raised if I call a method with no arguments or if I want to set a property of the class.

Perhaps something on threading... Will try to get more information.

Thank you very much for your help!

GOT IT!!!!

Ungi.28-Jan-04 2:14

28-Jan-04 2:14

http://support.microsoft.com/default.aspx?scid=kb;EN-US;146120

how to avoid references

Mephisto18720-Jan-04 3:44

20-Jan-04 3:44

I want to use a dll without manually adding a reference in the solution explorer. Is there any way to do this ?? Something corresponding to the good old "import" maybe ???

Heath Stewart20-Jan-04 4:17

20-Jan-04 4:17

An assembly cannot reference a Type if the assembly in which that Type is defined is not loaded. This is no different than any other platform. Even #import requires that a typelib exists on the machine (and running the code requires that the libraries containing the types defined in the typelib are present on the system).

Once an assembly that is required is referenced by your project, you can use using SomeNamespace; at the top of your source file, preventing you from having to type the namespace for a class each time, but the project still needs to have the assembly loaded that contains the definition for the Type you want to use.

Mephisto18720-Jan-04 4:54

20-Jan-04 4:54

I totally agree with you, but that´s not the point Confused | :confused:

The studio can create references to any registered component on the system. So I´m sure there is a way to do the same !?

Heath Stewart20-Jan-04 5:26

20-Jan-04 5:26

What do you mean, "The studio can create references to any registered component on the system."? Your project needs to reference the assemblies required by your project, period. When you add components, the assemblies in which that component and its dependencies are defined are added automatically if they aren't added already, but only when you use the designer. If you manually type the code, it does not do this automatically. It's all because of the designer.

If you're talking about the assemblies that show up in the Add Reference dialog, you can add additional directories in which to search in the HKEY_LOCAL_MACHINE\Software\Microsoft\.NETFramework\Assembly folders key.

If you don't want to worry about where assemblies are located (even though VS.NET will copy assemblies to the application directory that aren't installed in the GAC), you can use gacutil.exe to add assemblies to the Global Assembly Cache (GAC), or drag-n-drop the assemblies into the %WINDIR%\assembly directory.

This is no different than any other language or platform, as I said before. In Java, the classes or JAR files have to be in the CLASSPATH when compiling or running the application (you can override the CLASSPATH on the command line, though). In Win32, libs must be linked in when compiling and the DLLs must either be in the application directory or in a directory in the PATH environment variable. In linux, the shared objects must be in a lib directory configured in the SO cache. With COM, a CLSID is used but that CLSID must be registered on the system, in which case the path to the file is specified in the registry, or a file can be referenced that is already in a PATH directory (though not recommended).

That's just how everything works. The only assembly that doesn't show up in the references is mscorlib.dll, which is implied by the compiler unless overridden (possible in the VS.NET 2003 C# project properties, or using the command-line compiler since .NET 1.0 (v1.0.3705)).

Mephisto18720-Jan-04 22:12

20-Jan-04 22:12

Ok, thank you for your detailed describtion !!

In my case it´s a com dll I want to load by manually typeing the code (that´s why I was talking about registered components). The reason is that I don´t want that people, using my code in their own projects, have to care about the references I need. I want to enable my code to collect everything it needs on it´s own.

Heath Stewart21-Jan-04 3:46

21-Jan-04 3:46

Sure you can redefine the COM interfaces you require in your source, but you have to worry about instantiating, casting, marshaling, and more. Using tlbimp.exe or aximp.exe to create a Runtime Callable Wrapper (RCW), or interop assembly, is much easier. Besides, whether or not other developers use that interop assembly is moot - they can just as easily create their own! Remember, an RCW isn't the COM object - thus containing the code - itself, but just a wrapper. So long as that COM object is installed on the target machine, anyone can create an interop assembly from it. And there's will be no different from yours except, perhaps, differing only by the public key token if you sign the interop assembly when you create it.

Depending on the complexities of your COM object, manually defining all this stuff can be tedious, if not a waste of time.

Mephisto18721-Jan-04 5:08

21-Jan-04 5:08

Finally it works by invoking the methods on the object, created through the assembly, but I guess you are right. Compared with the two short mouse clicks you need to add a reference it´s really a waste of time.
And using the rcw wrapper class is simply much more comfortable.
Hmm.. so everything will remain unaffected, just explored a little more of the .new world Smile | :)

Thanks to all of you for your help...

Jose Fco Bonnin20-Jan-04 5:30

Jose Fco Bonnin

20-Jan-04 5:30

You can use reflection to load an assembly.

<br />
Assembly a = Assembly.LoadFrom("your.dll");<br />
Type t = a.GetType("namespace.classname");<br />
MethodInfo m = t.GetMethod("method");<br />
object o = Activator.CreateInstance(t);<br />
object result = m.Invoke(o,new object[]{parameters});<br />

If you want to avoid call methods in this way, you can also create an interface with all the necessary information about the dll and when you call CreateInstance just cast to it. For instance:

<br />
public interface IAnInterface<br />
{<br />
     void Method();<br />
}<br />
.......<br />
<br />
IAnInterface anInterface = (IAnInterface)o.CreateInstance(atype);<br />
IAnInterface.Method();<br />

Jose Fco Bonnin20-Jan-04 6:01

Jose Fco Bonnin

20-Jan-04 6:01

I type mismatched the last line

should be "anInterface.Method();" instead of "IAnInterface.Method();"

it was evident but .....

Mephisto18720-Jan-04 22:28

20-Jan-04 22:28

In fact I´ve already tried it the first way, but didn´t know how to call methods on my created object. Simply connecting an interface pointer to my object never worked...

The second way seems to be pretty smart, so I will try something like that.

Thanks for your inspiration !!!

Heath Stewart21-Jan-04 3:24

21-Jan-04 3:24

You cast the object that you get from Activator.CreateInstance to whatever class or interface it is. The assembly still has to be resolvable by either being in the application directory, a private path, the Global Assembly Cache, or by an implementation in your handler for the AppDomain.AssemblyResolve event. If the assembly can't be found that contains the Type, you'll get a TypeLoadException. Note that there is a significant performance issue using this over direct instantiation.