|
Also note that I'm in control of both ends of the network connection, so it doesn't need to be a standard format as long as the library can compress/decompress since my code will be on both sides.
|
|
|
|
|
Dave Calkins wrote: it doesn't need to be a standard format
I don't know how to do it, but I would love to go at least for a standard format, you will always get the benefits of other people improving code that you won't need to maintain.
Regards.
|
|
|
|
|
Windows Media Encoder can handle the capturing and streaming parts, if you don't mind using an external app.
|
|
|
|
|
ok, I'll take a look at it. I'm already getting the uncompressed frames, so I'd need to be able to feed frames to it. Probably a safe assumption that everyone has Windows Media Player installed.
|
|
|
|
|
The Windows Media Format SDK is lower level than the Media Encoder and includes a network stream.
|
|
|
|
|
I'm writing a serial port class. My team lead said that when using simple, non-overlapped I/O on Windows 2000, they found that doing 1 and 2 byte reads caused a significant peak in CPU utilization. (All our packets are read with a 1 byte, then either a 1 or 2 byte read then a lengthy read.) Do reduce this, they double buffered the reads.
I converted the class to use basic OVERLAPPED I/O. I wrote 2 versions of the class; one uses straight reads, the other reads the data in chunks and queues it up for the reader.
When testing both, I found that the process utilization was the same on average. Does anyone know if OVERLAPPED I/O is already buffering serial port reads? (Do serial port reads even make a ring transition at the driver level? Did this possibly change between Windows 2000 and Windows XP?)
Anyone who thinks he has a better idea of what's good for people than people do is a swine.
- P.J. O'Rourke
|
|
|
|
|
Hello!
I'm trying to find out how to detect double clicks on desktop screen. I could use GetKeyState() and make some calculations to detect 'global' double-click, but this would include clicks on buttons, icons and other items. I want to detect ONLY that double-clicks which are not connected with any action (those messages which system is not passing to any other application neither interpret by its own like double-clicks on icons).
Should I use global hooks?
SetWindowsHookEx(WH_MOUSE, MouseProc, tInstance, NULL) would fit if I could filter-out application/icons connected doubleclicks.
Thanks for any help
Pat
|
|
|
|
|
This is a complete SWAG, but once you detect a mouse click on a window, can you check to see if: 1) it has no parent, and 2) it belongs to the "#32769" class?
"Approved Workmen Are Not Ashamed" - 2 Timothy 2:15
"Judge not by the eye but by the heart." - Native American Proverb
|
|
|
|
|
Hmmm... Lets assume hooking to the global mouse messages via SetWindowsHookEx(WH_MOUSE,....). I would get ALL mouse messages.
Is this MSG structure enough to detect double-click on 'free' desktop window?
typedef struct {
HWND hwnd;
UINT message;
WPARAM wParam;
LPARAM lParam;
DWORD time;
POINT pt;
} MSG, *PMSG;
My pseudo-code would be like this:
if((pMsg->message==WM_LBUTTONDBLCLK) && (pMsg->hwnd==::GetDesktopWindow()))
{
// we've got double-click on desktop, not on any other window/icon??
}
Do You think that's enough? I wonder what pMsg->hwnd would be if I double-click on "my computer" icon?? Would it be the same? (::GetDesktopWindow())
Pat.
|
|
|
|
|
Use spy++ utility and check the message(s) when double-clicking My computer icon.
Me I think the message is for the SHELLDLL_DefView/SysListView32 classes that displays the icons, and not for #32769 desktop window.
|
|
|
|
|
|
Armond Sarkisian wrote: When I load the form, how can I get the value of name which is "John" to appear in the edit box for IDC_Edit1?
Assign a CEdit member variable (e.g., m_edit) to the IDC_Edit1 control. Then just call:
m_edit.SetWindowText(name.c_str());
"Approved Workmen Are Not Ashamed" - 2 Timothy 2:15
"Judge not by the eye but by the heart." - Native American Proverb
|
|
|
|
|
|
Armond Sarkisian wrote: What statement must I use to assign the CEdit member variable to the IDC_Edit1 control?
ClassWizard (Ctrl+W).
"Approved Workmen Are Not Ashamed" - 2 Timothy 2:15
"Judge not by the eye but by the heart." - Native American Proverb
|
|
|
|
|
SetWindowText for change text on the window and GetWindowText for retrive a text of the window
|
|
|
|
|
Hello all,
I'm studying some memory leaks that I have in one app that I'm writing, and I've seen that somehow the destructor of some of the dialogs is not called.
How can I ensure that this will happen?
Thank you in advance.
|
|
|
|
|
as any other object, dialog destructor is called when it goes out of scope (when is allocated on the stack), or when you delete its pointer (dynamically allocated). Please note that after EndDialog() ends the destructor is not automatically called, hence, if you need any cleanup at window closing, you have to override the OnClose handler and perform the cleanup there.
hope that helps.
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.
|
|
|
|
|
I feel sorry because I've not explained that the dialog was not modal, but in fact, I'm trying to use the PostNCDestroy override function and it seems to work well.
But again, I do not understand why the destructor is not being called...
Thank you.
|
|
|
|
|
Maybe your CDialog goes never out of scope.
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.
|
|
|
|
|
How can this be after an ALT+F4 and getting the entire app closed?
|
|
|
|
|
As pointed out by DavidCrow if you allocate dynamically (i.e. using new operator) the Dialog and never delete it then its destructor will never be called, even if the app terminates.
Anyway, maybe posting the code will help...
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.
|
|
|
|
|
Let me study it a little bit more, but by now what I must say is that adding the override to PostNCDestroy works like charm.
THANK YOU!
|
|
|
|
|
Joan Murt wrote: the dialog was not modal, but in fact, I'm trying to use the PostNCDestroy override function and it seems to work well.
Which means you have a modeless dialog. Do you have something like:
CMyDialog::CMyDialog(CWnd* pParent ) : CDialog(CMyDialog::IDD, pParent)
{
Create(IDD);
}
void CMyDialog::PostNcDestroy()
{
delete this;
CDialog::PostNcDestroy();
}
...
CMyDialog *pDlg;
pDlg = new CMyDialog;
pDlg->ShowWindow(SW_SHOW);
...
pDlg->DestroyWindow();
"Approved Workmen Are Not Ashamed" - 2 Timothy 2:15
"Judge not by the eye but by the heart." - Native American Proverb
|
|
|
|
|
Well, it is a little bit more complicated (but not a lot more  ) in fact there are several property sheets that have several property pages that are being created dynamically at runtime.
Then when the main dialog is getting destroyed implicitly the other dialogs that are not modal are being destroyed... As I said it seems to be working... with PostNCDestroy.
|
|
|
|
|
Joan Murt wrote: ...I've seen that somehow the destructor of some of the dialogs is not called.
How are you verifying this?
"Approved Workmen Are Not Ashamed" - 2 Timothy 2:15
"Judge not by the eye but by the heart." - Native American Proverb
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
