|
Thank you very much, Jdunlap, for your assistance....
BTW, I like your signature, "You must be the change you wish to see in the world." - Mahatma Gandhi
|
|
|
|
|
Brian JR wrote:
Thank you very much, Jdunlap, for your assistance....
You're welcome.
Brian JR wrote:
BTW, I like your signature, "You must be the change you wish to see in the world." - Mahatma Gandhi
"Blessed are the peacemakers, for they shall be called sons of God." - Jesus
"You must be the change you wish to see in the world." - Mahatma Gandhi
|
|
|
|
|
Okay, I did not realize that DirectShow was not part of the SDK. To be honest, I hadn't had a chance to dig in it much yet even though I installed it way back when 9.0 was released ( no time  )
However, you don't need to use mix mode. If someone has created a typelib, just create an interop assembly (either using VS.NET or the tlbimp.exe utility, part of the .NET Framework SDK) and use the assembly like any other. This way, you can keep it all in C# and not mess with mixed mode in MC++.
Reminiscent of my younger years...
10 LOAD "SCISSORS"
20 RUN
|
|
|
|
|
Oh God... thanks so much.... I just want to decide on a method.... because there are so many.... one method is to use this "type library"... another method is to write "wrapper classes"....
Here's the type library that I found:
http://www.kohsuke.org/dotnet/directshowTypelib/
I imported the *.dll file as an additional reference into my project. At that point I could examine the objects contained within. Is this what you mean?
What is an interop assembly? All I have is a *.tlb and a *.dll file from that link above. How are these related to interop?
Brian
|
|
|
|
|
You don't actually need the TLB file. The DLL is a .NET assembly that contains classes, methods, propertie, structs, enums, etc. that interoperate (interop) with COM. These DLLs do not contain the implementation, though, just as the TLBs don't. So you still need DirectShow installed on a user's computer. The CLR will create a Runtime Callable Wrapper (RCW) around the DirectShow COM controls automatically when you use the classes just like any other .NET classes from the BCL (or other libraries). Just use the DLL like any other assembly and don't worry about the details - the CLR does this for you. Reading about them is educational and is something you should do if you want to understand (and even good developer should understand what they're getting into).
Similarily, .NET controls can be exposed to COM through interop. In this case, the CLR creates a COM Callable Wrapper (CCW) around the .NET object so that it looks like a COM object. Nick Parker has a great article on CP about it, and I have one that goes into more details, even into bridging Java and .NET together with C++ using COM and JNI. It gives some in-depth details, but Nick's is better for understanding the concepts (make sure you read the comments, though, there was a few things I added to the article).
There's some good information about this on MSDN as well.
Reminiscent of my younger years...
10 LOAD "SCISSORS"
20 RUN
|
|
|
|
|
I want to thank you for your responses... it's so difficult to get confirmation on ANY concepts because none of my friends are programmers... everything I learn is through trial and error and reading...
Could you tell me the difference between using C++ wrappers and using the type library in C#? I just want to stick with one method, but I don't understand the intricate details of both approaches... which method is easier to use for a beginner? Which is easier to debug? Which method is "managed" and which is not?
I just need pointers as to what I should do and why... the why is very important.... I can figure out the details myself...
Thanks,
Brian
|
|
|
|
|
The best thing I can tell you to do is reprioritize your learning. I, too, am self taught, dating back to the early 80's, and much of it was spent reading stuff on gopher and then the Web (I've never personally been a big fan of books, but most people swear by them). So, read first, then do trial and error. Most people don't even bother to read and end-up relying on IntelliSense (or the like) and using the few classes they know over and over, or reinventing the wheel. The .NET base class library is full of useful classes and knowing at least most of them is important to knowing what you should use and when. Knowing how to read IL (that which all ".NET languages" compile down to, so don't worry about the source language when people state it what a library, for example, is written in) is also handy, but there are several tools like .NET Reflector[^] that let you see how things work. This can also be extremely handy and gives you ideas on how to design your projects to be flexible by being modular and supporting all the right interfaces so they can be used in anything (this practice is what I value above any coding practice, but that's of a personal nature).
So, the best thing I can do is to tell you to read about Interop[^] in .NET. This gives some great explanations about how the CLR (that which JITs and executes IL - not a specific language like C#, VB.NET, etc) creates CCWs and RCWs for COM and the Runtime to call. There's even some pretty good diagrams.
Basically, though, the difference between C++ wrappers and COM interop are the following points:
- C++ wrappers you actually have to write and compile into a separate DLL.
- IF you use P/Invoke, you're often left with marshaling problems and having to practically recreate most of the Win32 API that you're going to use.
- COM interop uses existing typelibs (contains type information about COM objects written in a DLL, OCX, etc.) and creates an assembly that contains all that information.
- The COM interop assemblies allow you to get COM type information, where as with C++ wrappers you only get type information about the C++ wrapper itself, and not the underlying code.
- COM interop assemblies can be created as easily as running tlbimp.exe with a couple parameters, or simply including a reference to a COM typelib in your project in VS.NET.
There are many other great uses for COM interop, but the important thing to remember (what most people forget, and what Microsoft doesn't even bring-up in documentation) is that you should still follow COM practices when create .NET classes that will be exposed to COM. That is, don't use auto-generated class interfaces of any kind - make your own so you have complete control over what's included and in what order in the VTABLE (and with what DISPIDs), and never change an interface once you've released your code - make a new interface with a version identifier (just like you should in COM) and implement that interface as the new primary class interface (again, just like in COM).
I hope that gives you some pointers. Just make sure you put research first and know your environment - both the Framework and knowing how to get the most out of your IDE or SDK tools (being able to use the SDK tools without an IDE is also important, I believe).
Reminiscent of my younger years...
10 LOAD "SCISSORS"
20 RUN
|
|
|
|
|
Heath Stewart wrote:
C++ wrappers you actually have to write and compile into a separate DLL.
Heath Stewart wrote:
The COM interop assemblies allow you to get COM type information, where as with C++ wrappers you only get type information about the C++ wrapper itself, and not the underlying code.
Heath Stewart wrote:
you should still follow COM practices when create .NET classes that will be exposed to COM
Heath:
I don't know how in the world to thank you enough... just those three quotes above are worth so much to me... I feel as though I can seriously stop searching for a "method" and start researching and coding, like you've rightfully pointed out...
You're not by any chance from Ontario, Canada, are you? 'Cause I'd take you out for a beer... or juice... or water... or whatever you drink!
|
|
|
|
|
Glad to help. Being a COM and .NET developer really helps and I'm glad I can pass it on. Good luck!
(And while I appreciate the offer for beer (of course  ), I live in Iowa. Thanks anyway!)
Reminiscent of my younger years...
10 LOAD "SCISSORS"
20 RUN
|
|
|
|
|
Heath... you deserve a Nobel Prize for helping so many people... I just noticed you respond to quite a few bewildered people in this forum!
|
|
|
|
|
hey,
looks like you figured it out. I tried the same thing but got stuck. I downloaded the DirectShowLib.dll from http://www.kohsuke.org/dotnet/directshowTypelib/ and integrated it into vs2003 but I can't access the functionality somehow. I know the dll doesn't contain the implementation, so how can I access the functionality? Can you give me an advice?
Sorry if my questions are to stupid, I'm very new to this and I just try to get a look insight.
Thanks a lot
Alex
|
|
|
|
|
I've been trying to install a small dot.net db client application on Windows XP but without success.
I did it several times on many computers and OSs and... it worked perfectly.
But now I have a very strange error...
I installed Oracle 9 client (I use Net8 protocol in my application).
I installed .Net Framework (ver. 1.1, size: 23 MB), next I installed MDAC (ver. 2.7).
I copied the application on the PC's hdd and I tried to run it, but this messages appeared:
----------------------------------------------------------------
Aplication has generated an exception that could not be handled.
Proces id=0xee0 (3808), Thread id=0xeac (3756)
Click OK to terminate this application.
Click Cancel to debug the application.
----------------------------------------------------------------
When I click , the message appears:
----------------------------------------------------------------
Registered JIT debugger is not available. An attempt to lunch a JIT debugger with the following command resulted in an error code of 0x2 (2). Please check the computer settings.
cordbg.exe !a 0xee0
.......
----------------------------------------------------------------
What's goin on?
I received this kind of message for the fist time (I installed several copies of my application on Win 2000, NT and XP earlier and everything was working fine! I'm sure that the code is fine - I use C#)
I would be grateful if anyone could show me what I'm doing wrong.
To be quite truthful I completely lost the idea where the problem might be...
Many thanks for help in advance.
misiek
|
|
|
|
|
You're program is generating some exception that the framework is catching - that's the first exception. The second exception (once you click 'Cancel' to debug the application) is saying that the .NET Framework cannot find a debugger on that system. That makes sense, though, because you're not running your code on a development box anymore.
Long story short - the problem is that your program is generating an exception. Wrap your Main() code in a try/catch block so that you can inspect what Exception is being thrown, and why. Even better, you could install the remote debugging toolkit on that machine and debug it from your Dev box that has VS.NET installed.
--
Russell Morris
"Have you gone mad Frink? Put down that science pole!"
|
|
|
|
|
Thanks for your answer.
I suspected that either .Net framework or Microsoft Data Access Components had not beed installed properly on that PC.
Earlier I installed that application on several (about 20) PCs and no such problem occured.
misiek
|
|
|
|
|
Actually, if this happened when you're running the application, more than likely the .NET Framework is either not installed or not installed correctly. If an exception occured in the .NET application itself, the message would be different. This is Windows's default Dr. Watson (or whatever name they give it these days) message. Basically, the VC runtime doesn't understand the PE/COFF executable format. These formats have references to the VM that runs them, like VB (non-.NET) and .NET assemblies.
Also, remember that the language doesn't matter, except in the case of certain language interoperability issues (NOTE: not COM interop - just language interop). MC++ has some language-specific assemblies to allow developers to use mixed mode and some C++ symantecs. VB.NET has a few assemblies that allow developers to use the "old ways" in some cases. These assemblies basically have some methods that older code uses wrapped into an assembly. Other than that, all .NET languages compile to intermediate language, or IL, which doesn't have anything to do with the source language. Just FYI.
Reminiscent of my younger years...
10 LOAD "SCISSORS"
20 RUN
|
|
|
|
|
To test if any application can work in (the mentioned above) .Net Framework environment, I wrote a small application (just a form with one button) with exception handling in Main() function.
This application is not working either and the message (exception message) is:
"System.Arithemtic.Exception: Overflow or underflow in the arithmitic operation.
at System.Drawing.Font.Initialize(FontFamily family, Single emSize, FontStyle style, GraphicsUnit unit, Byte gdiCharSet, Boolean gdiVerticalFont)
at System.Drawing.Font..ctor(String familyName, Single emSize, FontStyle style, GraphicsUnit unit, Byte gdiCharSet)
at Test15072003.Form1.InitializeComponent()
at Test15072003.Form1..ctor()
at Test15072003.Form1.Main()"
So what kind of problem it might be (.Net Framework)?
Thanks for help in advance.
misiek
|
|
|
|
|
 Hi
I have converted FOP(Java) application to J# (DotNet) after converting iam facing memory problem.Memory is keep on increasing finally Virtual memory error is coming in DotNet version but not in Java.
Any suggestions?
SivaKumar
SivaKumar
|
|
|
|
|
GC.Collect();
"When the only tool you have is a hammer, a sore thumb you will have."
|
|
|
|
|
Besides calling GC.Collection(), you might be holding on to references in objects. As long as there is a reference to an object held somewhere in your app / library, the object is in memory. While GC.Collect() forces garbage collection, it won't help if you're still holding object references. It'd be a good idea to check your code over.
Reminiscent of my younger years...
10 LOAD "SCISSORS"
20 RUN
|
|
|
|
|
Hello There,
I am looking for a solution of this problem now for weeks.
I am using VS .NET 2003 on Windows2000 SP3.
I am programming in C#.
Creating an instance of a Socket
m_socket = new Socket <br />
(AddressFamily.InterNetwork,<br />
SocketType.Stream,<br />
ProtocolType.Tcp);
results in the following message:
An unhandled exception of type 'System.Net.Sockets.SocketException' occurred in system.dll
Additional information: An operation on a socket could not be performed because the system lacked sufficient buffer space or because a queue was full
I have researched on the internet but found no useful information yet.
I do not want to connect to a host higher than 5000, and I have 3NIC's installed on my machine.
Any help is greatly appreciated.
regards,
stonee
|
|
|
|
|
any ideas?
thanks...
stonee
|
|
|
|
|
The more I work on my original idea and deeper into .NET Interop -- the more I'm confused. Maybe somebody could explain to me.
Here is the scenario:
1. Suppose I want to automatically export my Assembly to TypeLibrary, so other possible COM clients could use it;
2. I'm doing the following: from inside of assembly I'm using TypeLib Converter like that:
TypeLibConverter converter = new TypeLibConverter();
ConversionEventHandler eventHandler = new ConversionEventHandler();
UCOMICreateITypeLib typeLib = (UCOMICreateITypeLib)converter.ConvertAssemblyToTypeLib( GetExecutingAssembly(), TypeLibFileName, 0, eventHandler );
typeLib.SetName("SomeLib");
typeLib.SaveAllChanges();
Everything works as expected and TypeLibFileName after has all interfaces, coclasses and etc.
The problem is: all types in created typelibrary that are not of Primitive Types, except System.String were changed, either to become smaller in length(example: System.Drawing.Size is now just Size) or got converted, so they don't contain "." (like System.Drawing.Point is now System_Drawing_Point).
However, some of CLR types were converted to COM types, like System.Windows.Forms.Form was changed to IUnknown*.
And here I'm completely confused:
What get's converted and what is not?
How changed names ("." - "_") are supposed to be found in refferenced type libaries?
How you suppose to use those TLB files in your UNMANAGED projects if they are not complete -- by not complete I mean: there is no chance System_Drawing_Point could be found in refferenced typelibs (or maybe I'm wrong)?
Is there anyway of changing that behavior?
Maybe I don't understand some main principles here. Maybe Idea of typelib exporting is designed just for types you manually defined and therefore they are already COM complient. Or each of defualt Object types should be wrapped before being able to use it from COM? I thought that default dynamic CCW could be created for any Object derived .NET type -- and if so it's just typelib restriction or grammar errors i'm facing? But then, why "." was selected as name/class divider by .NET team if it's in conflict with typelib grammar?
Again, waiting for some help here...
|
|
|
|
|
OK, looks like I figured that out. Not elegant, but before automatically creating typelibrary, if I create a wrapper around original .NET component, enumerate all properties/methods/events and compile this wrapper -- then I could create TypeLibrary of that wrapper, which will corresponds to TypeLibrary of original object... While creating that wrapper I'm only placing alowed automation properties/methods/events in it -- so my code looks like that for methods:
foreach(MethodInfo mi in t.GetMethods())
{
ParameterInfo[] pi = mi.GetParameters();
Type type = mi.ReturnType;
string sType = type.ToString();
if(sType == "System.Void") // Could I determine Void without string comparison???
sType = "void";
if(sType != "void")
{
// I'm skipping here return types causing trouble:
if(!type.IsClass && !type.IsPrimitive && !type.IsInterface)
continue; // bad automation method
}
........
bool bExclude = false;
for(int i=0; i
|
|
|
|
|
The TLBEXP tool is for exporting types from a .NET assembly to COM. You should use REGASM to register your assemblies for COM while you're developing (or tick the 'Register for COM Interop' box in the IDE), and select the appropriate option (which I currently forget) in the deployment project for the assembly.
The purpose of the type library is to allow COM clients to know what classes, interfaces, methods and other types the assembly exposes. This is used by scripting engines at run-time, and VB6 at design and compile time, and also run-time if you use the VB6 Object type.
The COM Callable Wrapper (CCW) is an object which the framework generates that looks like a COM object externally, with COM-compatible types. This is a stub translator which marshals the types from COM formats (e.g. BSTR) into .NET compatible types, then calls the .NET method.
To go the other way, for a .NET assembly to call a COM object, the runtime generates a Runtime Callable Wrapper (RCW). This is a proxy for the COM object which again translates types from .NET to COM-compatible formats.
Shameless plug: we've used this with our Meteor[^] product (a system for allowing thin-client hand-held data capture terminals to run an application on a Windows server) to allow development in VB.NET, while the server software itself is written in VB6. Most new applications we're writing are now in VB.NET.
--
Mike Dimmick
|
|
|
|
|
So: what are you trying to say?
My complain and the problem was very specific: and exactly:
why not all CLR implemented and possibly exposed to scripting types are of Automation types?
For example: System.Drawing.Size is declared as struct -- therefore it cannot possibly participate in any functions calls through Automation either as a return value and/or argument -- therefore all CLR functions that use System.Drawing.Size will be visible to COM client, however will not be accesible through Automation (I mean IDispatch access)...
And it's not just Size: Have a look just in System.Drawing namespace:
Point, PointF, Rectangle, RectangleF, Size, SizeF... It's alot?
So, how in the world could you access them through "VB6 Object type" you are reffering?
Example: How you gonna call Control.Invalidate(Rectangle) from your script if Rectangle is not of automation type???...
Regards
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
