|
I'm presently working on a small application and I'm really stuck .
The app takes a frame sent by my webcam, do something on it (in that case, add a VRML object to the scene) and proceed to the next frame. I can communicate with the app using keyevent(ie. 'esc' quit the application, 'm' put som info on stdout, etc) in the main loop. However, I'd need to pause and resume that mainloop when some event occurs (ie after typing 't' to translate a volume, the user must enter how long is the translation...).
Any ideas?
I'm using C++ Visual Studio .NET 2003
Jean_ni
|
|
|
|
|
What does this have to do with this topic?
---
maximum 500 characters
|
|
|
|
|
I want to suspend/resume process on Win95, how to do?
|
|
|
|
|
Sorry, I can't help you, as I don't code on Win95 since, erm, mmm... 95. Wow, it has been 9 years already!
At least MSDN says that you can do OpenProcess, SuspendThread and ResumeThread on Win95, so I suspect that the problem is happening with my process listing code. Try to pass a known PID and see if it works...
Perl combines all the worst aspects of C and Lisp: a billion different sublanguages in one monolithic executable. It combines the power of C with the readability of PostScript. -- Jamie Zawinski
|
|
|
|
|
OpenThread API unsupported on Win95
|
|
|
|
|
There is a piece of software that, unlike Windows Taskmaster, does allow you to both see and suspend/resume processes. At least I think it has the same functionality you describe - I am myself no programmer.
It is called Process Explorer, copyright Mark Russinovich, from Sysinternals.com
It's been a great help to me in tracking down and suspending virus activitiy.
|
|
|
|
|
It is not possible at all since this feature is included in Windows NT, only.
|
|
|
|
|
While I want to suspend a thread in VC++,but return error code 0x00000005(Access denide),who know why?? thanks!
|
|
|
|
|
You need a simple app wizard gui.
Its like watching TV in black and white otherwise...
"An expert is someone who has made all the mistakes in his or her field" - Niels Bohr
|
|
|
|
|
If you want to quote people be respectfull and quote them right. Niels Bohr never mentioned "her" he wrote about "a man" ... You don't like it as he said it - don't quote him .
|
|
|
|
|
|
This sample is just a "Start".
All it does is produce a list of the various Processes currently running on your machine, which you could obtain anyway by using Task Manager.
It lacks an interface (e.g. checkboxes) by which the user could select which Processes he/she may want to suspend or resume.
I tried running it several times from Start->Run to see if I could cause it to suspend or resume Processes, and all I got, was a very quick flicker of the program indicating it had completed execution. IOW, I didn't have a chance to test for those other options.
If you are running VC++ 6.0, you will have to create your own Console Application project for this sample, because it was written for VC++ .NET, and the sample didn't come with a ".dsp" file.
If you were thinking of borrowing features from this sample to import into your own application, I cannot attest for its ability to do anything else, because I didn't get to see those features. The ONLY thing I know it does, is list Processes. That's it!
I did see code in there for it to suspend and resume Processes, (though I couldn't test them) but for everything else, meaning, any user interface, and the assigning of priorities to Processes (if that's something you might want to do after you've suspended one or several of them, etc.), you're on your own.
Lastly, if your Process name has more than two parts (e.g. System Idle Process), it will only report two (e.g. System Process).
William
|
|
|
|
|
It's a command line tool.
As such, you must run it from the command prompt.
Type cmd.exe at Start->Run and open a command prompt. Then use it from there.
But even if you use it PASSING THE PID from Start->Run it should pause a process.
It's a pitty people are so used to GUI applications that don't know how to use command line utilities anymore...
I'll provide a soon .dsp for VC 6.0 users. I didn't because I thought most VC6.0 users would use the Project Converter Tool[^]
"In an organization, each person rises to the level of his own incompetence." Peter's Principle
|
|
|
|
|
Daniel Turini wrote:
It's a pitty people are so used to GUI applications that don't know how to use command line utilities anymore...
Right, those youngsters are so unflexible
Soon, the knowledge of command prompts will be lost forever, when the last man knowing it passes away
--
Scanned MSDN Mag ad with YOUR name: www.magerquark.de/misc/CodeProject.html
See me: www.magerquark.de
|
|
|
|
|
I did recognize it was a Command Line tool, which is why I went to Start->Run and entered the full path of where the executable module was located, and ran it from there. That is how I got to see the flash of the list of Processes it displayed.
I was more fortunate in seeing the entire list without it disappearing on me when I ran it from the VC++ IDE.
But just to be fair and as thorough as possible, I did go back to Start->Run and following the pathname of where the executable module was located, I did append the PID of a utility that was currently running on my system, and received an error message from the system about not being able to locate the component.
When I removed the PID and ran just the pathname again, I could see the quick display of the list before it vanished. So I did try that effort as well.
Typing 'cmd.exe' to run a command line tool doesn't buy me anything more that what I am able to accomplish from Start->Run. AAMOF, it's preferable to run an application from Start->Run if that's all you want to do (which in this case was all I wanted to do).
Yes, I'll admit I am one of those people who prefer having a GUI with which to interface than having to revert back to the method we all had to deal with back there in the dark ages BEFORE GUI came along. GUI showed us there was a nicer and more convenient way of interfacing with the computer. (Pity those who refuse to come out of the darkness into the light.) For the extra effort going GUI requires, I don't mind it at all; I'll do it any day. It's either the lazy or the ignorant ones who continually bash GUI.
"Accept nothing short of perfection." The C++ Programming Language: 3rd Edition. Bjarne Stroustrup.
William
|
|
|
|
|
command line apps usually assume that they're being run from the command line (hence their name), and so will just exit when they finish. If you run such an app from start->run then the app will run, display it's output, and the windows will close the temporary console window.
If you actually want to see the output, then run it from a proper command prompt
--
Help me! I'm turning into a grapefruit!
|
|
|
|
|
> Pity those who refuse to come out of the darkness into the light.
Pity those who cannot figure out how to use a command line tool, despite the rather clear directions.
> It's either the lazy or the ignorant ones who continually bash GUI.
For one thing, using a command-line utility in a script is a lot easier to accomplish than trying to script a GUI-based one that was never intended for scripting anyway.
It's not a matter of coming out of the dark ages. It seems to me rather that you are unable to grasp the value of a command-line utility. Obviously you've never had any Linux experience. It's gaining popularity in case you haven't noticed, so I'd suggest getting used to working from a command prompt, 'cuz the command line utility is not about to die any time soon.
|
|
|
|
|
Grasp the value of "command line prompt" applications!!!!!! Is that all you can extol for "command line prompt" applications?
You've got to be kidding!!!!! What VALUE is there to grasp????? I've written and done my share of "command line prompt" applications years ago, and have no desire to revert back to the dark ages.
Open your eyes (and your mind while at it), and see for yourself that when given the choice of using a "command line prompt" or a GUI application, almost everyone choose the GUI one. That is a "no brainer"!! If users weren't happy and satisfied about using GUI systems (because it's nicer, more convenient and user-friendly to work with), the outcry would have been heard and known by now that there wouldn't be any GUI applications left around. Just use your brain and arrive at the conclusions yourself!!!!!
Not only are you one of the lazy and ignorant ones who bashes GUI (because you don't know how to program using it, and too lazy to learn), but you are also HYPOCRITICAL in your use of it. You bash it on one hand, but turn right around and use it.
In case you didn't know, you are up to your neck in the use of GUI by logging on to this website, and navigating its pages. All you do is click here and click there and things get done. And when you have to enter data, there is a window already prepared for you in which to enter the information, with the result waiting for you in a more pleasing and user-friendly setting. The ease and convenience of GUI surround you on this website everywhere you go, and everything you do. Still you bash it. If that isn't HYPOCRITICAL, then show us how superior "command line prompt" systems are, and write your own website using just "command line prompts", offering the services that this website does and lets see if it'll have the same kind of membership.
DO IT!!!!! PUT YOUR WORK WHERE YOUR MOUTH IS!!!!!
If you can't, then just shut up, OR go learn how to program using GUI.
William
|
|
|
|
|
WREY wrote:
DO IT!!!!! PUT YOUR WORK WHERE YOUR MOUTH IS!!!!!
If you can't, then just shut up, OR go learn how to program using GUI.
Hey, take it easy fellow. A console application is just a tool, like a GUI one. They try to solve different problems. This one was made to be used on extreme situations when poping fancy UIs could take forever, just like Kill.exe from the Resource Kit. I think we can see MS as the most successful GUI applications writer. And why do some of their applications are command line tools and do not have an UI? Why did they put on Windows XP several new console applications? Because they don't know how to do a UI? Because MS is lazy?
My latest articles:
XOR tricks for RAID data protection
Win32 process suspend/resume tool
|
|
|
|
|
The time it'd take me to write a Console application, I can spend less time using AppWizard and write a quick Windows GUI one, and have all the benefits of GUI provided for me, particularly if I might want to expand on its usefullness later.
Still there are times, (even) when I'm putting together a quick GUI program, that I know it's going to be a "throw away" sample. It'll serve its purpose and then put aside. On the rare occasions when I do write a Console application, it won't be for anything of significant benefit, it won't be for anything that I'll keep around, and it certainly won't be for anything that I'll share with the rest of the world.
Yes, much of the credit goes to MS for bringing out GUI and popularizing it, but they do not necessarily legitimize behaviors and trends. And yes, while I will make the distinction between MS (the company) and MS (its technical employees), I will say there are some who works there that are plain lazy and DUMB!!!! So I'm not going to say because MS does something, that MS is lazy, or not lazy. A distinction has to be made if you're going to use the company in that context.
William
|
|
|
|
|
Well, for each task there is the appropriate tool.
If you want to find out whether a specific computer is reachable inside the network, what do you do? Open the Explorer, go to My Network Places, and look for the computer?
I open the command line and type
ping <computername>
How do you determine the IP of your computer? Do you open the Network Connections folder, and open the Properties dialog for the specific connection?
I open the command line and type
ipconfig
Our product is composed of more than 100 projects, so we cannot create one big .dsw to compile it. Therefore we have a bunch batch files for compiling. It's pretty easy.
As you may see, there are several tasks where I really prefer the command line.
Regards
Thomas
Sonork id: 100.10453 Thömmi
Disclaimer: Because of heavy processing requirements, we are currently using some of your unused brain capacity for backup processing. Please ignore any hallucinations, voices or unusual dreams you may experience. Please avoid concentration-intensive tasks until further notice. Thank you.
|
|
|
|
|
Don't put your mind and waste your time with a ignorant/stubborn newbie (William) who cant't appreciate your work. If he can't understand, or at least accept the command prompt functionality, and the fact your code does not have GUI just because it quicly ilustrates/implements a programming technique and for that does not neeed have a GUI, he sure can't understand what your code is about anyway. He needs to address his social skill too beside programing skills..
|
|
|
|
|
William,
Chill. I'm not a GUI basher. I'm not sure where you got that impression from my post. I love GUIs as much as the next guy, in fact I've been writing apps with full-blown GUIs since the days of Windows 3.1 (so I know how to write them, thank you very much). Given the choice between using a GUI app and a command-line one, 99.9% of the time I'll choose the GUI app. Duh, you'll get no argument from me. As a matter of fact a few years ago I wrote an MFC-like library for DOS so I could write apps using CDialog, CButton, CListbox etc classes in old DOS text mode. You think I'm a "GUI basher" if I went through the hassle of writing such a library?
What I was pointing out (and you keep refusing to acknowledge) is that even in this day and age, command-line utilities still have their uses. I *never* said anywhere in my post (nor implied) that "GUI-based apps suck" and command-line apps are preferable (or "superior" as you put it). Gosh, reading your message, you'd swear I posted some holier-than-thou message. I didn't.
And, frankly, I don't know how you got onto this rant about GUIs and web sites and me being hypocritical. I'd say you just sound like a frustrated AOL newbie who can't figure out command-line utilities, but then you claim to have written your share of them. Fair enough, I'll give you the benefit of doubt. But I have a hard time believing, if you've really written a significant number of programs as you claim, that you can't recognize that sometimes having any GUI at all *doesn't even make sense*. For starters, and for your own edification, check some of the utilities in the various Windows resource kits.
|
|
|
|
|
Like you said, "I'll give you the benefit of doubt," I too, will give you the benefit of the doubt regarding some of your notions about me.
As a parting statement, let me focus in a bit more on "command line prompt" applications. What they do, or what benefits they serve, is not salient to my point. What is salient, is how they get activated, and the subsequent ways in which the users have to interface with them.
Do you remember when you were just learning how to program, Console applications were what you were using to understand how to do things, along with the syntax of the language? Invariably, at some point you had to write a little program that would display a menu with various choices and the subsequent processing that had to be done based on what choice was made. They were starting points and stuff of "yester-years."
However, as you became more confident, knowledgeable and proficient in your skills, Console applications no longer remained the mainstay of your efforts (at least, speaking for myself), and even when working with Windows applications, MS has provided a GUI for developers to used in the creating and testing of their programs.
Some of that technology can be emulated for your own personal use. For example, the "Open" icon on the toolbar (which is a GUI) gives you a window (another GUI) with a tree structure from which you can point and click to the drive, directory and subdirectory (all GUI's) for a file you need. Contrast that to a Console application where you'd have to type in all the information about the drive, directory (etc.) of the file you need, along with the real possibility of mistyping and committing numerous errors. Which way is preferable? (For me who likes to give discriptive names to my directories and files [etc.], typing all those information for a Console application doesn't make it difficult for me to choose which is preferable.)
That's just an example. IOW, if it MUST be a Console application it could still be activated within a GUI setting.
FWIW, I have NEVER been a subscriber to AOL.
William
|
|
|
|
|
William,
I'm glad you're presenting your argument in a much more rational and level-headed manner than your previous post. Let me go over this one. I promise no hostility, and no AOL name-calling.
> Do you remember when you were just learning how to program, Console
> applications were what you were using to understand how to do things, along
> with the syntax of the language? Invariably, at some point you had to write
> a little program that would display a menu with various choices and the
> subsequent processing that had to be done based on what choice was made.
> They were starting points and stuff of "yester-years."
Ok, now I see where you're coming from. You're discussing the old text-mode DOS applications where each programmer had to design his own (and rather inconsistent) interface. Text menus and text navigation...yuck! I'm *totally* with you on this one. Anyone still intentionally designing his own little text mode menus-based apps in this day and age should *not* even be in this business--or at least should not be writing applications professionally.
When I talk about "command-line utilities" that still have some use today, what I have in mind is utilities that you launch with a command, might pass a few parameters to, and then it does its job and shuts down--the sort of utility that has no need for user interaction once it's launched.
An example of this would be XP's defrag.exe, versus the graphical defragger (dfrg.msc). The GUI one is a lot more user-friendly than defrag.exe, hell it's cool to watch. The "problem" with the GUI version is that it needs user interaction to defrag multiple drives. I just want to tell it to "defrag all my drives". I can't do that and then walk away for an hour, 'cuz you can only select one drive at a time, and it'll sit there and wait after it's done. So I have to stay in front of the system and sit on my hands until it's done, and then manually restart the same process for each and every drive and partition (I have lots).
On the other hand I can write the following batch file, start it and walk away:
DEFRAGALL.BAT
DEFRAG C:
DEFRAG D:
DEFRAG E:
DEFRAG F:
(...)
DEFRAG Z:
*That* is the value of command-line utilities--there's no easy way to do the same thing with the GUI version of the defragger. I've seen lots of threads in various boards from people attempting to do things such as automate the GUI version using WSH, Sleep() and SendKeys(). Talk about fugly. I'm glad MS added the command-line version in XP (I don't believe it existed on Win2K).
I think we're in definite agreement on this point: if an app needs to interact with the user after it's launched, in any way, shape or form, it really, really should have a full-blown GUI. What I wasn't agreeing with was your unilateral claim that "command-line programs have no place today". I think the distinction is in our definition of "command-line program"...you're including the old, interactive, text-mode, menu-based programs of yester-year (I *most definitely* agree they should die a horrible death). In my mind, a "command-line program" that still has some use today is the typical one-purpose, "launch and forget" utility such as defrag.exe. Nobody wants an Excel in text mode. <shivers>
Back to the article at hand--this process suspend/resume tool--would it benefit from a GUI? Yeah, why not? But does being command line-based make it useless? I say it doesn't. I could picture a process pegging a CPU at 100% utilization and wanting to suspend it ASAP--without having to sit through the system loading all the GUI overhead (the MFC DLLs are significant or, God forbid, the VB runtime and custom controls), especially when resources are already being severely taxed. I've sit through attempts to load Task Manager (easily taking 2, 3 minutes) just to kill the offending process. If I can instead launch CMD.EXE and use some command-line utility (I forget its name, it's in the resource kit) to kill the process in 10 seconds, then my blood pressure stays that much lower...
|
|
|
|
|