|
I have a new idea 
Now that we have the table of all simple types, and rules for structures, interfaces, enum, ... a great new little thingie would be a Marshall replace tool that takes for instance the WIN32 API method call as input in an edit box, and returns the equivalent call in managed code. Doing this, people will stop losing their valuable time wondering how to do it.
I guess that's time to explore VS.Net addins...
And I swallow a small raisin.
|
|
|
|
|
I was thinking of starting a project on converting all of the SDK headers into enums and structs and DllImported functions by running them thru a parser, but it just seems to be alot of work for one person...but if I can find a couple ppl to help, then we can do it ! 
MYrc : A .NET IRC client with C# Plugin Capabilities. See
http://sourceforge.net/projects/myrc for more info. 
|
|
|
|
|
In fact, the tools for conversion are already there. For instance, TLBIMP converts an IDL interface to a marshalled managed interface. All we need to do, when facing a WIN32 method call to be translated, is wrap it inside a fake IDL file, and launch TLBIMP.
The beauty of it is that I believe TLBIMP can be run seamlessly inside a C# app.
Once done, just launch ILDASM, it shows the marshalled managed interface.
Well, may be not everyone will agree that's simple enough ,
And I swallow a small raisin.
|
|
|
|
|
But this seems to be only for COM and not for unmanaged functions. Ideally what I want is a tool to convert any header file into static structures accessable via C#.
EG: nice.dll comes with nice.h and is NOT a COM dll, then all I need to do is run header file thru tool and TADA there is all the functions from library. It will still be up to you to implement your own managed structure implementation.
BTW TLBIMP gets autoinvoked when referencing a COM dll in a project, so it is transparent to the user .
MYrc : A .NET IRC client with C# Plugin Capabilities. See
http://sourceforge.net/projects/myrc for more info.
|
|
|
|
|
IDL is 90% a wrapper on top of unmanaged functions, that's why only a few types MAY not be translated. But you're right in the end, a nice automatic tool with no IDL sh*t at all is just as well. I am thinking about it,
And I swallow a small raisin.
|
|
|
|
|
Check GotDotNet's user submissions for one called APIViewer, it translates the API file that shipped with VB6 into C# DLL import stuff. Unfortunately it lacks a lot of stuff that came out since VB6; but its a start.
James
"And we are all men; apart from the females." - Colin Davies
|
|
|
|
|
James T. Johnson wrote:
Check GotDotNet's user submissions for one called APIViewer
Thanx James , searching for it returns 0 resluts 
UPDATE: the search page seems broken, it remembers the previous query 
UPDATE 2: still no links to it, will search and post link if i find it.
MYrc : A .NET IRC client with C# Plugin Capabilities. See
http://sourceforge.net/projects/myrc for more info.
|
|
|
|
|
APIViewer.zip (93.1 Kb)
Its in VB and it appears to be from one of the beta's but it shouldn't take too much work to get it working again.
James
"And we are all men; apart from the females." - Colin Davies
|
|
|
|
|
Compiles fine, but doesnt seem to load the header file in the viewer, i will look at it though. Also there seems to be various versions (all the same really) of this file. Dont you just hate it when people rip off code like that?
MYrc : A .NET IRC client with C# Plugin Capabilities. See
http://sourceforge.net/projects/myrc for more info.
|
|
|
|
|
leppie wrote:
but doesnt seem to load the header file in the viewer
I should have said that it doesn't parse header files, but it loads a specially formatted text file to get the definitions.
You can find this file at Microsoft Visual Studio .NET\Common7\Tools\Bin\Win32API.Txt
James
"And we are all men; apart from the females." - Colin Davies
|
|
|
|
|
O dear my reply musta been washed away 
Thx James that works beautifully with Win32API.txt. I will have a look at modifying it for headers, or start a new one based on the code.
MYrc : A .NET IRC client with C# Plugin Capabilities. See
http://sourceforge.net/projects/myrc for more info.
|
|
|
|
|
I get the following compile error:
The type or namespace name 'DllImport' could not be found (are you missing a using directive or an assembly reference?)
on this:
[DllImport "user32.dll",EntryPoint="SendMessage",ExactSpelling=false,SetLastError=true)]
private static extern int SendMessage(int hwnd,int wMsg,int wParam,int lParam);
What am I missing? Should I be "using" something?
|
|
|
|
|
System.Runtime.InteropServices
|
|
|
|
|
I am about to start work on an app that will use DirectShow to capture video from a number of web cams and ASP.NET to generate a page for viewing them. There's more to it than that, but that's the core of it. I know there are some samples here on CP, but I wonder if anyone can advise me - would I be better off using DirectShow from MC++ or from C# ? My main worry is how the actual stream gets moved around, getting the video feed data from MC++ to C#.
Christian
We're just observing the seasonal migration from VB to VC. Most of these birds will be killed by predators or will die of hunger. Only the best will survive - Tomasz Sowinski 29-07-2002 ( on the number of newbie posters in the VC forum )
Cats, and most other animals apart from mad cows can write fully functional vb code. - Simon Walton - 6-Aug-2002
|
|
|
|
|
Christian Graus wrote:
would I be better off using DirectShow from MC++ or from C#
MC++, definitely. Otherwise you go through COM interop, blech, yuck, ugly, evil, etc., etc.
Of course, you could wait for DirectX 9 (this November, I think), so you could use fun DirectX from beautiful C#!
-Domenic Denicola- [CPUA 0x1337]
MadHamster Creations
"I was born human. But this was an accident of fate - a condition merely of time and place. I believe it's something we have the power to change..."
|
|
|
|
|
Consider this C# code:
///////
public class Worker
{
public ManualResetEvent MyEvent;
private Thread t;
private string message = "nothing now";
//Constructor
public Worker(string name)
{
t = new Thread(new ThreadStart(this.Work));
t.Name = "Worker: " + name;
t.Start();
//I don't like the following line:
while(t.ThreadState == ThreadState.Unstarted){}
}
//Property
public string Message
{
get{return message;}
set{message = value;}
}
//Thread function
public void Work()
{
MyEvent = new ManualResetEvent(false);
for(;;)//Loop forever
{
MyEvent.Reset();
MyEvent.WaitOne(); //Wait until "MyEvent" is Set
Console.Write("Message:" + message + ".\r\n");
}
}
//terminate the thread
public void kill()
{
t.Abort();
}
}
//////
Worker w = new Worker("Thread 1");
w.Message="Something";
w.MyEvent.Set();
....
w.Message="Something else";
w.MyEvent.Set();
...
w.kill();
----------------------------------------------------------------
Q1: Is encapsulating the thread in the class like this bad practice?
Q2: Assuming that there is nothing wrong with encapsulating the thread, is there anyway I can terminate it in a destructor? I would like to see this thread die when the instance of the class goes out of scope. I think explicitly calling the kill method is lame. (Or do I just have to get used to the way things are destroyed in C#?)
Q3: What is the “approved” method of waiting for a thread to start?
i.e. is there anything better than this:
while(t.ThreadState == ThreadState.Unstarted){}
-----
Any other comments would be appreciated.
Thanks,
-Kevin
|
|
|
|
|
ke5in wrote:
Q1: Is encapsulating the thread in the class like this bad practice?
No. It looks reasonable enough.
ke5in wrote:
Assuming that there is nothing wrong with encapsulating the thread, is there anyway I can terminate it in a destructor? I would like to see this thread die when the instance of the class goes out of scope. I think explicitly calling the kill method is lame. (Or do I just have to get used to the way things are destroyed in C#?)
Since GC is non-deterministic in .NET you could never be sure when the destructor of your class is run. If you don't mind the thread hanging around for some time after the class goes out of scope you could put the kill() call in the destructor. Although i wouldn't advise it.
May the Source be with you
Sonork ID 100.9997 sijinjoseph
|
|
|
|
|
My answer would be to implement events in the threaded class (Started and Exit) and responding to them in the main program.
The library I use for my IRC client makes use of threaded classes like this (i think, as far as i can see anyways )
Have a look at http://thresher.sourceforge.net[^]
The library runs rock solid, so I would assume this is the correct way to do it.
Hope this Helps
PS: ke5in, plz dont tick respond when receiving a reply, if you dont have a working email address ( or fix tour email address). Err: To: "ke5in" <temp1@appliedmobile.com> Mail returned - user not found.
MYrc : A .NET IRC client with C# Plugin Capabilities. See
http://sourceforge.net/projects/myrc for more info.
|
|
|
|
|
ke5in wrote:
Q1: Is encapsulating the thread in the class like this bad practice?
Not particularly, but why not have a seperate class containing an event, replace the ManualRaiseEvent with this class and then have an event handler in your Worker class?
I tend to believe in threading when I want two things to happen simultaneously (maybe if your Worker thread was continuously updating a database or an on-screen display while the program was off doing something else) rather than just waiting for something to happen. That's what events are for.
ke5in wrote:
Q2: Assuming that there is nothing wrong with encapsulating the thread, is there anyway I can terminate it in a destructor? I would like to see this thread die when the instance of the class goes out of scope. I think explicitly calling the kill method is lame. (Or do I just have to get used to the way things are destroyed in C#?)
Nothing wrong with doing it this way... you might want to call it "Dispose" though, that's the C#/VB.NET standard for killing something without waiting for it to be deconstructed.
ke5in wrote:
Q3: What is the “approved” method of waiting for a thread to start?
i.e. is there anything better than this:
while(t.ThreadState == ThreadState.Unstarted){}
Seems like a good method to me. You might want to Sleep(10) in the loop though, just so other programs can get at your processor while you're waiting.
Paul
|
|
|
|
|
I see a LOT of people are looking at remoting recently. Ive taken a look and it seems that creating a tcp channel and registering it is the way msft want you to talk between two applications.. even on the same machine.
Isnt that a huge security issue? I have to make a powerbuilder app communicate with a C# app. I dont want to put COM in the C# part of the application and I DEFINITELY dont want to deal with registering objects... ever again.
How can I get these two apps to communicate without having a registered COM object AND do it securely?
|
|
|
|
|
poodull wrote:
I dont want to put COM in the C#
Use remoting to avoid COM, and why don't you think security exist in remoting?
Soliant | email
"The whole of science is nothing more than a refinement of everyday thinking." -Albert E.
|
|
|
|
|
How I get the feel of a Wizard dialog in C#/Windows Forms?
I would like to make dialogs that acts like wizards.
Now I am using a buggy procedure of overlapped panels, that I hide and unhide.
What is the proper way to do that?
THX
"Nelle cose del mondo non e' il sapere ma il volere che puo'."
|
|
|
|
|
|
|
I think its time for regular expressions  HAHAHHAHA evil laugh from Dr. Evil
MYrc : A .NET IRC client with C# Plugin Capabilities. See
http://sourceforge.net/projects/myrc for more info. 
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
Email: