|
if you want to send a message in c#, here is the way to declare ...
[DllImport("user32.dll",EntryPoint="SendMessage",ExactSpelling=false,SetLastError=true)]
private static extern int SendMessage(int hwnd,int wMsg,int wParam,int lParam);
[DllImport("user32.dll",,EntryPoint="PostMessage",ExactSpelling=false,SetLastError=true)]
private static extern int PostMessage(int hwnd,int wMsg,int wParam,int lParam);
Hope this helps..
Thanks
|
|
|
|
|
Cool, thanks. I was just wondering if there was some C# or .NET way of doing this. They seem to abstract nearly everything else but I guess abstracting this would be getting too far away from an OS/hardware neutral language.
Thanks for the info,
-Kevin
|
|
|
|
|
Agreed.  That's the big trick (or lie, depending on the irony level) behind the DotNet framework. It is supposed to be interoperable, or even cross-platform and what people do is SendMessage or other things.
In articles such like these, the author uses a utility wrapper for a significant portion of the win32 API.
It looks like when you have to go through lower-level code, the uses of messages, notifications and so on is inevitable.
IMHO, MS is not to blame for disabling it entirely in C# (this is btw is almost impossible as the whole operating system is based on windows messaging). MS is to blame for providing an overridable WndProc(message) method for most C# UI controls, which indeed tends to make us keep the former approach.
What I would expect for DotNet 2.0 later in 2003 is a finished product, with a rich eventsubscriber-based mechanism that, especially when run on Windows, is exactly translated in lower layers as known windows messages and notifications. Or else provide richer API for most C# UI controls so that when we need to use owner drawing, we don't need to rely on WM_ stuff.
|
|
|
|
|
I'd agree with that prediction. MS already bit the bullet and included the Microsoft.Win32 namespace but all they included of any use is Registry handling (although that is such a nightmare when using the API in VB, having to fill out the strings for accepting the values, it's no surprise that it was a priority here).
I'm sure Windows Messaging will be the next thing they have to give in on, it's too fundamental, even if it is easy enough to import.
On the whole, I don't think people will see it as a break-down in the "multi-platform" thinking. If you want to write a multi-platform program for the mythical "other" platforms that will support a DotNet Framework, you stay away from the Microsoft Namespace; you're probably not going to want to access the registry or send any windows messages anyway.
But you've still got to be able to use the full Windows API readily if you feel the need and don't give a damn about other platforms. I'm sure the DotNet team will see this... eventually. 
|
|
|
|
|
In a way, it could just be an extension of delegates, couldn't it? Currently delegates just become function calls, but you could, I guess, have different delegate classes with different implementations, sending windows messages instead? It's all just implementation detail...
Stuart Dootson
'Java, Basic, who cares - it's all a bunch of tree-hugging hippy cr*p'
|
|
|
|
|
StephaneRodriguez wrote:
It is supposed to be interoperable, or even cross-platform
It *is* interoperable and cross-platform when you focus on the parts of the framework that hold that promise. Windows Forms, ADO.NET, ASP.NET among other technologies are not part of the CLI which is portion of the framework carrying that promise.
Other projects such as Mono are working on bringing over the non-CLI parts.
James
"And we are all men; apart from the females." - Colin Davies
|
|
|
|
|
Interoperable ? Not sure.
If we forget UI or other application layers, and go down to the simplest types such like "int" and "char", then if we refer to the MSDN documentation is is clearly said that :
- "int" is 32 bits : how does it cope with 64-bit oses ready this year?
- "char" is 16bits : how does it cope with the latest Unicode additions (I have read somewhere that 30 000 symbols have been added lately) ?
I don't know if the documentation showed this mapping just to give a snapshot reference while remaining essentially dynamical, or if it is hardcoded once for all.
In the second case, C# is just C without pointers. There is no more interoperability in it.
To add to the irony, I have to argue that WindowsCE is with the .Net framework not even part of their strategy, as (as for what I have seen so far) no method implementation targets this platform.
In fact, what MS calls interoperable is on the one hand interoperable across their own Windows platforms (not between Sun,HP,S/390,...). On the other hand, they actually cannot stand this either : VisualStudio.Net does not target PDAs or other devices. The Mobile internet toolkit looks like an application layer, not a framework layer.
AFAIK, I want MS to be able to ensure developers that at least a program developed targeting for instance WIN2000 can actually be run on any WIN2000 consumer machine.
This sounds stupid, but why should I spend time developing software that someone else will not be able to run ?
This happen to have been a failure for many of MS APIs, including DirectX.
Regards
|
|
|
|
|
StephaneRodriguez wrote:
If we forget UI or other application layers, and go down to the simplest types such like "int" and "char", then if we refer to the MSDN documentation is is clearly said that :
- "int" is 32 bits : how does it cope with 64-bit oses ready this year?
int will always be 32-bit in .NET; the full typename is System.Int32. In cases where you need a scalable value such as for pointers use IntPtr as that is what it is used for. On 32-bit platforms IntPtr will be 4 bytes and on 64-bit platforms it will be 8 bytes.
If you need a 64 bit integer use C#s "long" or System.Int64.
StephaneRodriguez wrote:
- "char" is 16bits : how does it cope with the latest Unicode additions (I have read somewhere that 30 000 symbols have been added lately) ?
Good point, and I have no idea; I assume we'll be stuck in the same situation as before and use codepages.
StephaneRodriguez wrote:
I have to argue that WindowsCE is with the .NET framework not even part of their strategy, as (as for what I have seen so far) no method implementation targets this platform.
Its coming, last I knew the Compact Framework was still in beta. Quite a few people got to play with it back in the early Beta phases and they liked it. Unfortunately I only have a Palm 100 so I didn't get to have any fun 
Smart Device Extensions and .NET Compact Framework Beta 1[^]
StephaneRodriguez wrote:
The Mobile internet toolkit looks like an application layer, not a framework layer.
It provides server controls for ASP.NET which should render correctly given the devices support. Whether that is an application layer or a framework layer could be debated because it behaves as both in places.
StephaneRodriguez wrote:
In fact, what MS calls interoperable is on the one hand interoperable across their own Windows platforms (not between Sun,HP,S/390,...).
Aside from not having an implementation of the CLI, what would stop a .NET console program from working on Sun, HP, S/390, etc? The CLI is the only part that Microsoft has said would be open for porting, the other technologies are more or less tied to Windows and kin thus it wouldn't make much sense to port them.
Of course MS is pushing the usage of Windows Forms and non-CLI portions of .NET, just like they've pushed the use of COM. Unlike COM though, we're seeing other implementations being produced.
StephaneRodriguez wrote:
This happen to have been a failure for many of MS APIs, including DirectX.
I would hardly call DirectX a failure; you'll have a hard time finding any retail game released in the last 3 years that doesn't use at least some part of DirectX. Keep in mind that DirectX started when the developers of Office saw the cool things the game SDK had and wanted to use some of those in Office.
James
"And we are all men; apart from the females." - Colin Davies
|
|
|
|
|
When you develop an entreprise product and big customers tell you to port a Windows app to Unix, your skills are speed and capabilities to port to this platform. Interoperability would normally mean that porting would be eased. I don't really see the point between this interoperability - from the real world - and the words interoperable that I see in MSDN doc.
As long as you aren't in this process, the greatest way to ensure the capabilities to do it, is to stay informed. It is very hard these days to share marketing versus true technology behind the .Net strategy.
Regarding DirectX, of course I wouldn't fight and say DirectX is not used. Of course, it is, and it's used by 99.99% of Windows games. I mean it is a failure because at the basis of the Game SDK, there should have been implementation which, for each feature, either were taking advantage of hardware, or were implementing it through software. Thanks to this paradigm, the DirectX was to be a tunnel were all games would run. May be slower if software was used instead of hardware.
What happened to that ? I have bought games that I have never been able to run. At least 3 / 4 of game trials fall in this too.
|
|
|
|
|
Hello all;
Is there a way in c#(.net) to hide an application from windows task manager's processess list..
I want my c# application to be invisible in the computer where it is installed.
Even if the user goes to task manager using ctrl+alt+del and task manager...
Any idea on how to disable ctrl+alt+del key sequence in c# on windows NT and above platforms in c#.. I started developing a application using delphi ( as it can create Global Hook. And i can trap the key sequence and pop up a box when ever ctrl+alt are pressed thus forcing the user to miss del key) and use that DLL in c#.
Any ideas & suggestions are appreciated..
Thanks
|
|
|
|
|
|
Perhaps not a trojan . But a security component i am building which will be eventually be installed on number of Servers at an organization to log Keyboard activity.
The form's show in taskbar property just hides from task bar. But the application exe is listed in the processes.
|
|
|
|
|
but why hide it from the processes? are all the users advanced enough to know how to close it? most users on the network at work barely know how to check emails.
 Email: theeclypse@hotmail.com URL: http://www.onyeyiri.co.uk
"All programmers are playwrights and all computers are lousy actors."
|
|
|
|
|
I am talking about System engineers/Administrators who may accidentally or wantedly corrupt the server. in this case, they being the system admins very well know to find out the application in the processes and kill em before they mis-handle or delete or go against their professional ethics even to the extent of formatting the machine before they leave the organization..
in this case, the org. will very well want to know who was exactly responsible ...
i think you got my point..
Gurus, please suggest me an idea...
|
|
|
|
|
I guess I wouldn't write this in C#. I would write it in C++ as a service or a device driver (probably a service). I have no idea how to do that, but C# definitely does not seem like the right tool.
Marc
|
|
|
|
|
I agree; But Microsoft promises c# to be the most powerful language after c++ giving control to the System programming.
I guess there is a way or atleast is there a way to activate the process immediately if any user kills it.
For example in Visual Studio .net IDE, when you create a C# or VB.net Web Application project, you always see wp_.... process in the processes.
Even if you kill it, the process comes up right way..
how Can i implement something like this?
Even if the user kills my application process, can i re-start it immediately...??
|
|
|
|
|
My suggestions are as follow :
- either write a dll, and let it be hosted by the operating system as a COM dll (for instance). Doing this, by definition, you won't see it in the processlist, because only .exe are listed.
- write a Dll and get it run by DllHost.exe or RunDLL32.exe depending on the operating system. (see MSDN for further details). Doing so, you still see DllHost.exe somehow in the process list (or svchost.exe for services) but no one would dare to stop it because this name brings nothing particular into attention.
|
|
|
|
|
Just launch your application when you receive WM_DESTROY or WM_CLOSE. Your current program will be closed but you will have a new session in memory. I don't think MS wants it to be possible to hide processes from the task manager list. The API shouldn't have anything about this.
Nd.
|
|
|
|
|
That one is a virus! not a process anymore. I am not sure you're able to shut down normally your computer using this idea.
And I swallow a small raisin.
|
|
|
|
|
Well the virus isn't visible in the task manager list...At least, there is a difference...
I have to recognize that old windows shouldn't be able to shutdown the computer.
But W2000 and WinXP don't allow more processes creation after shutdown, so it's ok.
Nd.
|
|
|
|
|
I had forgotten the trick but now I remember. You can use windowstations and desktops, they are objects that Microsoft introduced along with Windows NT.
These two objects allow to run processes in separate windowstations and desktops that the default one, which is the actual interactive windowstation and default desktop attached to it.
You may either create a new desktop on the current windowstation, winsta0, and then run processes on it.
You may also create a new windowstation as well.
Complete code can be found on MSDN with keyword search winsta0. That's plain raw C++ code.
Be sure to also prepare code for destroying the processes : as you will not even see them in the task manager, it will be slightly harder to stop them...
And I swallow a small raisin.
|
|
|
|
|
This seems simple to me but im getting an error that doesnt describe the problem well enough for me.
Im creating a MarshalbyRef object and exposing it on a server application using TcpChannel. a client then can comunicate with its functions remotely without error (i used Nish's guide @ csharp/absoluteremoting.asp). I would like for two clients to be able to talk to each other through this service (or anything like that). I was hoping to be able to just add an event to the remote object and link the projects that way. But when i try to += event binding, I get this error:
<br />
An unhandled exception of type 'System.IO.FileNotFoundException' occurred in mscorlib.dll<br />
<br />
Additional information: File or assembly name RemoteTestClient, or one of its dependencies, was not found.<br />
The assemblies seem fine to me and if i remove this line the project works (without the event).
what, and on how many levels, am i doing wrong?
thx
|
|
|
|
|
The problem here is that when the event is fired and the server calls the delegate it needs access to the client module in order to create the proxy. If you were to place both client and server in the same directory you would notice that this problem would not occur.
Check out the Remote Events Sample at this site
http://staff.develop.com/woodringhttp://staff.develop.com/woodring[^]
Here is an excrept from the article by Mark Woodring which explains the problem as well as the workaround
// When a client registers a delegate with a server via remoting,
// the delegate instance is marshaled by value to the server.
// The delegate itself holds a reference to the client callback
// target. Assuming the client type extends MarshalByRefObject,
// this means that when the delegate is deserialized on the
// server side of things, a proxy back to the client will be setup.
// In order for this to succeed, the type information for the
// client is needed, which means that the client's assembly needs
// to be present on the server machine and locatable via the
// standard rules of assembly resolution. This introduces
// an undesirable coupling between the server and all of its
// clients.
//
// The work around is to introduce a shim or forwarder between the
// client and server so that the server need only have access to the
// assembly containing the shim class. This shim class can be located
// any assembly - as long as both clients and server have access to
// it.
//
// In this sample, there are two apps: client.exe and host.exe.
// Client.exe is the obvious client, and host.exe is just a shell
// app that calls RemotingConfiguration.Configure to parse
// host.exe.config. This configuration file specifies that the
// Calc type from the server.dll assembly should be made available
// via remoting. You can substitute host.exe in the diagrams below
// for IIS or any other host process you might be using.
//
// An assembly named calcif.dll contains an interface (ICalc) that
// is implemented in the server assembly and programmed against by
// the client. This interface includes an event (of type
// MagicNumberCallback) that the client wants to register for.
//
// If the client simply does something like this:
//
// proxyToServer.MagicNumber += new MagicNumberCallback(OnMagicNumber)
//
// the you end up with a picture that looks something like this
// (where || indicates a process/machine boundary):
//
// [client.exe] [................server.exe.........................]
// ClientObj <-- || <-- ProxyToClient <-- MagicNumberCallback <-- CalcObj
//
// This is the scenario that breaks, since the server needs access to client.exe in order
// to construct proxy to the client. If, instead, the client instantiates
// the EventShim class from calcif.dll, passing the shim a delegate to the client method;
// and then passes the shim (which extends MBRO), then you get the following picture:
//
// [.................client.exe...................] [................server.exe.......................]
// ClientObj <-- MagicNumberCallback <-- EventShim || <-- ProxyToShim <-- MagicNumberCallback <-- CalcObj
//
// Given this, the server process now need only have access the EventShim type
// information, which is included in the assembly (calcif.dll in this sample)
// that both the client and server have access to.
//
// The added overhead of the EventShim instance in the client
// process is inconsequential compared to the overhead of crossing
// the process/machine boundary between the client and the server.
//
// You can also change the EventShim class to use the standard EventHandler
// delegate and EventArgs to come up with a more generic solution. This
// solution allows you to write the EventShim one time and use it for any
// number of situations, although you'll need to define custom EventArgs-derived
// structures to ferry the parameters back and forth as desired. Just
// choose the approach that's more comfortable for your situation.
May the Source be with you
Sonork ID 100.9997 sijinjoseph
|
|
|
|
|
Hi again...
I have Win32 dll functions looking like this:
int GetParam(IntPtr param);
int SetParam(IntPtr param);
API docs state: param = Pointer to the parameters structure to fill. Depending on the type of effect, the parameters returned will be one of: and list all structures...
Set function is not a problem. The problem comes in with the Get function. The param IntPtr can point to any of 9 different structs. How do I get the type of the struct at runtime given only the IntPtr?
I also noted that every struct is of different size. Dunno if this could work?
Otherwise I am clueless...
Any suggestions appreciated
MYrc : A .NET IRC client with C# Plugin Capabilities. See
http://sourceforge.net/projects/myrc for more info.
|
|
|
|
|
Probably the real prototype in the C# point of view is int GetParam(ref object param). And you should also add ref in your method call :
int n;
object obj = n;
int nb = GetParam(ref obj);
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
a trojan perhaps 
