|
Thanks for your help!
The non-client area is part of the displayed dialog, and if i click on the icon within the dialog, you're right, but the whole situation looks different at the Taskbar. If i press the right button on the dialog at the taskbar, WM_NCACTIVATE is send, unfortunately it's the only WM_NC** message!
Thank you anyway!
|
|
|
|
|
After doing a bit more of research work, I found a suitable article from MSDN to cater for your needs. Unlike I had remembered, the Taskbar is an object of the shell, and doesn't send any other messages to the windows residing in the tray area besides the WM_NCACTIVATE.
The MSDN link is http://msdn.microsoft.com/library/default.asp?url=/library/en-us/shellcc/platform/shell/programmersguide/shell_int/shell_int_programming/taskbar.asp
(If you can't get the link open, do g00gle with "The Taskbar (Windows Explorer)" to get a link)
From there, you can click 'Managing Taskbar buttons'. From there, scroll a bit down for information about the COM object representing the Taskbar (Modifying contents of the Taskbar)
So, it is a COM object. Get it's interface and you can do pretty much whatever you want. Regarding the issue you described earlier, jack in to the Taskbar object and add there a feature to send a message to your windows/applications when the user fiddles with their buttons on the Taskbar. I am wondering why this type of extension hasn't been written already. Guess nobody required it yet.
Greets,
Antti
----------------------------------------------
The definition of impossible is strictly dependant
on what we think is possible.
|
|
|
|
|
Thanks for your help, but adding and removing items from the taskbar isn't my problem, i need to know if an item of the taskbar is pressed or not! I haven't found any useful method which can do this. I'm thus far to implement it on my own whith threads who catches all messages be send!
Thanks anyway!
|
|
|
|
|
Even though I've searched the net and looked in MSDN I can't remember the name of the function that returns the ANSI keycode of a character. Does anyone knows?
|
|
|
|
|
Can you provide an example of what this function does (e.g., Given X, it returns Y)?
Five birds are sitting on a fence.
Three of them decide to fly off.
How many are left?
|
|
|
|
|
|
Thanks a lot John, that was exactly what I was looking for, it appears that in C++ this function doesn't exist because the compiler already does the conversion. Thanks, again.
|
|
|
|
|
Hi,
I am designing a winsock applications that utilizes AcceptEx() winsock extension. According to MSDN, sockets that are accepted via AcceptEx() work only with send(), recv() and other functions. However, they do not work with WSASend() and WSARecv().
Is there a solution to AcceptEx() working with WSASend() and WSARecv()? I want to make sure there is no other alternative.
One reason I prefer to use the winsock 2 API is because of the OVERLAPPED I/O feature. Secondly, I the application runs under IOCP. I have never used send() and recv() with IOCP.
Thanks,
Kuphryn
|
|
|
|
|
In a dialog based application is there any way to catch stndard
output( say cout<< "something" )and display it in a control while program is running.
Warm Regards,
KKRam
|
|
|
|
|
Do you know the definition of "overloading"?
|
|
|
|
|
It's having more than one function with the same name but with different argument types or number of arguments. Ideally the operations of each function should be similar in nature, for example two functions named Area where one might be for circles and another for cylinders. Each function takes different numbers of parameters, and the operations are not identical. If the operations were identical, with only the types of the arguments being different, then you would want to use a template function.
sf
|
|
|
|
|
I just upgraded to Visual C++ 2003, and haven't touched it yet. There is no book out that is MFC intensive in this new version. Has the MFC class structure changed greatly, or can I still rely on my huge MFC library of books that are VC 6.0 intensive?
sf
|
|
|
|
|
The MFC in VC7 is nearly identical to that in VC6. The biggest changes are under the hood and those are limited. The CString class, for example, is now shared with ATL and uses CStringT which is derived CSimpleStringT.
So, go ahead and use your huge library of MFC books.
Joe Woodbury
When all else fails, there's always delusion.
- Conan O'Brien
|
|
|
|
|
In the OnSize handler of my main window (CDialog) I am trying to reposition a listbox in my OnSize handler. I have the following code (I have stripped it down to what is still causing the crash. The assertion error only occurs when the window is first displayed.
void CDlg::OnSize(UINT nType, int cx, int cy) <br />
{<br />
m_ListBox.MoveWindow(10, 10, 50, 50, TRUE);<br />
CDialog::OnSize(nType, cx, cy);<br />
}
The error is an assertion failing in winocc.cpp:
void CWnd::MoveWindow(int x, int y, int nWidth, int nHeight, BOOL bRepaint)<br />
{<br />
ASSERT(::IsWindow(m_hWnd));<br />
<br />
if (m_pCtrlSite == NULL)<br />
::MoveWindow(m_hWnd, x, y, nWidth, nHeight, bRepaint);<br />
else<br />
m_pCtrlSite->MoveWindow(x, y, nWidth, nHeight, bRepaint);<br />
}
If I click "Ignore" when presented with the assertion error, execution continues just fine except that the listbox didn't get repositioned. On all subsequent OnSize calls, the listbox gets repositioned correctly.
Since I know the starting size of my dialog box, I can work around this by setting a flag so that during the initial OnSize call it won't reposition the listbox and I can just futz around in the resource editor trying to position it but it seems this isn't the right way to do this.
Can anyone help here?
|
|
|
|
|
Try adding:
if( m_ListBox.GetSafeHwnd() != NULL )
< code to move >
. . .
Guess I should explain why. the list box may not have the (as your seeing) a window handle (not created) and it is trying to move it.
Larry J. Siddens
Cornerstone Communications
TAME THE DOCUMENT MONSTER
www.unifier.biz
|
|
|
|
|
That is a better firewall than my BOOL kludge; flag 
But it makes me wonder - how do you position controls in a dialog if you can't position them until after they have been displayed in the wrong place?
|
|
|
|
|
If you manually call OnSize() from your OnInitDialog() (or OnCreate()) method, then they will be positioned correctly after they've been created in their initial positions.
To have them created initially in the correct place, either have them placed correctly in your dialog template, or create the controls in code instead of on a dialog template.
Shog9
nightdrivin'withoutheadlights...
|
|
|
|
|
I tried calling OnSize()manually from within my OnInitDialog() handler - both before and after CDialog::OnInitDialog() was called with the following:
BOOL CPeriodicTableDlg::OnInitDialog()
{
CDialog::OnInitDialog();
SetIcon(m_hIcon, TRUE);
SetIcon(m_hIcon, FALSE);
Table.InitGroups();
Table.InitElements();
m_SliderRed.SetRange (0, 255, TRUE);
m_SliderGreen.SetRange(0, 255, TRUE);
m_SliderBlue.SetRange (0, 255, TRUE);
m_GroupList.SetCurSel(0);
SetSliderPositions();
SetSliderValueText();
CRect r;
GetWindowRect(&r);
OnSize(SIZE_RESTORED, r.Width(), r.Height());
return TRUE;
}
and the app hangs. No errors, just an endless loop that I have to terminate with the Task Manager.
|
|
|
|
|
That's odd... Can you break into the debugger and see where it's hanging?
Oh, one thing - donno if this is it or not, but you don't need to call CDialog::OnSize() from within your handler - normally it does nothing useful, but in this case it may call Default() or something similar (can't remember of the top of my head) which could have unwanted results.
Shog9
nightdrivin'withoutheadlights...
|
|
|
|
|
I think the reason it happened is that, child controls are created after the parent window(your dialog) is created.
As soon as your dialog is created it will be sized to the initial dimensions thus a call to CDlg::OnSize() is issued right away. However, at this moment the child control has not been created yet, so you get an assertion falilure when you try to move that control since it's not a window yet. I think you should add a verification if (::IsWindow(m_ListBox.m_hWnd)) before calling m_ListBox.MoveWindow() and you should be OK.
|
|
|
|
|
Though the other answers give methods that will work and might be safer, I have always just checked the values of cx and cy. i.e.
void CDlg::OnSize(UINT nType, int cx, int cy) <br />
{<br />
if ( cx > 0 || cy > 0 )<br />
{<br />
m_ListBox.MoveWindow(10, 10, 50, 50, TRUE);<br />
}<br />
CDialog::OnSize(nType, cx, cy);<br />
}
which also does the trick.
|
|
|
|
|
Is there a way to free memory from struct?
|
|
|
|
|
Not sure what your asking...
If you allocated memory with "new", then use "delete" and set the pointer to NULL. If you did it with "malloc", then use "free" and set the pointer.
What you could do, is create a destructor for a struct and clean up there.
Example:
struct Stuff
{
Stuff() { p = NULL, i = 0; }
~Stuff() { delete [] p; p = NULL; }
int i;
char* p;
};
using:
{
Stuff x;
x.p = new char[10];
ASSERT( x.p );
x.i = 10;
< other usage >
} // cleanup, item will be destroyed.
Larry J. Siddens
Cornerstone Communications
TAME THE DOCUMENT MONSTER
www.unifier.biz
|
|
|
|
|
I just recently got back into C++ been a few years since I have done anyhting with C++ due to RL issues. I bought the book "C++ from the ground up" and it is using features I have never used before or seen and says these are now standard C++ features. So i googled and found that Visual Studio C++ does not work well at all with this new(to me atleast) standard. I was wondering if there is a update to Visual C++ to make it compliant with the standard C++ as that is what I want to learn. Oh I almost forgot I have version 6.0. All i have found is that it is all fixed in .net. Just trying to find out if there is a update to make it compliant with standard C++ features.
RanBlade
aka Eric Ranaldi
"Passion is what drive you to stay until 4am ficing that minor bug that hardly anyone would notice...Passion is where great games come from. If you don'l live and breath games, you shouldn't be in the gaming industry" - Dave Pottinger, Ensemble Studios
|
|
|
|
|
Not that I'm aware of. I'd love to see it but it ain't never going to happen.
MS only recently gave a rat's ass about C++ standards compliance recently and took onboard several high-profile C++ gurus.
"Sucks less" isn't progress - Kent Beck [^]
Awasu 1.1.2 [^]: A free RSS reader with support for Code Project.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
