|
Thanks for all the invaluable feedback, everyone. Many of my suspicions have been verified and I’ve learned some things about Windows scheduling that has given me a bit more gray hair. Fortunately, setting the thread quanta to the minimum (about 33ms) provides just barely enough response time to make the protocol implementation work under typical conditions. The implementation doesn’t meet the specification, but it does work so it’s sufficient for now.
Thanks again for all the help!
|
|
|
|
|
"G d Answer"
|
|
|
|
|
I suggest you look for a long term solution, Windows is not meant to be this close to real time. Not jsut because of the serial port issue but if your system is this time senistive you are likely to hit further problems and trying to balance the scheduling will continue to be a headache.
|
|
|
|
|
I'm a little puzzled by the behavior you are seeing from your serial device. We run XPe and a dozen serial devices in real time, but they are purely interrupt driven and I think that's the difference. The requirement for the 5ms timeout is problematic, though it could be done with driver level code.
(If hard real time is needed and you want free, don't bother with Linux; check out eCos instead. If cost isn't an issue, there's plenty of choices like Windows CE or Integrity from Green Hill Software. [And VxWorks, but I detest it and found that dealing with Wind River Systems was a nightmare.])
Anyone who thinks he has a better idea of what's good for people than people do is a swine.
- P.J. O'Rourke
|
|
|
|
|
The OS is Windows XP, writing in C using win32 API. I cannot find a (just spent an hour googling sigh!) way to have mixed colors in a text string. SetColorText() makes the text all the same color, and so does SetBkColor(). For example I would like to print the string "This is a test." and have the word "test" in red and the other words in black. If anyone could show me code to do this I'd really appreciate it.
Zach
|
|
|
|
|
You'll have to draw 'test' separately from the rest of the text, so you can change the DC's attributes between calls to the text output routine.
Java, Basic, who cares - it's all a bunch of tree-hugging hippy cr*p
|
|
|
|
|
If you don't mind the "clutter" you could try using a rich edit control and the EM_DISPLAYBAND message to display formatted text, using the rich edit control you could color your text the way you want or even have multiple font sizes and styles in on line and then use the forementioned message to render it onto a DC... i know it sounds ugly, but hey, sometimes ugly solutions are the only working solutions. (Not that i am saying this is the only way to do what you want)
> The problem with computers is that they do what you tell them to do and not what you want them to do. <
> Life: great graphics, but the gameplay sux. <
|
|
|
|
|
Hello gentlemen,
Is there any option to disable/prevent window minimizing when I press window key(between Ctrl and Alt) + D?
I have one dialog without tile with transparent backgroud, I don't use MFC.
I am capturing these windows messages
case WM_WINDOWPOSCHANGING:
return true;
break;
case WM_WINDOWPOSCHANGED:
return true;
break;
case WM_SIZE:
if(wParam == SIZE_MINIMIZED)
{
return true;
}
break;
Thank you.
|
|
|
|
|
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?
|
|
|
|