|
OK...I solved this with what seems like an ugly hack, surely there must be a better way....
Anyways, what I did was to PostMessage a user message from the CBN_SELCHANGE event and strip the prefix in my user message handler, I just hope the messages continue to arrive in the correct order...
|
|
|
|
|
I used NtQueryInformationProcess to get
PROCESS_BASIC_INFORMATION and PEB and then RTL_USER_PROCESS_PARAMETERS.
But CommandLine of RTL_USER_PROCESS_PARAMETERS is always associated with the currect process although I passed in different PID into NtQueryInformationProcess() call.
By the way, I am using XP64.
Can you help.
Thanks
Jack Rong
|
|
|
|
|
Have you read the following notice in documentation [^]:
[NtQueryInformationProcess may be altered or unavailable in future versions of Windows. Applications should use the alternate functions listed in this topic.]
?
Jack Rong wrote: although I passed in different PID into NtQueryInformationProcess() call.
You should pass the process handle, shouldn't you?
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke
[My articles]
|
|
|
|
|
Thanks for your response.
Yes, I do pass the process handle, here is the example,
hProcess = OpenProcess(PROCESS_QUERY_INFORMATION | PROCESS_VM_READ,
FALSE, mypid );
NtQueryInformationProcess (hProcess, ProcessBasicInformation,
&pbi, sizeof(pbi), &dwSize);
Where "mypid" is what I want and is not current PID. But the CommandLine I got is the Current Process's CommandLine. So strange!
Yes, I realize that. But I am not sure which new function can be used in order to replace the "NtQueryInformationProcess()" though.
Jack
|
|
|
|
|
How do you get the command line? I don't see such a option in the documentation.
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke
[My articles]
|
|
|
|
|
Hello everyone,
I understand there should be no exception thrown from destructor. But exception will block the remaining code to be executed until catch block.
In my destructor, I free resources step by step. But at some first step, there may be exception in destructor, so I suspect the remaining resources can not be freed correctly. In my class, I use member variable to hold resources.
My questions are,
- My current solution is to declare each member as smart pointer, so that to ensure the destructor will be called.
- I am not sure whether my concern is correct or no such issue -- e.g. member's destructor will always be called or not, even if I do not wrap them with auto_ptr?
thanks in advance,
George
|
|
|
|
|
George_George wrote: e.g. member's destructor will always be called or not, even if I do not wrap them with auto_ptr
of course no destructor is called for objects allocated dynamically and assigned to standard (even if class member) pointers.
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke
[My articles]
|
|
|
|
|
Thanks CPallini,
One more question, if the class member has destructor, even if
- we do not call it exeplicitly in the whole class's destructor;
- or because of exception execution flow, it is not executed
its destructor will be called when the current object instance destructs?
regards,
George
|
|
|
|
|
See here [^].
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke
[My articles]
|
|
|
|
|
Thanks CPallini!
I think here is the answer,
--------------------
In reverse order of construction: First constructed, last destructed.
In the following example, b's destructor will be executed first, then a's destructor:
void userCode()
{
Fred a;
Fred b;
...
}
--------------------
So, I think the answer to my question whether destructor of member variable will be called in the following two situations is -- yes, they must be called. Correct understanding?
- we do not call it exeplicitly in the whole class's destructor;
- or because of exception execution flow, it is not executed.
regards,
George
|
|
|
|
|
The destructors of member variables are always implicit called, so you have NOT to call them explicitely.
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke
[My articles]
|
|
|
|
|
Thanks CPallini!
From your reply, I think in the two situations, as long as I implement the destructor of the members properly, they will be called finally without any issues. Correct?
- we do not call it exeplicitly in the whole class's destructor;
- or because of exception execution flow, it is not executed.
regards,
George
|
|
|
|
|
George_George wrote: I am not sure whether my concern is correct or no such issue -- e.g. member's destructor will always be called or not, even if I do not wrap them with auto_ptr?
You are kidding right? With all the esoteric question you ask around here when you don't even know how destructors work. That is exactly why in the past I suggested you stop investigating some of the issues you were on about. You need to stick to fundamentals until you get a firm grasp of them. Until then you are basically lost.
Ah yes, just below is yet another good example:
George_George wrote: For the following code, on x86 build, the output is
000000C8
000000C8
and on x64 build, the output is
CCCCCCCC000000C8
00000000000000C8
You are looking at and questioning what the compiler generates when you don't even know how destructors work. That makes no sense at all. It's even worse for someone that is constantly claiming they are trying to make sense of things. 
led mike
|
|
|
|
|
You're still answering the bot, huh?
The history of "his" question topics is amazingly diverse,
sometimes just seemingly random.
Mark Salsbery
Microsoft MVP - Visual C++
![Java | [Coffee]](https://codeproject.freetls.fastly.net/script/Forums/Images/coffee.gif)
|
|
|
|
|
Couldn't agree more Mark.
Mark Salsbery wrote: The history of "his" question topics is amazingly diverse,
sometimes just seemingly random.
In my opinion it usually begins with a seemingly basic question about a small detail, but when the answer comes it blows up to something else where George clearly has not grasped the concept and he refers to another detail in some obscure MSDN article or similar. From that point on it takes a good book to explain to George how it really works. This means that I've stopped answering until his questions shows that he has actually paid some attention and learnt something.
"It's supposed to be hard, otherwise anybody could do it!" - selfquote
"High speed never compensates for wrong direction!" - unknown
|
|
|
|
|
Mark Salsbery wrote: sometimes just seemingly random.
Most of the time. He's just lost, but he sure maintains a great attitude with all the stuff hurled at him. It's hard to imagine that we will ever figure out what his deal is. He is the internet developer forum enigma.
led mike
|
|
|
|
|
Thanks for your encouragement, I will continue my work.
regards,
George
|
|
|
|
|
George_George wrote: I will continue my work.
Hey George, could we know what is your work? 
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke
[My articles]
|
|
|
|
|
I like coding and take a lot of time study various coding issues. My purpose is to know as much as you know in 5 years.
regards,
George
|
|
|
|
|
CPallini wrote: Hey George, could we know what is your work?
Don't you know what an enigma is? 
led mike
|
|
|
|
|
I guess kudos to George for getting at least two online
communities to do his research for him.
It still, however, makes me laugh that Microsoft's bot-
detection flagged him as a bot. THAT'S serious research!
He's going to end up writing the next killer app.
Mark Salsbery
Microsoft MVP - Visual C++
|
|
|
|
|
Mark Salsbery wrote: It still, however, makes me laugh that Microsoft's bot-
detection flagged him as a bot.
Yeah, if nothing else, he is unique.
Mark Salsbery wrote: He's going to end up writing the next killer app.
Absolutely. By the way I have some outstanding land in florida for sale, you interested?
led mike
|
|
|
|
|
How about:
try
{
delete your_pointer;
}
catch (your thrown_exception on delete)
{
}
Anyway, what you've described seemed like an unhandled exception thrown in a loop.
I suggest you avoid using dynamic allocation without a smart pointer. If possible, use references on arguments to functions and members of your class. Using pointers usually leads to circular and redundant dependences.
Beware of your design. It is a very common practice to stack everything on "multi-purposed" classes. Every class has a purpose. If you stick with that in mind, probable your class will be split to several ones, and you'll find lots of issues.
|
|
|
|
|
Thanks gscotti!
1.
"If possible, use references on arguments to functions and members of your class" -- could you show some code please? I want to learn your best practice, but I do not understand until I see some code. 
2.
gscotti wrote: Beware of your design. It is a very common practice to stack everything on "multi-purposed" classes. Every class has a purpose. If you stick with that in mind, probable your class will be split to several ones, and you'll find lots of issues.
Confused about your points above. Do you mean it is good practice to make a class big to contain a lot of stuff other than split?
regards,
George
|
|
|
|
|
Hi,
On Remarks section, MSDN documentation of CListCtrl:SetItemState its written that SetItemState may be used for hiding or disabling items on the List. I tried to find the state bits for hiding or disabling any item but i couldn't.
Do you have any idea?
Thanks,
Cem
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
