|
If you want your dialog to stay on top all the time, check out SetWindowPos()[^], and pass &this->wndTopMost to the function.
|
|
|
|
|
Thanks for reply,
my dialog must be at the bottom of the Z order.
I have dialog with text and the bg of the dialog is transparent.So it looks like the text is written directly on the desktop(but it isn't).
The problem is when I hit win. key+D so the dialog is minimized.
I know, it can be done using of windows hooks. I want to avoid of that(if it's possible).
|
|
|
|
|
Win+D does not mean minimize. It means show desktop.
Win+M is minimize.
«_Superman_»
I love work. It gives me something to do between weekends.
|
|
|
|
|
daavena wrote: I am capturing these windows messages
Have you verified with Spy++ that you are handling the correct message(s)?
"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
|
|
|
|
|
I use spy++, but when I hit win+D there is no message for my dialog(nothing about minimizing).
_Superman_ wrote
Win+D does not mean minimize. It means show desktop.
maybe that is the reason why I can not capture the proper message.
|
|
|
|
|
Hello all,
Firstly, does anyone have any info regarding the NtSetSystemPowerState function? I can't seem to find any documentation.
Secondly, is there any way to shutdown which is faster than calling ExitWindowsEx, but slightly better than calling NtShutdownSystem from the kernel?
Oh, and finally, can anyone provide me with some information on the entire windows shutdown process, beginning with the call to ExitWindowsEx?
Thanks in advance. 
modified on Saturday, March 14, 2009 3:10 PM
|
|
|
|
|
I don't have much idea regarding this function but you may try at this.[^].... 
|
|
|
|
|
Too bad that's for ReactOS 
I wonder if the function params are the same on Windows, since ReactOS has almost the same kernel...
|
|
|
|
|
hxhl95 wrote: Oh, and finally, can anyone provide me with some information on the entire windows shutdown process, beginning with the call to ExitWindowsEx?
Some info is available here.[^]
hxhl95 wrote: I wonder if the function params are the same on Windows, since ReactOS has almost the same kernel...
It's quite possible since ReactOS is designed in such a way that existing windows program can run on it. So, for this the API parameters must be same... This can be verified by calling this function assuming those parameters are correct. If call succeeds then you have got the solution...
|
|
|
|
|
Well, I did try calling the function with those params...
Here's my code (after typedef-ing POWER_ACTION and SYSTEM_POWER_STATE:
typedef DWORD (WINAPI* lpNtSetSystemPowerState)(POWER_ACTION SystemAction,SYSTEM_POWER_STATE MinSystemState, ULONG Flags);
hNTDLL = LoadLibrary("NTDLL.DLL");
lpNtSetSystemPowerState NtSetSystemPowerState = (lpNtSetSystemPowerState)GetProcAddress(hNTDLL, "NtSetSystemPowerState");
NtSetSystemPowerState(PowerActionShutdown,PowerSystemShutdown,NULL);
The only param I don't get is flags, which I put NULL for. Not working.
|
|
|
|
|
hxhl95 wrote: The only param I don't get is flags, which I put NULL for
Flags is of type ULONG. Instead of putting it NULL you may try substituting it with some unsigned value like 0x123....
And since it's hit and trial approach after all, this might not work. Instead you may try looking for actual kernel calls and then finding right parameter values using tools like process explorer etc. Best of luck!!!
|
|
|
|
|
I just found out that NtSetSystemPowerState returns STATUS_NOT_IMPLEMENTED in NT 4.0. Now I'm wondering if it's implemented in 5.1 and above. I know for a fact that it's in Vista though. 
All my calls to NtSetSystemPowerState have been returning 0xC00000EF. STATUS_NOT_IMPLEMENTED is 0xC0000002. If my research is correct, 0xC00000EF is NT_STATUS_INVALID_PARAMETER_1
 Anyone have clues regarding the parameters? I can't find any calls to it inside anything.
modified on Saturday, March 14, 2009 6:53 PM
|
|
|
|
|
|
Plenty of help for your data structures homework task can be found[^] on the internet.
Java, Basic, who cares - it's all a bunch of tree-hugging hippy cr*p
|
|
|
|
|
That was a nice one!!!
|
|
|
|
|
|
I have an MFC dialog application. It monitors certain types of windows and collects information on them. I start a new thread for every window based on it's title. I use a timer to find windows that meet the criteria. I created a struct named ThreadInfo and I pass it to the thread. At the end I either close the monitored window(s) or close my dialogs.
This causes several memory leaks.
Here is the code in the timer if it finds a window that meets the criteria:
ThreadInfo *pInfo = new ThreadInfo;
pInfo->hMainWnd = dlg->GetSafeHwnd();
pInfo->hMonitoredWnd = hwnd;
pInfo->x = y;
CWinThread *pThread = AfxBeginThread(ThreadFunction, (PVOID) pInfo, THREAD_PRIORITY_NORMAL, 0, 0);
Here is the code for ThreadFunction:
UINT ThreadFunction(LPVOID pParam)
{
ThreadInfo *pInfo = reinterpret_cast<threadinfo> (pParam);
while (IsWindow(pInfo->hMonitoredWindow))
{
do.Something;
Sleep(100);
}
return 0;
}</threadinfo>
I tried the following scenarions to eliminate or at least identify the memory leaks. The resulting leaks are below them:
A:
- I create pInfo and close the dialog first:
thrcore.cpp 68B client block
mydlg.cpp 748B normal block
strcore.cpp 46B normal block
B:
- I create pInfo and close the monitored window first:
mydlg.cpp 748B nromal block
strcore.cpp 46B normal block
C:
- I create pInfo, but don't start the thread:
mydlg.cpp 748B normal block
strcore.cpp 46B normal block
D:
- I don't create pInfo and pass NULL to the thread:
no leaks!
E:
- I delete pInfo in ThreadFunction and close monitored window first:
no cpp file, 160B normal block
F:
- I delete pInfo in ThreadFunction and close dialog first:
no cpp file, 160B normal block
thrcore.cpp 68B client block
mydlg.cpp 748B normal block
strcore.cpp 46B normal block
So I think the 748B and 46B blocks are for pInfo, while the 68B and 160B block are for pThread. But how and where should I delete them?
I think I should delete them in the dialog, but how do I send a message from the thread when it ends? And how I delete the handles if I close the dialog first?
|
|
|
|
|
1. Why not take a local copy of *pInfo early in the thread function, so you can delete pInfo early:
UINT ThreadFunction(LPVOID pParam)
{
ThreadInfo info(reinterpret_cast<ThreadInfo*>(pParam));
delete reinterpret_cast<ThreadInfo*>(pParam);
while (IsWindow(info.hMonitoredWindow))
{
do.Something;
Sleep(100);
}
return 0;
}
2. Do you keep track of all the threads you've created? Doesn't look like it. Store them in a vector or something and delete them in your dialog's WM_CLOSE handler.
3. If the monitored windows aren't closed, does the thread terminate? You probably ought to have some way of telling the threads to exit even if their monitored window still exists.
Basically, you need to think about the likely lifetimes of objects and work out where you need to be deleting objects.
Java, Basic, who cares - it's all a bunch of tree-hugging hippy cr*p
|
|
|
|
|
Thanks!
1. This didn't compile, error was:
error C2664: 'ThreadInfo::ThreadInfo(const ThreadInfo &)' : cannot convert parameter 1 from 'ThreadInfo *' to 'const ThreadInfo &'
but I used the following:
ThreadInfo *pInfo = reinterpret_cast<threadinfo> (pParam);
ThreadInfo info = *pInfo;
delete pInfo;</threadinfo>
And it seems to work. The 748B and 160B blocks are eliminated.
2. I had a threads vector earlier, but I didn't use it. Now I use it as you recommended, but I use ON_WM_DESTROY (I switched off the close button):
void CFredoDlg::OnDestroy()
{
for(vector<handle>::size_type i = 0; i < threads.size(); i++)
{
threads.erase(threads.begin() + i);
}
}</handle>
But the 68B and 46B blocks are still there. Now I will try to find a way to terminate the threads. If you have a solution for that, don't keep it!
|
|
|
|
|
keret wrote: But the 68B and 46B blocks are still there
Implies you have a thread object and a string that you haven't deleted.
keret wrote: Now I will try to find a way to terminate the threads. If you have a solution for that, don't keep it!
You could use a global boolean-ish variable. You would set it using InterlockedExchange[^] and read as you would any other variable.
Set it to zero before any threads are started and to one when you want to exit. Use this code to set it (let's presume it's called letsExitNow)
InterlockedExchange(&letsExitNow, 1);
Now, in each thread, you would change your with loop to somethig like this:
while (!letsExitNow && IsWindow(pInfo->hMonitoredWindow))
In the ON_WM_DESTROY handler, wait for each thread handle to be signalled (signalled means the thread has exited) - you can use WaitForSingleObject[^] or WaitForMultipleObjects[^] to do that.
Java, Basic, who cares - it's all a bunch of tree-hugging hippy cr*p
|
|
|
|
|
My TreadFunction is in a separate file (MyThread.cpp).
How can I reference letsExitNow from there? Or should I put the code in MyDlg.cpp?
|
|
|
|
|
Add a definition for letsExitNow in one file:
LONG letsExitNow;
and an external declaration in the other:
extern LONG letsExitNow;
Java, Basic, who cares - it's all a bunch of tree-hugging hippy cr*p
|
|
|
|
|
Sorry, I have never used extern before.
I put this in MyDlg.h:
public:
LONG letsExitNow
I put this in CMyDlg::OnInitDialog:
InterlockedExchange(&letsExitNow, 0);
And I put this in ThreadFunction:
extern LONG letsExitNow;
But I got an "unresolved external symbol "long letsExitNow"" error. Did I something wrong?
|
|
|
|
|
Minor mis-understanding
Put the LONG letsExitNow in MyDlg.cpp - NOT in a method, just in the file.
Java, Basic, who cares - it's all a bunch of tree-hugging hippy cr*p
|
|
|
|
|
Thank You, I really appreciate your help. This was a complicated problem (for me now at least). The 160B object was another struct I didn't include in the code above.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
