shortcut to trigger event when not in focus
-
does anyone know a way to make an event trigger if a key combo is pressed ( lets say ctrl+alt+insert) that would trigger an event to go the problem is that the app may not be in focus
You can do it, but I am not sure you really want to. If you hook into the windows message loop you can pick up on all windows messages includeing keyboard keypresses, but it is pretty intensive and would most likely affect the proformace of your application and perhaps the performance of others as well. I guess I would ask why do you want to do this? Is there a better way to do the same thing? It would be un likely that your users would know this key press short cut. Now if you are trying to write a nice little hack that is looking for control - alt del and then you are trying to get the password typed it etc. that is another issue. You won't find much help here on this site for that type of stuff. Ben
-
You can do it, but I am not sure you really want to. If you hook into the windows message loop you can pick up on all windows messages includeing keyboard keypresses, but it is pretty intensive and would most likely affect the proformace of your application and perhaps the performance of others as well. I guess I would ask why do you want to do this? Is there a better way to do the same thing? It would be un likely that your users would know this key press short cut. Now if you are trying to write a nice little hack that is looking for control - alt del and then you are trying to get the password typed it etc. that is another issue. You won't find much help here on this site for that type of stuff. Ben
the problem is that they are working seamlessly there is an application they use that is run on a remote server and on occasion it locks up and the user does not have access to ctrl alt delete becuase it is running on a remote session and that would open taskmanager for there local comptuer the only solution i can think of is to run another application with the remote application ( two applications) and when ever it locks up set it a key stroke command so that the second program (my program) kills the first which will respawn in a few seconds since the second app will not have its windows displayed i dont know how else to trigger it other than to use a keyboard shortcut also since they will be wokring in the other application, My app wont be the primary focus
-
the problem is that they are working seamlessly there is an application they use that is run on a remote server and on occasion it locks up and the user does not have access to ctrl alt delete becuase it is running on a remote session and that would open taskmanager for there local comptuer the only solution i can think of is to run another application with the remote application ( two applications) and when ever it locks up set it a key stroke command so that the second program (my program) kills the first which will respawn in a few seconds since the second app will not have its windows displayed i dont know how else to trigger it other than to use a keyboard shortcut also since they will be wokring in the other application, My app wont be the primary focus
-
In the remote session you can right click on the task bar at the bottom and select task manager. That way they can see the task manager on the remote PC. I think that would be the best option. Ben
i think you missed the part about it running seamlessly yes its a remote desktop but only the one application is displayed on the users computer it gives the illusion that its running localy so the taskbar and the start button all that stuff is you local compuer just the app is displayed and run remotly.
-
i think you missed the part about it running seamlessly yes its a remote desktop but only the one application is displayed on the users computer it gives the illusion that its running localy so the taskbar and the start button all that stuff is you local compuer just the app is displayed and run remotly.
Wow, that is different. I guess that isn't the design I would go with. I am assuming this is a windows application? Is there a reason it needs to run on the remote server? Do your users only have lame PC's so their pc's won't actually run the app? Or perhaps you don't want to load the .net framework on their pc? You can launch a windows app from a network server and it will run locally on the user's PC as long as the trust has been set up. I have actually written an article on this: http://www.codeproject.com/dotnet/Using_MSI_or_a_strong_nam.asp[^] Anyway, I think I would look at some other options to get out of that situtation if possible. Ben
-
Wow, that is different. I guess that isn't the design I would go with. I am assuming this is a windows application? Is there a reason it needs to run on the remote server? Do your users only have lame PC's so their pc's won't actually run the app? Or perhaps you don't want to load the .net framework on their pc? You can launch a windows app from a network server and it will run locally on the user's PC as long as the trust has been set up. I have actually written an article on this: http://www.codeproject.com/dotnet/Using_MSI_or_a_strong_nam.asp[^] Anyway, I think I would look at some other options to get out of that situtation if possible. Ben
it actually has to do with 3 things the computers are decent they could easily run the app 1) licensing is one reason , you dont have to buy for example 3000 copys of winword, only 1000 becuase only 1000 people would be on the server at any given time 2) is when you have 3000 or so users you only have to update the software on the remote server ( in our case we have 8 servers) 3) helps with remote access. we deploy allot of users to really shitty areas and they might not have a good connection . so if they do work and suddenly lose conductivity there session is still running at HQ and some one can go in and save it. or they can connect an pop back in where they left off.
-
it actually has to do with 3 things the computers are decent they could easily run the app 1) licensing is one reason , you dont have to buy for example 3000 copys of winword, only 1000 becuase only 1000 people would be on the server at any given time 2) is when you have 3000 or so users you only have to update the software on the remote server ( in our case we have 8 servers) 3) helps with remote access. we deploy allot of users to really shitty areas and they might not have a good connection . so if they do work and suddenly lose conductivity there session is still running at HQ and some one can go in and save it. or they can connect an pop back in where they left off.
- I can understand the licensing thing, but it would seem you still have to license the terminal servers now. It would also seem with 3000 employees you probably should be doing the type of license that pretty much lets you do what you want verse per seat. Anyway licensing is a pain. 2) If the application resides on a network server you only have one place to update it. Of course if one user is in the app you won't be able to update it unless you kill that users session. 3) this is a problem, but most likely your app shouldn't be connected to the database server the whole time, it should only connect when saving or selecting data. Anyway, you have very valid issues. Still going back to your original problem. The application running on the remote server is locking up. Are you sure the app is locking up or is it the remote connection. I use remote connects a lot and if the connection is bad or just slow things become un responsive really quickly. So it is a real possibilty that you don't have an issue with the app as much as a slow connection to the remote server. That is a whole different problem. Ben
-
- I can understand the licensing thing, but it would seem you still have to license the terminal servers now. It would also seem with 3000 employees you probably should be doing the type of license that pretty much lets you do what you want verse per seat. Anyway licensing is a pain. 2) If the application resides on a network server you only have one place to update it. Of course if one user is in the app you won't be able to update it unless you kill that users session. 3) this is a problem, but most likely your app shouldn't be connected to the database server the whole time, it should only connect when saving or selecting data. Anyway, you have very valid issues. Still going back to your original problem. The application running on the remote server is locking up. Are you sure the app is locking up or is it the remote connection. I use remote connects a lot and if the connection is bad or just slow things become un responsive really quickly. So it is a real possibilty that you don't have an issue with the app as much as a slow connection to the remote server. That is a whole different problem. Ben
agian its a weird concept the application is not running at the local level so there is no connection problems if your connection to your session is bad then it still will not effect the session on the server 2ndly the application is Winword.exe but it is full of custom macros and whatnot ( in my opionion it is poorly written) HOWEVER i dont have athority to rewrite it but i do know that after about a year of dealling with it that the cure all fix is to remote control the user and kill the winword proccess ( it will then resawn)
-
agian its a weird concept the application is not running at the local level so there is no connection problems if your connection to your session is bad then it still will not effect the session on the server 2ndly the application is Winword.exe but it is full of custom macros and whatnot ( in my opionion it is poorly written) HOWEVER i dont have athority to rewrite it but i do know that after about a year of dealling with it that the cure all fix is to remote control the user and kill the winword proccess ( it will then resawn)
Well, with the process class you can find the winword process and kill it. There is a GetProcessesbyName that should return all the winword processes if you pass winword.exe into it. Then in your foreach you can do the p.Kill(); So at that point you would just need to re-start the app. Ben
-
Well, with the process class you can find the winword process and kill it. There is a GetProcessesbyName that should return all the winword processes if you pass winword.exe into it. Then in your foreach you can do the p.Kill(); So at that point you would just need to re-start the app. Ben
-
i can already find it and kill it the respawn is taken care of with something else the triggering the find and kill is what i need
Well, not that this is a great solution, but since they are both running on the same box. You should be able to set up something like this: The application in question writes out a datatime stamp to some file. The find and kill application checks after a few minutes if it still hasn't see anything from the app then it kills it. Now I know this is winword so maybe writing out that datetime will be hard, but you kind of need the application to regularly do something so you know it is there. If you are writing out to files, of course you need to make sure that you clean them up as well. Anyway, maybe not a great idea, but an idea. Ben
-
Well, not that this is a great solution, but since they are both running on the same box. You should be able to set up something like this: The application in question writes out a datatime stamp to some file. The find and kill application checks after a few minutes if it still hasn't see anything from the app then it kills it. Now I know this is winword so maybe writing out that datetime will be hard, but you kind of need the application to regularly do something so you know it is there. If you are writing out to files, of course you need to make sure that you clean them up as well. Anyway, maybe not a great idea, but an idea. Ben
-
not really an option the winword.exe goes directly to an oracle database that i dont have access to none of the files are saved on the sessions hdd
Ok, that is sort of what I thought. I did find one property in the process class that may help you. It is called Responding. Here is the MS help on it: If a process has a user interface, the Responding property contacts the user interface to determine whether the process is responding to user input. If the interface does not respond immediately, the Responding property returns false. Use this property to determine whether the interface of the associated process has stopped responding. If the process does not have a MainWindowHandle, this property returns So I guess in that case you could have the other app always running and checking every so often to see if the winword has stopped responding. If after checking a few times it still isn't responding then kill it and relaunch. Ben