|
I thought it was you
Give them a chance! Do it for the kittens, dear God, the kittens!
|
|
|
|
|
Thank you
|
|
|
|
|
What is the best way to implement manual scrolling in a textbox?
The problem I'm having is getting the scroll bar position to "align" to the text. Particulary the last line/end of line....
I guess the whole issue is around what size I must chose for my scroll bar range. Should that be equal to my content size - visible size, or be equal to the numbers of lines - visble lines, all assuming content size is bigger than the visible size? If lines, how do I handle the horizontal scroll bar then?
Thanx
Give them a chance! Do it for the kittens, dear God, the kittens!
|
|
|
|
|
How would you create a text within a Console app, which would be a different color such as red?
--Stickman
|
|
|
|
|
Have a search in the GotDotNet.com 's userfiles area for ConsoleEx, cant remember if its VB.NET or C# , but it has quite alotta cool functions, something small did bother me, but I cant remeber what now...
Give them a chance! Do it for the kittens, dear God, the kittens!
|
|
|
|
|
|
i have created a form in c#
when i press ctrl+Break it destroy.
and an exception occure.
who to get rid of that?
i want when i press ctrl+break then it does not do any thing.
can any body give the solution of it?
r00d0034@yahoo.com
|
|
|
|
|
I believe that only happens when you run the program under a debugger; I tried out two different programs (without running it from within VS.NET) and neither of them stopped execution.
James
"And we are all men; apart from the females." - Colin Davies
|
|
|
|
|
please read that code and solve my problem.
Given after that code.
//////////////////////////////////////////////////////////
public class Win32Hook <br />
<br />
{ <br />
<br />
[DllImport("kernel32")] <br />
<br />
public static extern int GetCurrentThreadId(); <br />
<br />
<br />
<br />
[DllImport( "user32", CharSet=CharSet.Auto,CallingConvention=CallingConvention.StdCall)] <br />
<br />
public static extern int SetWindowsHookEx( HookType idHook, <br />
<br />
HOOKPROC lpfn, <br />
<br />
int hmod, <br />
<br />
int dwThreadId <br />
<br />
); <br />
<br />
<br />
<br />
public enum HookType <br />
<br />
{ <br />
<br />
WH_KEYBOARD = 2 <br />
<br />
} <br />
<br />
public delegate int HOOKPROC(int nCode, int wParam, int lParam); <br />
<br />
<br />
<br />
private HOOKPROC hookProc;
<br />
<br />
<br />
public void SetHook() <br />
<br />
{ <br />
<br />
<br />
hookProc = new HOOKPROC(this.MyKeyboardProc); <br />
<br />
<br />
<br />
SetWindowsHookEx(HookType.WH_KEYBOARD, hookProc, 0,<br />
GetCurrentThreadId()); <br />
<br />
<br />
<br />
} <br />
<br />
<br />
<br />
public int MyKeyboardProc(int nCode, int wParam, int lParam) <br />
<br />
{ <br />
<br />
<br />
return 0; <br />
<br />
} <br />
<br />
}<br />
<br />
<br />
To install the hook procedure <br />
<br />
Win32Hook hook = new Win32Hook(); <br />
<br />
hook.SetHook();
//////////////////////////////////////////////////////////
Above code is 100% correct but my problem here is that I want to execute it for each thread for that purpose I modify a line of code and that is
SetWindowsHookEx (HookType.WH_KEYBOARD, hookProc, IntPtr.Zero,0 );
But after changing that line of code it does not solve my problem because MyKeyboardProc function does not execute its code.
I don’t know why? Can any body give its solution?
r00d0034@yahoo.com
|
|
|
|
|
hi,
i'm using udp on sockets and wonder how to set a timeout on receiving? haven't found anything on that issue...
sometimes it happens, that there is no connection or packets get lost and i really need a configurable timeout here.
possible workaround would be to have the calling thread install a timer, and if the child-thread isn't done with his communication-things, he's aborted (-9 so to say ). but it would be nicer if there is a timer somewhere within the socket-internals...
any idea?
:wq
|
|
|
|
|
Rüpel wrote:
possible workaround would be to have the calling thread install a timer, and if the child-thread isn't done with his communication-things, he's aborted
If the thread is blocked in UdpClient.Receive() or UDP Socket.ReceiveFrom(), then calling Abort on the thread will not stop it until the blocked method returns. To stop it, after calling Thread.Abort, you have to send a datagram to yourself for the thread to unblock. Then it will be aborted.
-- LuisR
──────────────
Luis Alonso Ramos
Chihuahua, Mexico
www.luisalonsoramos.com
"Do not worry about your difficulties in mathematics, I assure you that mine are greater." -- Albert Einstein
|
|
|
|
|
...you have to send a datagram to yourself for the thread to unblock...
i've tried, but it doesn't seem to work.
what's wrong with this little console-application?
<br />
[STAThread]<br />
static void Main(string[] args)<br />
{<br />
Class1 foo = new Class1();<br />
foo.MainLoop();<br />
}<br />
<br />
public void MainLoop()<br />
{<br />
Thread listener = new Thread(new ThreadStart(Listen));<br />
listener.Start();<br />
<br />
UdpClient sender = new UdpClient();<br />
IPEndPoint self = new IPEndPoint(IPAddress.Loopback,7789);<br />
sender.Send(new byte [] {0x01},1,self);<br />
<br />
while (listener.IsAlive) ;<br />
}<br />
<br />
void Listen()<br />
{<br />
UdpClient ear = new UdpClient();<br />
IPEndPoint remote = new IPEndPoint(IPAddress.Any,0);<br />
ear.Receive(ref remote);<br />
Console.WriteLine("Got some Input from {0}",remote);<br />
}
:wq
|
|
|
|
|
just a little bumpage , in case someone thinks: "hey this is just a 'question-answer-thx'-thread and i don't have to look at it"
if that gets fixed, i'm ready to post my first article here on codeproject. so could anyone please give me an idea?
:wq
|
|
|
|
|
Try this:
(for a 10 seconds timeout)
ear.Client.SetSocketOption(SocketOptionLevel.Tcp, SocketOptionName.ReceiveTimeout, 10000);
"In an organization, each person rises to the level of his own incompetence." Peter's Principle
|
|
|
|
|
hey, this looks cool. will try it tomorrow
although i will try SocketOptionLevel.Udp instead of Tcp first
thx anyway.
:wq
|
|
|
|
|
at first, both SocketOptionLevel.Udp and SocketOptionLevel.Tcp raise an exception when being used with SocketOptionName.ReceiveTimeout . it seems you have to use SocketOptionLevel.Socket instead.
but that even doesn't help. the Receive() -function still blocks. i don't know what that ReceiveTimeout is for
:wq
|
|
|
|
|
now i did a 'hack' that works for me.
public class TimedUdpClient : UdpClient
{
private int timeout = 1000;
private Thread timeoutWatchdog;
public int Timeout
{
get { return timeout; }
set { timeout = value; }
}
public new byte[] Receive(ref IPEndPoint remote)
{
timeoutWatchdog = new Thread(new ThreadStart(StartWatchdog));
timeoutWatchdog.Start();
try
{
byte[] ret = base.Receive(ref remote);
return ret;
}
catch (SocketException)
{
return null;
}
}
private void StartWatchdog()
{
Thread.Sleep(timeout);
this.Send(new byte[] {0x00},1,"",8000);
}
}
my little test-program from two or three postings above didn't receive the packets since they have to be sent on the same socket (at least i believe that). when this byte from my watchdog is sent, there's an exception ("connection closed by remote" or something like that) raised somewhere inside UdpClient.Receive() . it would be nicer, if it would just receive the byte and one could distinguish by the sender, if that packet was sent by the watchdog (thus, on the same socket) or comes from outside. UDP is a connectionless protocol, so i'm not sure, how such a connection-closed-excpetion may occur, but actually it does
anyways. all i wanted, was stop Receive() from blocking and this way it works.
thx to everyone that helped. (also the ones that read, thought and had no idea)
:wq
|
|
|
|
|
|
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!
|
|
|
|
|