|
You call ExecuteProcess with the same command line you would use at a command prompt. The directory is what the current directory should be set to.
For example, ExecuteProcess(_T("C:\\Windows\\System32\\Notepad.exe win.ini"), _T("C:\\Windows"));
This is very simple code, but it illustrates the basic principles. Go to MSDN and read up on CreateProcess() and WaitForSingleObject(). Read up on multi-threading and synchronization. Experiment. Step through the code. Until you fully understand this code, you will not be qualified to write any code.
Anyone who thinks he has a better idea of what's good for people than people do is a swine.
- P.J. O'Rourke
|
|
|
|
|
I never did get an answer to my initial question
|
|
|
|
|
You can't do what you want. system doesn't give you back the identity of your process, so you have no way to (later) control it. You have to use some other mechanism to create the process, like (as Joe suggested) CreateProcess, which does give you the process identity (through the PID and a process handle in the case of CreateProcess).
Java, Basic, who cares - it's all a bunch of tree-hugging hippy cr*p
|
|
|
|
|
gamefreak2291 wrote: I never did get an answer to my initial question
Your original question was posted when Europe had just gone to bed, India was debating getting to eat its breakfast Bhaji, and the Americas were having their after work beer. Or in your case, doing their homework.
1/ You don't pay us - we'll answer if / when we feel like.
2/ I'll give you credit for not putting "URGENTZ" in your subject line!
Anyway, Joe has given you a very good answer - if you need details, functions like CreateProcess have very long documentation to read.
I wish you success with your course,
Iain.
In the process of moving to Sweden for love (awwww).
If you're in Scandinavia and want an MVP on the payroll (or happy with a remote worker), give me a job!
|
|
|
|
|
I am upgrading from an older version of Visual Studio to Visual Studio Express 9.0. In my code I have #include tapi.h. This causes an error. Does anyone know how to solve this?
|
|
|
|
|
It's in the platform SDK.
Anyone who thinks he has a better idea of what's good for people than people do is a swine.
- P.J. O'Rourke
|
|
|
|
|
Windows SDK will not load with Visual Studio 2008. In the Platform SDK the dialer example uses tapi.h and does not comiple with VS2008. Do you have the dialer example from the Windows SDK?
|
|
|
|
|
|
If you only have the Visual Studio 2008 EXPRESS, the Windows SDK will not download into your PC.
I was able to solve the problem with '#include tapi.h'. When I created the project, Visual Studio left the "Preprocessor Definitions" blank. When I put in "WIN32;_DEBUG;_WINDOWS" it compiled OK.
Thanks for the responses.
|
|
|
|
|
Member 476468 wrote: Does anyone know how to solve this?
Solve what? 
"Old age is like a bank account. You withdraw later in life what you have deposited along the way." - Unknown
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
|
|
|
|
|
In Visual Studio 2008, what replaces tapi.h?
|
|
|
|
|
Have you looked in the two include folders to see if the file exists, or search the .h files to see if they contain TAPI-related functions?
"Old age is like a bank account. You withdraw later in life what you have deposited along the way." - Unknown
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
|
|
|
|
|
Hi,
I have derived class which has 2 base calsses CSyncObject and CSingleLock
Since the input to the CSingeLock is a pointer to a CSyncObject my question is
if I first create the CSyncObject can I reference that object object when executing
the Constructer for the CSingleLock with the "this" pointer
e.g. class mylock() : public CSyncObject(NULL) , public CSingeLock(this->
my question really is am I going down the right path
I would assume the "this" pointer gets initialized after excuting the first
contructer
|
|
|
|
|
ForNow wrote: I would assume the "this" pointer gets initialized after excuting the first contructer
No, you should be OK - this code does 'the right thing':
#include <iostream>
class A
{
public:
A(int x) { x_ = x; }
int x_;
};
class B
{
public:
B(A* a) { std::cout << a->x_ << std::endl; }
};
class C : public A, public B
{
public:
C(int y) : A(y), B(static_cast<A*>(this)) {}
};
int main(int, char**)
{
C c(33);
}
VC++ (unlike gcc) does raise a warning[^] about doing this, but reading the warning description, I don't think it applies in this case.
Java, Basic, who cares - it's all a bunch of tree-hugging hippy cr*p
|
|
|
|
|
It worked
Please explain what is the value of "this" pointer on entrance to B from my undertanding static_cast<a*> is just a cast
????
|
|
|
|
|
ForNow wrote: from my undertanding static_cast<a*> is just a cast
Not in the presence of multiple inheritance - with multiple inheritance, you have two bases whose members you have to contain in your object. That means that for (say) class C : public class A, public class B, you have this layout in memory:
+---------------+
| A members |
+---------------+
| B members |
+---------------+
| C members |
+---------------+
So, to cast a C* to a B*, you will have an offset, equal to the size of A's members.
Java, Basic, who cares - it's all a bunch of tree-hugging hippy cr*p
|
|
|
|
|
Hi,
class mylock : public CSyncObject, public CSingleLock
{
public:
mylock(BOOL bInitialLock);
BOOL Unlock();
};
mylock :: mylock(BOOL bInitialLock) : CSyncObject(NULL), CSingleLock(static_cast<CSyncObject*>(this), bInitialLock)
{
bInitialLock = FALSE;
}
Made a breakpoint when I tried to instatiate mylock with following code mylock my_threadlock(init_s);
at mylock the this value was 1feb8 as I steped into CsyncObject it remained 1feb8 when I got to CsingleLock's
contructer this value was bumped to 1FEC0 However m_hObject value was 1FEB8 CsyncObject value
Still have some debugging to do but thankx
this article also elucidates the point you tried to make
http://carcino.gen.nz/tech/cpp/multiple_inheritance_this.php
thankx again
|
|
|
|
|
I disagree with Stuart. The "this" pointer should rarely be used in an initializer list. This is especially apt here since CSyncObject has virtual classes and the virtual table hasn't been set up at this point.
I also think your class is a mistake and misunderstands CSyncObject() and CSingleLock(). The point is that there is one synchronization object with multiple threads locking that object. That locking is done by instantiated CSingleLock() at the start of a scope and upon exit of that scope, CSingleLock will be destructed regardless regardless of how the scope was exited.
Moreover, with your code, what does CSyncObject even represent?
Finally, note that CSyncObject will be destructed before CSingleLock which will attempt to unlock the destructed CSyncObject.
Anyone who thinks he has a better idea of what's good for people than people do is a swine.
- P.J. O'Rourke
|
|
|
|
|
Joe Woodbury wrote: The "this" pointer should rarely be used in an initializer list.
It all depends whether he actually uses what the this pointer points at in the constructor or just stores it for later use. Storing for later use? Yeah, you'll be OK.
Joe Woodbury wrote: ...the virtual table hasn't been set up at this point.
The vtable will be consistent with the definition of the base class in the base class constructor (see this Scott Meyers article[^] for confirmation).
However, you do need to be very careful and aware of what's happening...which is why I probably shouldn't have said the OP would be OK with using this.
Joe Woodbury wrote: I also think your class is a mistake and misunderstands CSyncObject() and CSingleLock(). The point is that there is one synchronization object with multiple threads locking that object. That locking is done by instantiated CSingleLock() at the start of a scope and upon exit of that scope, CSingleLock will be destructed regardless regardless of how the scope was exited.
Yeah, I wasn't even looking that far 
Java, Basic, who cares - it's all a bunch of tree-hugging hippy cr*p
|
|
|
|
|
As Far CsingLeObject Being Distructed I can always Create on the Heap as it will exist for the Life time of the app
Since threads are always Coming and going it may not be a bad idea to have to around
|
|
|
|
|
I think you need to redesign a bit your architecture. You first have the problems explained by Joe but it also feels completely wrong: your class IS a CSingleLock object and IS a CSyncObject ? This is akward. I guess you are trying to make something without really understanding what you are doing.
Maybe if you explain what you are trying to do (conceptually I mean, not low level code like here), we could help you design a better solution...
|
|
|
|
|
As far as what Joe Pointed the Csync Object getting destroyed before the Lock Object
the thread is in constant loop while(1) waitting to get signalled so it never ends
What I was trying to do since a CSingleLock needs a CsyncObject pointer make it all part of
one SuperClass
as said my code is a thread waitiing to get signaled when it does I single thread via the Lock
until the code finishes executing
thnakx
|
|
|
|
|
Following Cedric's response (which is quite correct) that your class shouldn't be both a lock and a sync object, here's a further suggestion that avoids both that confusion and the use of this in constructor calls.
Look at this page from Boost[^] describing the 'base-from-member' idiom.
Now, you could re-factor your code as:
struct mylock_pbase
{
mylock_pbase() : syncObject(NULL) {}
CSyncObject syncObject;
};
class mylock : private mylock_pbase, public CSingleLock
{
public:
mylock(BOOL bInitialLock) : mylock_pbase(),
CSingleLock(&syncObject, bInitialLock)
{
}
BOOL Unlock();
};
You could use the boost::base_from_member class, but it would only remove the need to declare mylock_pbase.
Java, Basic, who cares - it's all a bunch of tree-hugging hippy cr*p
|
|
|
|
|
I understand your just mylockphase create a CsyncObject named syncobject
IS there a need for the : syncobject(NULL) wont the CsyncObject get created without it
btw what does the "explicit" qualifer in Font of the CSyncObject signify
|
|
|
|
|
ForNow wrote: syncobject(NULL)
I put that there because you had it in your original post 
ForNow wrote: btw what does the "explicit" qualifer in Font of the CSyncObject signify
That the constructor can't be used (by the compiler) to perform implicit type-casts. It only really matters for single parameter constructors and should probably be used for most single-parameter constructors just to make sure you don't create objects unless you really meant to. Look at the documentation for it[^].
Java, Basic, who cares - it's all a bunch of tree-hugging hippy cr*p
modified on Thursday, April 2, 2009 3:33 AM
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
