|
I am calling CreateProcessWithLogonW to spawn a new process in WinXP and it takes about 45 seconds on my computer to load the new process....any idea why this is happening....??
It takes about 2 to 3 seconds for the same call to spawn a new process on Win 2000 machine.
|
|
|
|
|
ARe you spwaning the same process (exe) on both OS?
Kuphryn
|
|
|
|
|
Yes...it seems that the exe is not taking the time...it is the CreateProcessWithLogonW call that is taking the time....
|
|
|
|
|
How different are the login profiles of both accounts ? (i.e., the one on winXP and the one on win2K)
If one has more processes under HKCU->...->Run, then its normal that is requires more time.
Just a thought
DarkByte
|
|
|
|
|
It is a good thought indeed but for my case the user on both XP and 2000 are newly created standard users. They have been created from the User Management console in both OS.
|
|
|
|
|
I made a very simple class, and when the default destructor is called, i get a debug assertion failure. (i'm using VC++ SP5)
if i call a function like this
void Testfunction()
{
uImage test;
test.Create(100);
}
the function exits properly, with the default destructor deleting the arrays successfully, however,if i call a function like this, that is without allocating the arrays,
void Testfunction()
{
uImage test;
}
The function exits with a Debug Assertion Failure, _CrtIsValidHeapPointer
What i'm confused is that, i'm trying to do cleanup in the destructor by deleting all the dynamic arrays. Although i havent created the arrays, there should be no problem coz i checked whether the pointers are NULL or not (when performing delete). So, why is there a debug assertion?
My class header is
#ifndef UIMAGE_H
#define UIMAGE_H
class uImage
{
private:
int *R;
int *G;
int *B;
public:
uImage();
~uImage();
void Create(int x);
};
#endif
My Class is
#include "StdAfx.h"
#include "uImage.h"
uImage::uImage()
{
}
uImage::~uImage()
{
if(R!=NULL) delete R;
if(G!=NULL) delete G;
if(B!=NULL) delete B;
}
void uImage::Create(int x)
{
R=new int[x];
G=new int[x];
B=new int[x];
}
|
|
|
|
|
uus99 wrote:
if(R!=NULL) delete R;
if(G!=NULL) delete G;
if(B!=NULL) delete B;
Should be:
if(R!=NULL) delete [] R;
if(G!=NULL) delete [] G;
if(B!=NULL) delete [] B; The differences between delete and delete [] were discussed here about a week ago. Search this forum for that thread.
"When I was born I was so surprised that I didn't talk for a year and a half." - Gracie Allen
|
|
|
|
|
Yes, you are right, i realized it. Even after i corrected that, there is still the same problem. Why?
|
|
|
|
|
You have not initialised the pointers.
uImage::uImage() : R(NULL), G(NULL), B(NULL)
{
}
or
uImage::uImage()
{
R = NULL;
G = NULL;
B = NULL;
}
Given this you do not need to check for R != NULL etc before calling delete as delete does the check for you.
Secondly you have missed deleting the array properly.
delete [] R;
R = NULL;
etc...
I would set R = NULL; after the delete also. But that's just me!;)
Ant.
I'm hard, yet soft.
I'm coloured, yet clear.
I'm fuity and sweet.
I'm jelly, what am I? Muse on it further, I shall return! - David Williams (Little Britain)
|
|
|
|
|
Thanks! The initialization of those pointers to Null solved my problem right away! I never knew i had to do that!
Thanks again!
|
|
|
|
|
As a rule of thumb, always initialize pointers to null (unless you have a reason to initialize them with a value). When it becomes a habit, It'll make testing against them much easier in the future.
Jeremy Falcon
|
|
|
|
|
You have to do that. Your pointers were not NULL, they were undefined which means any value is legal. My debugger expliactly sets everything to 0xAAAAAAAA to make sure that they are not null.
You are lucky, on many systems they will be NULL 95% of the time and you will tear your hair out trying to figgure out why your program crashes one time in 20.
|
|
|
|
|
That's interesting. I would think that the proper usage of delete contributed to the solution as well. Both are absolutely critical to ensuring that your code works properly. Not using new and delete properly will cause undefined behavior (sometimes your code will crash, sometimes it won't).
I've seen code like this:
#include "gconst.h"
struct globalmem
{
int counter;
int[SIZE] nDataBuffer;
//just as an example, the real data struct had many
//other attributes as well
}
//now later, in some other piece of code
globalmem* gpGlobalMem = new globalmem;
//Now even later upon application exiting
delete[] globalmem; //oops! use delete globalmem
//remember, if new was used, delete should be used for
//destruction. Always use the same format of new and
//delete (even though there is an array in global mem
//you still instantiated only 1 globalmem structure
//using new.
Now what was really weird was that the delete[] globalmem statement was in our code for years, even though it was wrong and never caused problems. But after adding even more variables to the data structure during the enhancement to a system, the software just started crashing when trying to exit the application.
|
|
|
|
|
Hi,
In VC++ 6.0, is there a way to change the group to which a radio button belongs without having to recreate that radio button ?
Thank you for your help.
John
|
|
|
|
|
I think group depends on radio's position in tab order.
You can adjust it in dialog resource editor, select Layout -> Tab Order in main menu, or Ctrl-D
rrrado
|
|
|
|
|
Yes. Modify a combination of the GROUP property and the TAB ORDER of the controls in the dialog. All controls in TAB ORDER beginning with a control with the GROUP property set are considered a group up to (but not including) the NEXT control in the tab order with the GROUP property set.
|
|
|
|
|
I think you'll find that radio buttons in a group have to be sequentially numbered as well, so you'll have to change the resource ID.
------- sig starts
"I've heard some drivers saying, 'We're going too fast here...'. If you're not here to race, go the hell home - don't come here and grumble about going too fast. Why don't you tie a kerosene rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt
"...the staggering layers of obscenity in your statement make it a work of art on so many levels." - Jason Jystad, 10/26/2001
|
|
|
|
|
Is there a way to kill a another process from within your process other than TerminateProcess??? Thanks.
|
|
|
|
|
You should signal your thread that you want it to finish by sending message, or using some signaling object, so that your thread could make neccessary cleanup before exitting
rrrado
|
|
|
|
|
You mean like using IPC? That would be the preferred method but that assumes known interfaces etc.
"No matter where you go, there your are." - Buckaroo Banzai
-pete
|
|
|
|
|
Is there a way to send a signal to one process from another process. I know you can call "raise(SIGINT)" to send a signal to your own process. Can one re-direct a signal to another process?
|
|
|
|
|
Hi,
Did you try ResetEvent(), SetEvent(), WaitForSingleObject() ?
Sincerely Yours,
RadioShark
|
|
|
|
|
ResetEvent(), SetEvent(), WaitForSingleObject() don't they work for thread...??
I think mutex is the solution....
|
|
|
|
|
You could use the WM_COPYDATA mechanism, but you need to have the hwnd of the process you want to signal.
------- sig starts
"I've heard some drivers saying, 'We're going too fast here...'. If you're not here to race, go the hell home - don't come here and grumble about going too fast. Why don't you tie a kerosene rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt
"...the staggering layers of obscenity in your statement make it a work of art on so many levels." - Jason Jystad, 10/26/2001
|
|
|
|
|
i hope can someone help me in this project.....
firstly i want to know how to read a text from a file...
after that convert the text to lowercase or uppercase...
than count the probability of the word that appear in the text......
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
