|
Ya bro.... i understand what u r telling, bt im new at c# coding so facing problems.
|
|
|
|
|
Please, don't use textspeak here - it can really annoy people, and that reduces your chances of getting a helpful answer.
I can't help you fix your code - I don't have a clue what you have written, and I couldn't run it if I did as I haven't got your data either - so it's going to be up to you.
Start with the "original" code - I'm pretty sure you didn't write it all - and look ate what is happening with the data there. Then look at what the code you added does to that data: that should give you clues as to what you are doing wrong.
Those who fail to learn history are doomed to repeat it. --- George Santayana (December 16, 1863 – September 26, 1952)
Those who fail to clear history are doomed to explain it. --- OriginalGriff (February 24, 1959 – ∞)
|
|
|
|
|
Because you read past the end of the file?
Without seeing the bigger code that this is a part of it's impossible to tell you what you did wrong.
|
|
|
|
|
Have you attempted to retrieve anything from the stream yet? If not, add the following beforehand:
m_Stream.Position = 0;
|
|
|
|
|
I have an application that calls the run prompt, but the OS puts the run prompt in a strange location. I can't seem to identify the hWnd of the window so that I can use pin invoke commands to move it?
Has anyone ever been able to identify the run prompt window and send a command to the OS to move it?
64bit
c:\Windows\SysWOW64\rundll32.exe shell32.dll,#61
32bit
c:\Windows\System32\rundll32.exe shell32.dll,#61
|
|
|
|
|
Ummm....why?
It's a Window that belongs to Explorer.
Also, anything you do in the Run window can be done with Process.Start(). What's with the obsession with the Run window?
|
|
|
|
|
Explorer is putting the prompt in an odd location and I would like to be able to control that.
I've created a GUI toolbar for server 2012, which is why process.start isn't an option in this case as a replacement for a GUI prompt.
|
|
|
|
|
turbosupramk3 wrote: xplorer is putting the prompt in an odd location and I would like to be able to control that.
There is a problem in Explorer that is causing it. I have no idea what the cause of the problem is though. What I've done to "fix" it is to login at the console as a new user that has never logged in on the machine before. Hit Win-R to bring up the window and it always shows up in the proper place. I then logout and back in again as the user affected, and it's fixed.
I've only seen this happen twice - ever.
You're trying to code around a problem, not fixing the problem.
turbosupramk3 wrote: I've created a GUI toolbar for server 2012, which is why process.start isn't an option
That makes no sense. If you're replacing something (you don't specify what) then that makes Process.Start even more effective as a solution.
|
|
|
|
|
It makes perfect sense. I've created a GUI tool bar since server 2012's version sucks. Part of that is familiarity, and one of the buttons I have calls the run prompt via the code I posted in my first post, which does use process.start behind the scenes to make that call. Click on the button for that and up the old familiar run prompt comes. I do not know why Windows places it on screen where it does, but I'd like to move it dependent on where a user puts the tool bar at on screen and not have that static odd ball location.
Now, do you know how I can move this Explorer shell window? Spy++ can see a window handle for it and I can drag it around the screen manually ... usually when I can do something manually, I can do it programmatically.
|
|
|
|
|
Get the name of the window, verify it in Spy++, and you can find it with this[^].
Once you have the handle you can set it's position with SetWindowPos[^].
|
|
|
|
|
Thanks Dave. I tried something like this by iterating through the processes, I will try with that example and report back tomorrow.
|
|
|
|
|
I believe the MainWindowHandle value of 0 is what is making this tough for me. Here is what I am seeing and this is what I had encountered before, no way to rectify what I'm seeing in spy++ to what I have when I enumerate through the process information. I still think the limitation is me though and not Windows or else how would spy++ have the alphanumeric value in the handle box?
http://s26.postimg.org/jlajsrx49/run_Prompt_Step_Through1.png[^]
|
|
|
|
|
You haven't said how you are trying to get the handle of the Run window but it is possible with the native function EnumWindows.
using System;
using System.Diagnostics;
using System.Runtime.InteropServices;
public class ProcessWindowFinder {
[DllImport("user32.dll", SetLastError = true)]
[return: MarshalAs(UnmanagedType.Bool)]
static extern bool EnumWindows(EnumWindowsProc callbackMethod, IntPtr state);
[DllImport("user32.dll")]
static extern UInt32 GetWindowThreadProcessId(
[In] IntPtr hwnd,
out UInt32 processId);
delegate bool EnumWindowsProc(IntPtr hWnd, IntPtr state);
public void FindWindows(Process selectedProcess) {
EnumWindows(SelectWindowsByPID, (IntPtr)selectedProcess.Id);
}
private bool SelectWindowsByPID(IntPtr hwnd, IntPtr state) {
Int32 pid = state.ToInt32();
Int32 windowPid = GetWindowPID(hwnd);
if (pid == windowPid) {
}
return true;
}
private Int32 GetWindowPID(IntPtr hwnd) {
UInt32 PID;
GetWindowThreadProcessId(hwnd, out PID);
return unchecked((Int32)PID);
}
}
The callback function SelectWindowsByPID filters the handles down to those belonging to the selected process, in your case rundll32. You could filter further by window text (native GetWindowText) and visibility (native IsWindowVisible) but I think that final application specific filtering should really be done outside the ProcessWindowFinder class which is why I suggest raising an event.
Alan.
|
|
|
|
|
Hi Alan,
Thanks for the reply. I'm trying to figure which function to plug information into, to test the code you posted.
If it is EnumWindowsProc(IntPtr hWnd, IntPtr state);, I don't have the hWnd? Can you lead me a long a little more please?
|
|
|
|
|
For some reason, you seem obsessed with passing a window handle into a function to find another window handle. You just need the Caption of the window:
[DllImport("user32.dll", SetLastError = true)]
static extern IntPtr FindWindow(string lpClassName, string lpWindowName);
private void button1_Click(object sender, EventArgs e)
{
IntPtr runHandle = FindWindow((string)null, "Run");
Debug.WriteLine(string.Format("Run window handle: {0}", runHandle.ToString()));
}
|
|
|
|
|
I'm not obsessed with anything but learning. Here is what the IDE told me when I tried that code.
"Unable to find an entry point named 'FindWindow' in DLL 'user32.dll'."
|
|
|
|
|
What does your copy of the code look like? FindWindow has been in user32.dll since the beginning of Windows.
|
|
|
|
|
I closed and reopened the solution and it worked? Thank you for this, it was such a simple solution, I believe I tried something similar before originally posting but if I remember correctly I would always get a handle of 0 ... it turns out there is a slight delay/lag so before FindWindow will work on a spawned process, as the process has to load. I was not able to figure that out before, but was after you posted your code. Thank you.
@Alan, if you read this, I would still like to learn how your class ties together, and how it could be tweaked. 
private void btnTest_Click(object sender, EventArgs e)
{
Process p = Process.Start(@"c:\Windows\System32\rundll32.exe", "shell32.dll,#61");
int timeOutCounter = 0;
IntPtr runHandle = IntPtr.Zero;
do
{
runHandle = FindWindow((string)null, "Run");
Thread.Sleep(100);
timeOutCounter = timeOutCounter + 1;
} while ((runHandle == IntPtr.Zero) && (timeOutCounter < 30));
if (runHandle != IntPtr.Zero)
{
SetWindowPos(runHandle, 0, 800, 800, 425, 235, 0X4 | 0x0040);
}
}
|
|
|
|
|
OK,
The only public method in the class is FindWindows. It calls the native EnumWindows method which enumerates all top level window handles and for every window handle found a callback method is invoked. The method, which has the signature bool EnumWindowsProc(IntPtr hwnd, IntPtr state), is SelectWindowsByPID.
So some code that starts the process you are interested in and then enumerates the window handles,
Process p = Process.Start(@"c:\Windows\System32\rundll32.exe", "shell32.dll,#61");
ProcessWindowFinder finder = new ProcessWindowFinder();
finder.FindWindows(p);
On my system 267 window handles were found and SelectWindowsByPID was invoked once for each of those handles. The filtering by process ID showed that only 3 were associated with the rundll32 process.
To determine which of those 3 handles identifies the "Run" window use the native GetWindowText function. There is an example c# method on pinvoke.net http://www.pinvoke.net/default.aspx/user32/GetWindowText.html[^]. For testing insert your code inside the if block where I inserted the comment // Do something here.
Alan.
|
|
|
|
|
Hi Alan,
This is quite humbling. I honestly cannot figure out how to modify your class, ashamedly.
What I am trying to do is to get the class to return a list of hwnds and pids and then I was going to use GetWindowText to narrow down the proper hwnd while parsing through that list, as I am getting 4 or 5 handles found. This may be the wrong way to go about this, and this might be why I am having such trouble with it.
Using a Messagebox.Show in place of the // Do something I was able identify the proper pid and handle associated with it, but embarrassingly, I cannot figure out how to create an array of some sort, add each handle found and then return it to my calling function so that I can then parse through the returned data. I cannot figure out how this part of the code works
EnumWindows(SelectWindowsByPID, (IntPtr)selectedProcess.Id);
when SelectWindowsByPID requires two parameters by delclaration
IntPtr hwnd, IntPtr state and I see that it somehow interacts with a static extern, which I have never used before. I apologize for my ignorance, but I'm self taught and apparently have discovered a large hole in my learning.
|
|
|
|
|
I see you've got Dave's FindWindow suggestion working and it's certainly a lot simpler than my method.
As you asked about EnumWindows here goes, although you may have to do some reading yourself, as getting callback functions to work reliably requires some advanced techniques.
First part of the answer on how EnumWindows works
EnumWindows(SelectWindowsByPID, (IntPtr)selectedProcess.Id);
The .NET program calls EnumWindows and supplies a method that will be called by Windows for every handle that is found. This is the callback method, the c# signature of which is fixed as
delegate bool EnumWindowsProc(IntPtr hWnd, IntPtr state);
Windows sets the first parameter to the window handle it has found. The second parameter is a copy of the second argument supplied to EnumWindows, which provides a way for the programmer to pass information into the callback. I've used it to pass in the process Id.
Fully operational examples have additional complexity as it is essential to stop the .NET garbage collector moving any object that is referenced by the callback function. Rather than modify the original code I'll show you a complete class that gives a list of window handles.
using System;
using System.Runtime.InteropServices;
public class ProcessWindowList2 : System.Collections.Generic.List<IntPtr> {
[DllImport("user32.dll", SetLastError = true)]
[return: MarshalAs(UnmanagedType.Bool)]
private static extern bool EnumWindows(EnumWindowsProc callbackMethod, IntPtr state);
private delegate bool EnumWindowsProc(IntPtr hWnd, IntPtr state);
[DllImport("user32.dll")]
private static extern UInt32 GetWindowThreadProcessId(
[In] IntPtr hwnd,
out UInt32 processId);
private readonly Int32 pid;
private static Int32 GetWindowPID(IntPtr hwnd) {
UInt32 PID;
GetWindowThreadProcessId(hwnd, out PID);
return unchecked((Int32)PID);
}
private static Boolean SelectWindows(IntPtr hwnd, IntPtr state) {
GCHandle gch = GCHandle.FromIntPtr(state);
ProcessWindowList2 list = (ProcessWindowList2)gch.Target;
Int32 windowPid = GetWindowPID(hwnd);
if (list.pid == windowPid) {
list.Add(hwnd);
}
return true;
}
public ProcessWindowList2(Int32 processId) {
this.pid = processId;
EnumWindowsProc callback = new EnumWindowsProc(SelectWindows);
GCHandle gch = GCHandle.Alloc(this);
try {
EnumWindows(callback, GCHandle.ToIntPtr(gch));
} finally {
gch.Free();
}
}
}
This is a modified version of published code http://msdn.microsoft.com/en-us/magazine/bb985713.aspx[^]. It's derived from List<IntPtr> but has a special constructor that populates the list with handles. The code makes use of GCHandle.Alloc(this) to inform the garbage collector that objects of this class must not be moved until GCHandle.Free is called. This is essential for the safe operation of the callback.
Using the class is very simple
Process p = Process.Start(@"c:\Windows\System32\rundll32.exe", "shell32.dll,#61");
ProcessWindowList2 hwndList = new ProcessWindowList2(p.Id);
foreach (IntPtr hwnd in hwndList) {
}
Have fun!
Alan.
|
|
|
|
|
Thank you very much for taking the time to explain this Alan. This is completely new to me and I have a lot to read and learn about, but each time I read your post it becomes a little more clear. Hopefully I'll be able to come back and read this in a few weeks and understand it fully as I fill in this hole in my c sharp knowledge.
-Brad
|
|
|
|
|
|
You could, but EF already wraps every batch of updates (when you call DbContext.SaveChanges) in a transaction by itself.
You get more control over this process if you're using EF6.0 or above. Read this[^] for more information.
Before you get into doing your own transactions you might want to read this[^].
|
|
|
|
|
i know this but problem with this is mostly these calls are in DAL.
IN General you call ur business function from controller and there are multiple calls made which should be in transaction e.g.
using(Transaction.....)
{
BLL.SomeFunction1()
BLL.SomeFunction2()
}
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
