|
Does anyone know how to stop a service form being killed by the Task Manager or any other method other than the services own stop function.
If this is at all possible?
Cheers
|
|
|
|
|
I don't think it is, as it wouldn't be a particularly desiarable behaviour (unless you were writing a virus or something).
The best way to stop users from meddling with task manager is through user accounts and permissions - an often neglected, but very important, part of system administration.
|
|
|
|
|
Yes, on the Stop function loop for 45 seconds, the service stoper will time out. Now this is kind of stupid to do.
My eMail control
My Blog
|
|
|
|
|
The problem I have this that we have written a service/application that monitors usage and controls access using a booking system to around 3000 workstations, but some users have found that by killing the service this then stops the service from logging them out when the booked time has elapsed
I supposed then answer is testing the current user who is tiring to exit the service and testing the system exit status.
Looping on the on stop would work if you could tell if the workstation is in a state of shutting down forced or not.
|
|
|
|
|
This is more a training problem than a computer problem.
Solution:
Step 1: Identify the user.
Step 2: Fire the user.
Repeat as necessary.
|
|
|
|
|
|
Is there any way to find the compiler's CLR version to use in an #if clause?
Something like:
#if CLR == 2.0
//do this
#endif
Thanks in advance,
Rei
|
|
|
|
|
Every .Netframework leaves a key in:
"HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\policy"
For example if the machine has 2.0 Framework installed then there will be:
"HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\policy\v2.0" key in the registry
try this code:
if (Registry.LocalMachine.OpenSubKey("SOFTWARE\\Microsoft\\.NETFramework\\policy\\v2.0") != null)
{
//Do something
}
but that will work fine with the if statement, not with the preprocessor directive #if.
|
|
|
|
|
You can't access any C# constructs from the precompiler directives though... only the precompiler variables and a small handful of comparative expressions.
|
|
|
|
|
Sorry for the mistake. I fixed my message though. I will look for it, if I find something I'll let you know.
But, can you give me a hint why you want it in a preprocessor directive rather than ordinary if statement?
|
|
|
|
|
I'm trying to use System.Drawing.BufferedGraphics, which is only available on .NET 2.0. I could use System.Drawing.Bitmap instead, but it's slightly less performant.
Also, some of the form mouse events are slightly different between the two versions.
I want to avoid having two copies of the code if I can, so I want to use the preprocessor to distinguish between the two.
There's one variable, VC_V7 that's used in an example in the C# documentation on MSDN, but that's only for Visual Studio (I think... I'm not sure why it'd be VC_V7).
Thanks for helping 
|
|
|
|
|
http://msdn2.microsoft.com/en-us/library/0feaad6z.aspx[^]
The C# compiler itself defines no symbols or macros that you can use in your source code; all symbol definitions must be user-defined.
That's why there's no documentation 
Guess I'll have to find some ways to work around it.
Thanks though.
|
|
|
|
|
Hi. I have a winform (with fade-in and fade-out effect) and I run it on VS 2003 and works great. But when I use VS 2005, the winform appears like with flicks, it's like it had a rendering problem. The example works great with VS 2003, but I have to run in in VS 2005.
Any ideas??
Thanks a lot !!!
|
|
|
|
|
Try this in the form's constructor:
SetStyle(ControlStyles.AllPaintingInWmPaint | ControlStyles.UserPaint, true);
If that doesn't work, try playing around with the other ControlStyles things.
That might fix it.
|
|
|
|
|
I still have the problem.
Any other ideas ??
Thanks a lot !!!!
|
|
|
|
|
Hmm... try turning off the Application.EnableStyles thing in the Main() method, if it's there.
|
|
|
|
|
Reinux, I can't see the option you're reffering , only one: Application.EnableVisualStyles(); but it isn't take any parameters.
Thanks a lot !!!
|
|
|
|
|
Try taking the whole line out.
It's sorta optional.
|
|
|
|
|
|
I'm out of ideas 
|
|
|
|
|
I found the problem ...
See this link:
http://www.dotnet247.com/247reference/msgs/42/214827.aspx
Yes, that is what I found. I hadn't seen the flickering before because my
form was too small.
However, this is true. The flickering occures when the underlaying window is
switched to "layered mode". Actually it flickers even if you set alpha to
255 (fully opaque).
Switching to layered mode involves three steps.
1. Checking the os version - it has to be NT 5 or latter
2. Set WS_EX_LAYERED window style
3. SetWindowLayeredAttributes this method is not defined in user32.dll for
versions before Win2k that's why first step is necessary.
When a Windows Forms control is created it is not a layered window. And it
switches to this mode when set the opacity to some value less then 1.
So my solution is to switch to layered mode in some early stage of the form
life. As soon as the form is created before to become visible. Otherwise
we'll see the flickering.
Javier is completely correct that the layered window has to be fully
redrawn. But it goes only when the window (form) resizes. You can still
invalidate some portions of the form and it will works how ot supposed to
work.
Layered window could even show better performance in some situations.
How internaly layered windows work is all painting is redirected to
off-screen buffer and when the painting's done alpha blending is applied to
the resulting picture and the result is drawn on the screen. This of course
is done internaly in windows and it uses the video card hardware support for
alpha blending if it has any.
Becuse all winodw is double buffered Windows doesn't send WM_PAINT when the
form is moved for example or when some part of the form is uncovered. In
such cases Windows uses double buffered image.
When children control is moved on the form it updates as much as it is
necessary. So the performance hit is not so big.
Anyway, my first solution that I was planning to post involved P\Invoke and
calling all API functions necessary to switch to "layered mode", but then I
found that if one set Opacity to value less then 1 and then return it back
to 1 the form class doesn't switch to the "normal mode" and leave the window
layered.
So the easiest way to get rid if this flickering is by overriding
OnControlCreated method and adding the following two lines:
this.Opacity = 0.9;
this.Opacity = 1;
No more flickering .
Thanks a lot people !!!
|
|
|
|
|
So you figured it out 
Wow that's weird.
|
|
|
|
|
Try checking the DoubleBuffered property in your form and in the ControlStyles to true.
|
|
|
|
|
I have a single-selection listview, configured to view details.
It has 4 columns.
When I left-click on one of the items (left-most column), the
SelectedIndexChanged Event fires, as expected. The first time
I left-click (after the form loads), the SelectedItems.Count is 1.
For subsequent left-clicks the Event fires two times: the first time, the
SelectedItems.Count is zero; the 2nd time the count is 1.
Why is the event firing 2 times?
Thanks,
Don
|
|
|
|
|
I haven't used ListView in a long time, but my guess is that it's technically deselecting the selected item first so that it can fire the deselected event as well.
Given you don't want to take any action when nothing is selected, you could get around it by just saying this at the beginning of the method:
if(SelectedItems.Count == 0)
return;
Try to figure out the exact cause too though. It's always a good idea to know what caused a problem in the first place if you're using a workaround.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
