|
Jammer wrote: I'm just doing some debugging using this tool. Its dead easy to view the contents of a DataSet using the native VS visualizer but where is this in Mole ... what path through the objects and properties do you walk to get a view on the actual contents of a DataSet?
Why not ask this on the Mole forum? Karl and Josh never sleep - they are gods who do not need such mortal things, so they will pounce on the question like an asthmatic hyena.
|
|
|
|
|
Ahhhhhhhhhhh!! I didn't even see the mole forum! sorry!
hmm ... i need more sleep!
|
|
|
|
|
Hmm ... no wonder I posted it in here ... where on earth is the mole forum?
|
|
|
|
|
Jammer wrote: where on earth is the mole forum?
Here[^]
|
|
|
|
|
Pete O'Hanlon wrote: pounce on the question like an asthmatic hyena.
Interesting visual...somehow it fits rather well however. 
Scott.
—In just two days, tomorrow will be yesterday.
—Hey, hey, hey. Don't be mean. We don't have to be mean because, remember, no matter where you go, there you are. - Buckaroo Banzai
[ Forum Guidelines] [ Articles] [ Blog]
|
|
|
|
|
Scott Dorman wrote: Interesting visual...somehow it fits rather well however.
Thanks - I was kinda proud of that one. It just seemed to flow.
|
|
|
|
|
I am looking for a way to launch an application inside a window in my applicatin. Specifically I wan to to open a command propt window with a window container in my application. Is there a way to do this, preferably in c#.
Thanks in advance
|
|
|
|
|
Joseph Weisenburger wrote: Is there a way to do this
Not the way you are thinking about it no. If you knew the first thing about how the Windows OS works you would know that.
What you could do, and even this is a giant hack, is spawn the console process and capture it's output by hooking the processes output stream. Then you can read from the stream and display the data in a window in your application.
And no, I'm not going to give or send you sample codes even though it's urgent so don't even ask. The Microsoft MSDN Web site [^]provides all sorts of examples and articles and documentation. There are also many many articles with example code here on Code Project. Go find them.
I am also not going to try to teach you programming fundamentals using text based communications. Get a book, take a class, whatever but don't try to learn how to be a software developer by asking questions on forums. It takes long enough to gain any level of proficiency doing it in a more traditional fashion.
led mike
|
|
|
|
|
Pre-emptive. I like that.  Saves time later.
|
|
|
|
|
Can't you tell from my total post count that I am concerned about conserving CP resources? 
led mike
|
|
|
|
|
|
Giorgi Dalakishvili wrote: Is this what you are looking for: Window Tabifier[^] ?
#region signature
my articles
#endregion
Yes, This is very helpful. Thank you.
|
|
|
|
|
Glad to help you
|
|
|
|
|
I have a .Net (2.0) assembly that I want to call using a Com client (a VB6 program) on another machine. I don't need it to be strong-named or in the GAC - the assembly will be in the same directory as the Com client.
So, based on various examples from googling, MSDN, etc., my process has been:
1. Make sure that the assembly [call it MyAssy.dll] has ComVisible
attribute set, and use both an interface and a class that implements the
interface.
2. Make sure that the assembly, the interface and the class are all
decorated with GUID attributes, and the Interface also has a ComVisible =
true attribute.
3. Build the .Net assembly.
4. On the .Net machine, regasm MyAssy.dll /tlb:MyAssy.TLB. This succeeds,
and I copy both the dll and the type library to the VB6 machine with .Net
2.0 framework installed.
5. Again, regasm MyAssy.dll /tlb:MyAssy.TLB (with correct paths everywhere.)
6. Open the VB project and add the reference to the type library. In the VB6
project I can now see the class and Intellisense shows me all its methods.
So far so good.
7. However, when I try to compile, I get Run-time error -2147024894
(800700002) Automation Error - Cannot find the file specified. The error
occurs when I instantiate an object from MyAssy.dll
The GUIDs in the registry appear to match the GUID for my class and the Type library. I have numerous times removed references, unregistered, verified that the GUIDs are gone from the registry, reregistered, and many other things but have not been able to solve this problem. Even more annoying, I did a proof-of-concept of this whole process several months ago, and it worked fine, and continues to work, on the same 2 machines. The difference here is that MyAssy.dll actually wraps another .Net DLL that actually does something useful, but even when I temporarily removed the reference to the useful .Net DLL from MyAssy.dll, I had the same problem.
I've been through lots of troubleshooting posts that told me to try all of the "fixes" in the above paragraph, but no go. Any idea what might be wrong?
Thanks much,
Elizabeth C.
|
|
|
|
|
Elizabeth Connolly wrote: 5. Again, regasm MyAssy.dll /tlb:MyAssy.TLB (with correct paths everywhere.)
Have you verified those paths in the resulting registry entries?
Also the Ole View tool that used to come with Visual Studio was a great way to verify a COM components registration and even instancing it. It is now a SAMPLE and you can download it[^], build it and run it to verify COM components are accessible.
led mike
|
|
|
|
|
Yes, I did verify the paths in the reg entries and they checked out.
I will try the OleView though. Thanks for the pointer!!!
|
|
|
|
|
Try adding the /codebase switch to regasm, that adds the path to the registry of where the DLL is located. If you don't then it assumes it's somewhere in the PATH variable.
|
|
|
|
|
Aha! I will try this. I hadn't done it because I thought /codebase would only work in certain situations, but I will for sure try it and see if it works. Thanks!
|
|
|
|
|
Unless your assembly is registered in the GAC or in the system path then you need this. However don't move the DLL once you've registered it with that command because it won't be able to find it then.
|
|
|
|
|
I have a few more questions:
1) If the Com-Visible "wrapper" DLL, which is Com registered and seen by Com clients, wraps another DLL, does this other DLL also need to be COM Visible, registered via regasm /codebase, etc.? My Com DLL references another which references several others. Do all the DLLs need to be COM Visible? I thought that it was only the wrapper that had to be visible but maybe this is not the case?
2) And are there any bad side effects for other .Net applications that also consume a COM-Visible DLL (but not through Com)?
Thanks!
|
|
|
|
|
1) No, if it's wrapping it through .NET code.
2) Not that I know of, depends on how you code it mostly. Situation dependent (e.g. accessing shared resources).
|
|
|
|
|
Thanks, Ed!
I will put in some logging or something to try to figure out why the calls to my wrapper dll seem to do nothing on the com machine, but have the intended effect on the .Net machine.
Glad to hear it took you 2 weeks to get this working; I have been pulling my hair out over it since Friday!
|
|
|
|
|
THAT WORKS! You're a genius!
Now I have to debug the assembly, which doesn't seem to work, but at least I can compile!
THANK YOU!!!! 
|
|
|
|
|
Don't worry it took me 2 weeks to get that little gem working to call a C# dll in Delphi 5.
|
|
|
|
|
How do I keep people from browsing sub folders on a .net website?
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt, 1997
-----
"...the staggering layers of obscenity in your statement make it a work of art on so many levels." - Jason Jystad, 10/26/2001
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
