|
This is going to be a huge pain to do. The DGV was designed to have a single display control and edit control in any one column. What you would have to do is create your own custom DatGridViewColumn classes that determines which edit control to display based on some criteria. You can find an example of creating a custom column here[^]. Note that doing this requires three seperate classes.
|
|
|
|
|
hi members
I want to retrieve the application path of program which is currently running in task manager, please help me.
|
|
|
|
|
System.Diagnostics.Process.GetProcessesByName will give you access to the process.
Call .MainModule.FileName will return the full path to the exe.
|
|
|
|
|
To Get path of running Application listen in TaskManager you can use Given Code
Take a List box and a Button and write given code in click event of button.
foreach (Process p in Process.GetProcesses())
{
string procFile;
try
{
procFile = p.Modules[0].FileName;
}
catch (Win32Exception ex)
{
procFile = ex.Message;
}
listBox1.Items.Add(string.Format("Process {0}: {1}", p.ProcessName, procFile));
}
|
|
|
|
|
Hello coders,
I've been wondering this for some time, but haven't been able to find an answer to: How does DoEvents actually work (technically seen)?
The way I look at it, you have this picture describing your single-threaded application:
[ Your code ]
[ Translation to .NET events ]
[ Message Pump ]
With basically messages coming in from Windows at the Message Pump level, then advancing up until it reaches your code in terms of Events. Your code runs etcetera, and whenever execution 'pauses' (e.g. disappears when debugging), the message pump gets execution again and handles messages. Somewhere parallel is the garbage collector, asynchronously cleaning up your mess in collect 'n reap batches. Am I at least right about this picture (if not, then my question might not make sense)?
The actual question then is: how does DoEvents, called from your code, manage to fall back into the Message Pump? I'd think you need to re-enter the calling function, so basically advance through the stack back to the caller, without losing all the context allowing you to move up to your original point of execution. That means that a simple call to the message pump 'function' would not be the way to, because then it would end up a top of the stack.
One solution to this I was thinking of was to use something like SendMessage(WM_USER_IDLE, ...) to get back into the message pump, but is that even possible/allowed? Does anyone know the answer, because I am REALLY curious
Thanks for reading my rant, and I'll hope you have some answers,
Richard
|
|
|
|
|
There is no such thing as "the message pump", i.e. you can have as many pumps as you like.
Example: when you show a dialog, it has its own message pump, which processes messages related to the dialog and ignores the others.
DoEvents() looks like yet another message pump, which processes everything until there are no more messages, then returns. And it is pretty dangerous to call DoEvents() from within an event handler, as it may cause that very handler to be called again, i.e. it may re-enter which you probably did not intend nor anticipate.
|
|
|
|
|
So it really is another message pump (quite like the original) atop of the call stack? For some reason, I felt it couldn't be that, but don't know exactly why. Probably because this new message pump would have to have the same behaviour as the original. I guess it's possible in an environment like .NET (or VB runtime before that).
Thanks for your answer.
|
|
|
|
|
Luc Pattyn wrote: you can have as many pumps as you like.
Correct.
Luc Pattyn wrote: a dialog, it has its own message pump
In general not correct. However, modal dialogs usually have their own message pump.
Time you enjoy wasting is not wasted time - Bertrand Russel
|
|
|
|
|
that is what I meant, to me a dialog is a modal window and a modal dialog a tautology.
|
|
|
|
|
Windows under the hood is still basicaly a non-preemptive multitasking OS, meaning that on a given processor core, individual threads are allocated execution time slices by the system one at a time. During your thread's slice of time, your application has the core and can execute as long as it sees fit, returning to the system when you are done. In such an OS for an application to "play nice" with others, if you running a long execution, you would intersperce your code with DoEvents (especially if you have a long running loop, you put a DoEvents in the loop) to allow the OS to have a timeslice to perform it's housekeeping routines, send pending messages, etc.. In other words, DoEvents allows your code to return execution to the OS for a timeslice then execution returns to you where you left off. This is especially handy if you are coding a Windows Forms app that updates it's screen elements as your code is running (example a progress bar). If you don't allow the OS a timeslice to send messages to your program to re-draw, your window will seem to freeze untill your long running process is finished and execution is returned to the OS (your app's screen won't redraw).
Kevin Rucker, Application Programmer
QSS Group, Inc.
United States Coast Guard OSC
Kevin.D.Rucker@uscg.mil
"Programming is an art form that fights back." -- Chad Hower
|
|
|
|
|
Spectre_001 wrote: Windows under the hood is still basicaly a non-preemptive multitasking OS
I don't agree. The Windows kernel is event driven, is priority based, is pre-emptive, has fairness implemented, and contains some protection against CPU monopolizing processes. There is no need to call DoEvents(), or anything else, at all to get things to work properly. Here is a simple test: create a process that contains a long computation and have it optionally generate output while computing; now run a number of instances and watch how each of them is proceeding.
Windows is not a real-time OS, which means it is not guaranteeing much on latency; however it does not need the user's cooperation to provide a good interactive user experience. There are ways to make an app behave badly, one of them would be to execute long or blocking stuff on a WinApp's main thread; and there are ways to make an app fail, one of them is calling Application.DoEvents() causing code to get re-entered while it wasn't designed for re-entrance to start with.
BTW: none of the misbehavior mentioned (block GUI thread, call DoEvents) would negatively affect other processes.
|
|
|
|
|
I thought this question was going to be about the access function (does the same kind of thing)
*shudders at recollection of coding in access*
---Guy H  ---
|
|
|
|
|
Guy Harwood wrote: *shudders at recollection of coding in access*
Ahh the heady days of my youth spent coding VBA... I can barely remember what it was like to end a line of code without a semicolon and have a hard time doing it when I wander into VBA to trick out a macro in Excel for a co-worker these days. Makes me feel old to think of how long ago that was (mid 90's). 
Mike Devenney
|
|
|
|
|
Reflector is your friend:
public static void DoEvents()
{
ThreadContext.FromCurrent().RunMessageLoop(2, null);
}
If you keep poking deeper, you see that it's just running a message loop to handle any messages that might have been sent.
|
|
|
|
|
I beleive DoEvents call moves the pointer on the call stack to where the Windows Messages are, saving the current point and then returning to it after the windows messages are processed.
Of course not this over simplified but I beleive the logic works this way...
|
|
|
|
|
That is not correct. The Windows Message queue is not "on" the stack. No weird call stack operations are performed.
For .Net Application.Run() and Application.DoEvents() are somewhat similar in that they both call a message pump. A message pump could be very simply be:
MessagePump()
{
while ( true )
{
Message msg = GetMessage();
DispatchMessage( msg );
if ( msg.Msg == WM_QUIT ) break;
}
}
The code behind DispatchMessage will eventually call your events, e.g. when a button is clicked.
If you then do a form.ShowDialog() it will re-enter the message pump function (recursively, the previous call just stays on the call stack).
This is why showing a message box in a timer event handler will result in stacking up message boxes until resources are exhausted or a stack overflow occurs.
The call stack will look something like this (looking at it top-down) :
Application.Run
MessagePump
DispatchMessage
... framework stuff ...
Timer1.TimerEvent
SomeForm.ShowDialog
Application.DoEvents
MessagePump
DispatchMessage
... framework stuff ...
Timer1.TimerEvent
SomeForm.ShowDialog <-- if you indeed do this call then this will repeat until...
modified on Wednesday, September 8, 2010 2:36 PM
|
|
|
|
|
That's exactly what I meant, for example, if our heavy processing code is inside DispatchMessage, it might simply do "Goto address 1" as exemplified below and push the current address on the stack so it can be popped after the goto call finishes:
MessagePump()
{
while ( true )
{
Adr 1 Message msg = GetMessage();
Adr 2 DispatchMessage( msg );
Adr 3 if ( msg.Msg == WM_QUIT ) break;
}
}
Again, that's how I think it works.
|
|
|
|
|
This is low level Windows API view, not sure how dotNET sits on top.
1. Each Thread can have its own message pump if needed. If you have windows created on multiple threads, they can run separately. (97% sure)
2. A modal dialog must provide a new message pump, because it is called from the current stack of the "calling" message pump. The "calling" message pump is frozen until the modal dialog's pump exits. This is how you can get a return value from the Modal dialog during the event dispatching of the calling pump. This is also the case with Menus. The event handler for the menu is called from a different pump.
3. Prior to Windows XP(?), the only way to share the cpu with other Windows apps was when calling GetMessage() or PeekMessage(). It really was "play nice or don't play at all." You had to make sure that you "chunked" background work in such a way that you invoked PeekMessage() occasionally.
I am pretty sure that even Windows 95/98?/ME? were 32bit wrappers around the same old Windows 1.0 core. Pre-emption was enforced on DOS virtual machines, but all Windows apps ran in the same VM. This was great because you could actually locate and read memory structures out of other running programs on the system! WinNT families were pre-emptive and full protected memory spaces out of the starting block. There is probably a windows genealogy somewhere that says when certain features were introduced when.
|
|
|
|
|
I'm surprised that no one has pointed to MSDN for this: http://msdn.microsoft.com/en-us/library/system.windows.forms.application.doevents.aspx[^]
I know MSDN isn't always helpful, but it tells you what it does as well as when to use it and when not to use it.
Realistically, most circumstances where it is not safe to call DoEvents indicates that you are doing something wrong (such as raising the event in its own handler). Note: the emphasis is on "most" since there are exceptions to almost every rule.
I don't claim to be a know it all, for I know that I am not...
I usually have an answer though.
|
|
|
|
|
MSDN unforunately doesn't say HOW it does it, which was what I wanted to know.
I pretty much always check MSDN; I find it very helpful.
I already have a lot of experience using DoEvents in a correct way in VB6. With .NET I much prefer a worker thread though, for many reasons.
Thanks for all the responses
|
|
|
|
|
Hello All ,
I have used a CalendarExtender in my page with textboxes. When I press enter key in another textbox, calendar's popup is appearing.
I have used defaultbutton attribute in form tag and tried keeping my button id as defalut button but this is also not working.
Please help me out in same..
Thanks In Advance
|
|
|
|
|
Sorry, but you chose the wrong forum for your repost. You should be asking this in the ASP.NET[^] forum.
|
|
|
|
|
Hi all,
I am doing a very simple operation via c#.
1 I just copy an existing JPEG file in temp directory.
2 Then I open the copied Jpeg file from temp directory.
3 I try to delete the original Jpeg file and application crashes.
Please see below c# function for this:
using System.IO;
public void DeleteAfterCopyingOriginalImageFile(string strOriginalJpeg)
{
string strTempFolder = System.IO.Path.Combine(System.IO.Path.GetTempPath(), "JpegTemp");
if (!Directory.Exists(strTempFolder))
{
DirectoryInfo directory = Directory.CreateDirectory(strTempFolder);
directory.Attributes = directory.Attributes | FileAttributes.Hidden;
}
string strTempJpeg = System.IO.Path.Combine(strTempFolder, "TempImage.jpg");
if (!File.Exists(strTempJpeg))
{
File.Copy(strOriginalJpeg, strTempJpeg);
}
Process.Start(strTempJpeg);
File.Delete(strOriginalJpeg);
}
I need to follow exactly these steps (cannot delete original file before opening TempImage.jpg). Can anybody help in knowing why copy and opening of temp file lock the original file. How can I prevent original jpeg file from being locked. I am new in .Net. Please help me.
More Info about the user case: The user case is that user cannot perform any operation on original file. So a temporary copy of original file is created in temp folder. User can then open/edit temp file. And if he thinks that he can replace original file with that of edited (copied in temp directory) one or he does not need original file any more, he can delete original file (and if required, can make temp file as the original one). So I strictly need to follow the same steps.
Regards
Aseem
Thanks in Advance
|
|
|
|
|
DO NOT cross post or repost you question.
You have received responses to your original post. Posting again will not allow others to see all the context and what has been tried already.
Read "How to get answers..." at the top of this forum!
I know the language. I've read a book. - _Madmatt
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
