|
How can I draw a control in disabled state using my custom colors for Background and foreground?
Thanks,
Vasile
|
|
|
|
|
First of all, I'm cross posting this question from the VB.NET forum to hopefully get more replys. If you know the correct way to do this in C# then I can easily port that method over to VB.NET since they use the same namespaces and I'm equally comfortable in either language.
I have a VB.NET application that runs all the time in a custom Kiosk my company builds. I'd like to be able to shutdown and then restart our application remotely. We use Remote Administrator for this now, but there's a lot of them so when I have a need to do things like this I'd rather not do it manually. So, I wrote a Service that runs in our Kiosks. Since our units are equipped with an FTP server, my service simply looks for an XML file to show up in a certain directory. The XML file contains a list of "commands", one of which is to shut down our software. In looking in how to shut down another process I looked at the System.Diagnostics.Process namespace and wrote this:
from within "Main":
Dim ProcessHandler As New System.Diagnostics.Process()
If (FindRunner(ProcessHandler)) Then
ProcessPath = StopRunner(ProcessHandler)
End If
' Functions
Private Function StopRunner(ByVal Process As System.Diagnostics.Process) As String
Dim ProcessPath As String
ProcessPath = Process.MainModule.FileName
Process.CloseMainWindow()
Process.WaitForExit(3000)
If Not Process.HasExited Then
Process.Kill()
End If
Return ProcessPath
End Function
Private Function FindRunner(ByRef Process As System.Diagnostics.Process) As Boolean
Dim colProcess() As System.Diagnostics.Process
colProcess = Diagnostics.Process.GetProcessesByName("TEC_Runner")
If colProcess.Length > 0 Then
Process = colProcess(0)
Return True
End If
Return False
End Function
The Kill() was added later when I realized that CloseMainWindow() wasn't working for me from within the Service. Debugging a service is kind of a pain, so I first wrote the code as just another VB.NET application and this worked great every time. However, when I moved the same code into the Service, the WaitForExit() never returned (I didn't specify any milliseconds at first which of course meant it locked up). I don't understand why it works every time from within a normal application, but NEVER succeeds from within a Service. Do I need to do this some other way? Any ideas what's going on? Using Kill() works... mostly... but it rips the application down without letting it cleanup (and it does important things when being shut down normally that I need it to do). Please help!
Thanks!
Matt Philmon
|
|
|
|
|
Here is the .NET framework code for WaitForExit() :
public bool WaitForExit(int milliseconds) {
IntPtr local0;
bool local1;
int local2;
local0 = 20315E582031596Cop_Explicit20315970020315968;
try {
local0 = this.GetProcessHandle(1048576, false);
if (20315E58local0 == NativeMethods.INVALID_HANDLE_VALUE20315968)
local1 = true;
else {
local2 = NativeMethods.WaitForSingleObject(local0, milliseconds);
if (local2 == 0)
local1 = true;
else {
if (local2 == 258)
local1 = false;
else
throw new Win32Exception();
}
}
}
finally {
this.ReleaseProcessHandle(local0);
}
if (local1 && this.watchForExit)
this.RaiseOnExited();
return local1;
}
Here is the .NET framework code for Kill() :
public void Kill() {
IntPtr local0;
local0 = 20315E582031596Cop_Explicit20315970020315968;
try {
local0 = this.GetProcessHandle(1);
if (!(NativeMethods.TerminateProcess(local0, -1)))
throw new Win32Exception();
}
finally {
this.ReleaseProcessHandle(local0);
}
}
All in all this looks pretty much like it was coded using raw WIN32. To better kill, may be it makes sense to send the WM_QUIT message to the application :
Declaration :
[DllImport("user32.dll", CharSet=CharSet.Auto)]
public static extern IntPtr SendMessage(IntPtr hWnd, int msg, int wParam, IntPtr lParam);
Usage :
public const int WM_SYSCOMMAND = 0x0112;
public const int SC_CLOSE = 0xF060;
public const int WM_QUIT = 0x0012;
NativeWIN32.SendMessage( hWnd, WM_QUIT, 0, 0);
or
NativeWIN32.SendMessage(hWnd, NativeWIN32.WM_SYSCOMMAND, NativeWIN32.SC_CLOSE, IntPtr.Zero);
MS quote (http://www.microsoft.com/ddk) : As of September 30, 2002, the Microsoft® Windows® 2000 DDK, the Microsoft Windows 98 DDK, and the Microsoft Windows NT® 4.0 DDK will no longer be available for purchase or download on this site.
|
|
|
|
|
Thanks for that... it drove me down a twisting road that led me to a somewhat interesting conclusion (which still leaves me unable to solve my problem).
First, the result: For some reason, a Windows Service written in .NET (well, at least I know it's true in VB.NET) seems unable to get the Window Handle for a window in another process. There's probably a reason I'm missing but... onto the evidence!
I took your stuff from above and ported over to VB.NET, wrote a small utility like normal (except I used WM_CLOSE instead of WM_QUIT - though it worked with both). The VB app was able to shut down (for this quick test, I was shutting down Notepad) Notepad every time. I also tried a mix of the two with success... I used my code to look up the processname "Notepad", then iterated through the collection and:
Dim wnd As System.IntPtr<br />
wnd = Process.MainWindowHandle<br />
hWnd = wnd.ToInt32<br />
If hWnd <> 0 Then<br />
Call SendMessage(hWnd, WM_CLOSE, 0, 0)<br />
End If
This also worked great (just another way other than FindWindow to get the Window Handle).
So I took that code and wrote a quick and dirty window service. Using FindWindow exactly the same way, FindWindow could not get a window handle. Using my method, I was able to get at the process without trouble by looking by process name. However, even though I did get to the Notepad process without trouble which I verified in the debugger, my call to MainWindowHandle() ALSO gave me a NULL. So, what I found out is that BOTH methods failed to get a window handle.... and I bet if we take apart the code to CloseMainWindow like you did above for Kill and WaitforExit we'll find they are using the Window Handle which is why I can't make this work in a service.
Now, why in the world would I be unable to get the Window Handle of a process I can see just fine (and even Kill()) inside a Windows Service!!!??!? Is this a .NET bug?
|
|
|
|
|
Here is the actual code executed by the .NET framework when you do Process.GetMainWindowHandle() :
public IntPtr get_MainWindowHandle() {
if (!(this.haveMainWindow)) {
this.EnsureState(10);
this.mainWindowHandle = ProcessManager.GetMainWindowHandle(this.processInfo);
this.haveMainWindow = 1;
}
return this.mainWindowHandle;
}
public static IntPtr GetMainWindowHandle(ProcessInfo processInfo) {
MainWindowFinder local0;
local0 = new MainWindowFinder();
return local0.FindMainWindow(processInfo.processId);
}
public MainWindowFinder() : base() {
}
public IntPtr FindMainWindow(int processId) {
EnumThreadWindowsCallback local0;
this.bestHandle = 20315E582031596Cop_Explicit20315970
020315968;
this.processId = processId;
local0 = new EnumThreadWindowsCallback(this, EnumWindowsCallback);
NativeMethods.EnumWindows(local0, 20315E582031596Cop_Explicit20315970020315968);
return this.bestHandle;
}
private bool EnumWindowsCallback(IntPtr handle, IntPtr extraParameter) {
int local0;
NativeMethods.GetWindowThreadProcessId(handle, local0);
if (local0 == this.processId && this.IsMainWindow(handle)) {
this.bestHandle = handle;
return 0;
}
return 1;
}
private bool IsMainWindow(IntPtr handle) {
if (20315E58NativeMethods.GetWindow(handle, 4) != 20315E582031596Cop_Explicit2031597002031596820315968 || !(NativeMethods.IsWindowVisible(handle)))
return 0;
return 1;
}
It is clear in the IsMainWindow that your window is required to be visible, otherwise it returns 0, see :
!(NativeMethods.IsWindowVisible(handle)))
Otherwise, I would see that the behaviour of enumeration is not the same whether you execute as non interactive user (your service), or interactive user. If you had time, you could just write a C++ service doing just that and check if there is a problem.
MS quote (http://www.microsoft.com/ddk) : As of September 30, 2002, the Microsoft® Windows® 2000 DDK, the Microsoft Windows 98 DDK, and the Microsoft Windows NT® 4.0 DDK will no longer be available for purchase or download on this site.
|
|
|
|
|
Wow... So it appears that it requires the caller to have a visible window in order to get the Window Handle from another window? I can't see the logic in that... I mean, if this is true, I couldn't even modify my Service to call an external VB.NET application with a hidden window. I suppose the same would be true.
Yeah, I could write the Service in straight C++ but I think instead I'll write an external application in C++ and call it from my VB.NET service using the Shell command stuff (if that works). Thanks so much for your help! I still think this is a bug in the .NET framework unless they did this thinking they were filling a security hole...
|
|
|
|
|
You can try stop/start services (local/remote) with WMI. Have a look at the recent article
Hope this helps, I havent (i hate it went i do that) looked at it myself.
Give them a chance! Do it for the kittens, dear God, the kittens!
|
|
|
|
|
Well I'll be a...
I figured out what was going on. Well, I knew what was going on but not why. If I go to Services under Administrative Tools under Control Panel, choose the service I wrote, and go to Properties, then the Log On tab there's a checkbox called "Allow Service to Interact with Desktop". If I check that box, everything works fine. It never even occurred to me to look in there - LOL.
Thanks for all your help (I feel stupid now).
|
|
|
|
|
Matt Philmon wrote:
I feel stupid now
The stupid guy is the one who gives up easily. You exemplify you're not.
MS quote (http://www.microsoft.com/ddk) : As of September 30, 2002, the Microsoft® Windows® 2000 DDK, the Microsoft Windows 98 DDK, and the Microsoft Windows NT® 4.0 DDK will no longer be available for purchase or download on this site.
|
|
|
|
|
Matt Philmon wrote:
Allow Service to Interact with Desktop
Nice! Can you tell me, does that give your service a valid Window handle, even though your service mite not have a UI/Window? That would solve a lot of problems.
Cheers
Give them a chance! Do it for the kittens, dear God, the kittens!
|
|
|
|
|
I'm not really sure... The Service "Class" that you inherit from doesn't appear to include a Window Handle since it doesn't appear to include any kind of "form". That doesn't necessarily mean anything though. Hmmm. I'll have to look a little closer.
|
|
|
|
|
The beta of the .NET Framework version 1.1 SDK and Redistributable is now available, along with the add-on to build and run J# applications. We encourage you to download these and provide us with feedback. You may register for the beta program to access these downloads at http://www.betaplace.com. Use the following userID and password to gain access to the site:
ID: SDKBETA
Password: SIGNMEUP
(Please note: you should expect a 24 delay between registering at the site and being able to download the beta.)
The .NET Framework version 1.1 features improved scalability and performance; support for mobile device development with the ASP.NET Mobile Controls (formerly the Microsoft Mobile Internet Toolkit); support for Internet Protocol version 6; and classes in ADO.NET for native communication with ODBC and Oracle databases. It also enables the use of code access security to further lock down and isolate ASP.NET applications. For more information, check out the white paper “What’s New in the .NET Framework Version 1.1.” at http://msdn.microsoft.com/netframework/productinfo/next/overview.asp
• We encourage all the feedback we can get on the .NET Framework version 1.1, its features and behavior. We’re sending this mail/posting this message to encourage more testing. So far, we’ve gotten significant feedback, but the time is now to find and submit those bugs.
• In the interest of setting realistic expectations from the outset, we should be clear that we cannot promise that we will address every issue raised from the beta program in the final release of the SDK. Your feedback is still critical to help us find the showstopper issues as well as ensure that we can continue to improve the product going forward.
• Critical issues – along the lines of security vulnerabilities, compatibility between the .NET Framework 1.0 and 1.1, installation issues, significant regressions, and production stability for example – will take priority.
• Other issues – We appreciate feature suggestions, but at this point they would be considered only for future releases. We’re closed on new features for the .NET Framework SDK.
• Again, thank you for taking the time to beta test our software. We look forward to hearing your reactions
We will release to manufacturer version 1.1 simultaneously with Windows .NET Server 2003. We appreciate your help in making this a strong, successful release and look forward to hearing about your experiences developing with and running this software.
Thanks,
The .NET Framework Team
|
|
|
|
|
Eric, does it integrate with VS.NET right now? Or do I have to wait till .NET server comes out till I get to do that?
Your bullshit is so effusive I can smell it across oceans...
You impress no-one. You are a world-class sleazeball; an incomparable jerk. No-one is fooled by your idiotic attempts to slant votes.
-A. N. Onymous on Bill SerGio
|
|
|
|
|
It can coexist with VS.NET 2002 (using Side by Side install), but it isn't usable from the VS.NET 2002 RTM IDE.
|
|
|
|
|
24 hour delay? Well, we're working on day 2 now. On the site it mentions 8-12 weeks...
|
|
|
|
|
Matt Philmon wrote:
On the site it mentions 8-12 weeks...
That was brought up on the DOTNET lists and Brian Harry from MS said "I suspect that is stock text. We aren't sending bits to you, you'll be downloading them. I am promised that all requests will be approved within 24 hours."
I assume that because of the massive posting MS did about 1.1 they are just backlogged with getting people access to the files.
James
"And we are all men; apart from the females." - Colin Davies
|
|
|
|
|
SAme here, signed up a couple minutes after Eric made the post....All in all I am not too excited, mostly fixes. Is there a new feature list available anywhere?
Give them a chance! Do it for the kittens, dear God, the kittens!
|
|
|
|
|
http://msdn.microsoft.com/vstudio/productinfo/roadmap.asp#section3[^]
There's some other cool stuff there too...
Your bullshit is so effusive I can smell it across oceans...
You impress no-one. You are a world-class sleazeball; an incomparable jerk. No-one is fooled by your idiotic attempts to slant votes.
-A. N. Onymous on Bill SerGio
|
|
|
|
|
I was actually hoping to see a list of enhancements really.
EG, RichTextBox mite now contain a protected ScrollPosition property, something I had to add myself.
Give them a chance! Do it for the kittens, dear God, the kittens!
|
|
|
|
|
I'm sure that they're somewhere....maybe on MSDN.
Your bullshit is so effusive I can smell it across oceans...
You impress no-one. You are a world-class sleazeball; an incomparable jerk. No-one is fooled by your idiotic attempts to slant votes.
-A. N. Onymous on Bill SerGio
|
|
|
|
|
Eric Gunnerson (msft) wrote:
(Please note: you should expect a 24 delay between registering at the site and being able to download the beta.)
Hi Eric, I was wondering why my delay is taking 93 hours? Maybe I should re-register. Anyone else recieved there mails yet?
Give them a chance! Do it for the kittens, dear God, the kittens!
|
|
|
|
|
|
I've searched here but no found. I wonder if anyone has created a control that look like the drop down detail view (in folder view mode, no tree) on the left panel of Windows XP's window explorer?
Thanks.
|
|
|
|
|
|
No. It's not the tree control I was looking for.
When you click "folders" toolbar button from window explorer, it changes to folder view, then on the left side, there is the detail panel which displays information about files and folder, also the down arrow on the upper right corner serves a drop down function.
It's only available in Windows XP.
|
|
|
|
|