|
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);
|
|
|
|
|
StephaneRodriguez wrote:
int GetParam(ref object param).
The function takes a pointer as an argument, not sure if this will work.
Here's what I make from MSDN:
1. Declare each struct as a formatted class, iow apply StructLayout.Sequential. As I dont know the Type of the returned struct im forced to use a class.
2. My implementation:
public object Parameters
{
get
{
IntPtr paramptr = IntPtr.Zero;
int result = GetFunction( paramptr);
object param = null;
Marshal.PtrToStructure(paramptr, param);
return param;
}
set
{
IntPtr paramptr = IntPtr.Zero;
Marshal.StructureToPtr(value, paramptr, true);
int result = SetFunction( paramptr);
}
}
Dont know if this will work yet  but it does compile . Should be able to test soon.
Thanx
MYrc : A .NET IRC client with C# Plugin Capabilities. See
http://sourceforge.net/projects/myrc for more info.
|
|
|
|
|
For global hooks you need the hook proc in a DLL. Now assuming we want to do this from .NET, we'll have a problem. At least I am having problems. .NET DLLs dont seem to be real DLLs as far as I am concerned
I am wondering what to pass as the HINSTANCE parameter for SetWindowsHookEx!
Regards,
Nish
Author of the romantic comedy
Summer Love and Some more Cricket [New Win]
Review by Shog9
Click here for review[NW]
|
|
|
|
|
Hey Nish,
I was just looking into this for my painting woes. I have not tried it yet, and I'm not sure if it applies to you but look at section 44.6 at this link:
http://www.syncfusion.com/FAQ/WinForms/FAQ_c70c.asp
|
|
|
|
|
|
Hi Nish
Dunno if this will help?
Marshal.GetHINSTANCE() returns IntPtr to HINSTANCE.
HTH
MYrc : A .NET IRC client with C# Plugin Capabilities. See
http://sourceforge.net/projects/myrc for more info.
|
|
|
|
|
|
|
Did someone get a successfull way to register hotkeys in C# ?
eg : CONTROL + SHIFT + J or whatever else which works whoever has the focus.
[DllImport("user32.dll")] private static extern bool RegisterHotKey(long hWnd, int id, int fsModifiers, int vk);
// MOD_CONTROL + MOD_ALT = 6
bool b = RegisterHotKey(GetForegroundWindow(),100,6, 'j'); /*0x4A*/ or 'j' doesn't work.
b is always false...No way to register anything.
Please help, my program is useless whithout hotkeys. Thanks.
Nd.
PS :
MOD_ALT 1
MOD_CONTROL 2
MOD_SHIFT 4
MOD_WIN 8
|
|
|
|
|
Anonymous wrote:
[DllImport("user32.dll")] private static extern bool RegisterHotKey(long hWnd, int id, int fsModifiers, int vk);
The returned value of the function is a C++ BOOL iow in C# an int, 0 = false all else = true;
Maybe this helps
MYrc : A .NET IRC client with C# Plugin Capabilities. See
http://sourceforge.net/projects/myrc for more info.
|
|
|
|
|
Thanks Leppie, I didn't know that. It wasn't working because I wasn't doing the registration with the right handle ! I was using GetForegroundWindow during form init, and at this moment, the handle is pointing to Visual Studio and not the launched application...
Nd.
|
|
|
|
|
This works for me
First the definitions:
[DllImport("user32.dll", SetLastError=true)]
public static extern bool RegisterHotKey(
IntPtr hWnd,
int id,
KeyModifiers fsModifiers,
Keys vk
);
[DllImport("user32.dll", SetLastError=true)]
public static extern bool UnregisterHotKey(
IntPtr hWnd,
int id
);
[Flags()]
public enum KeyModifiers
{
Alt = 1,
Control = 2,
Shift = 4,
Windows = 8
}Now a sample use of the code:
In Form load:
bool success = RegisterHotKey(Handle, 100,
KeyModifiers.Control | KeyModifiers.Shift, Keys.J);
System.Diagnostics.Trace.WriteLine(
"Success = " + success.ToString());In Form closed or closing:
UnregisterHotKey(Handle, 100); And finally override the WndProc so the message can be handled.
protected override void WndProc( ref Message m )
{
const int WM_HOTKEY = 0x0312;
switch(m.Msg)
{
case WM_HOTKEY:
MessageBox.Show("Hotkey pressed");
break;
}
base.WndProc(ref m );
}HTH,
James
"And we are all men; apart from the females." - Colin Davies
|
|
|
|
|
Thanks for your answer and the needed time. I replace all my code by yours and it still didn't work...That give me the idea to search for something else and I got it. I was using GetActiveWindow in order to get the handle of the current program...I know, it's not the best way...I will search for a better one later, time is running. During the init of the form, the GetActiveWindow returns the handle of Visual Studio and not the one of my program. So I was trying to register hotkeys for Visual Studio and it wasn't working.
Well, thanks to you it's working fine now, I was gonna give up (too much time spent on it)
My program should be ready for tomorrow with minimal features.
Nd.
|
|
|
|
|
If you want to get the HWND for your Form use the Handle property of the Form.
James
"And we are all men; apart from the females." - Colin Davies
|
|
|
|
|
Interesting
Just a question James...
In the Interop Marshalling section (Platform Invoke Data Types) in MSDN it states:
BOOL as Unmanaged type in Wtypes.h = long in Unmanaged C++ = System.Int32 as Managed type.
Looking at your code, is it possible to allways use bool instead of int as long as the returned value does not hold somethin like an error code?
Also, in alot of examples I see them using int for a DWORD which really translates to uint. OK, I understand it will work, but only if int => 0. Why not use uint in the first place?
This is all getting a bit overcomplicated to me.
I think probably the best is to keep it simple. Try the logical way, if fail, do the way according to Platform Invoke Data Types Table.
Suggestions?
Cheers
MYrc : A .NET IRC client with C# Plugin Capabilities. See
http://sourceforge.net/projects/myrc for more info.
|
|
|
|
|
As you've found out, all that is important is that the size be the same. However some things will get marshaled back and forth correctly.
The conversion between BOOL and LONG to bool will marshal correctly so that the bool will have a true/false value.
Using unsigned types in .NET isn't really discouraged but doing so makes the code non-CLS compliant so that code may not be portable to other languages or even used by them should they not support the same unsigned types. Thats my understanding anyway 
James
"And we are all men; apart from the females." - Colin Davies
|
|
|
|
|
Ahh, thx James. Didnt know about unsigned types being non CLS compliant.
re BOOL, i just made a small function to take care of it , but with this input i'll try converting some of them as see the results.
The only remaining worry is what happens when DWORD return a value bigger than Int32.MaxValue? Not that it has happened yet, but it could.
MYrc : A .NET IRC client with C# Plugin Capabilities. See
http://sourceforge.net/projects/myrc for more info. 
|
|
|
|
|
leppie wrote:
The only remaining worry is what happens when DWORD return a value bigger than Int32.MaxValue? Not that it has happened yet, but it could.
Unfortunately thats just something you have to know ahead of time and it depends on how the value is used.
If the DWORD contains something larger than Int32.MaxValue the return result will be negative as the LSB or MSB will be set (I never can remember how it should be ordered  )
James
"And we are all men; apart from the females." - Colin Davies
|
|
|
|
|
Thx again James 
James T. Johnson wrote:
If the DWORD contains something larger than Int32.MaxValue the return result will be negative as the LSB or MSB will be set (I never can remember how it should be ordered )
According to MSDN an overflow exception will occur unless the block is marked unchecked. In which case the MSB/LSB (hell i dont know either, will wait till next year when I'm doing bitwise operations more regularly) will be set.
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
