|
Hi all,
In my SDI applocation, I play the video file with the help DirectX.
Now I have to draw buttons over the running video image.
When trying for the same it's getting appear behind the video.
How to create buttons on the video
Thanks in Advance,
Chinna
|
|
|
|
|
Guys,
I am tring to dynamically move the positions of the child dialogs whenever the parent dialog is resized. But I started getting confused with the values passed to GetWindowPos for the dialogs.
Bsically, I have a parent dialog class, CMyDlg and the dialog contains a Group Box (IDC_SUBFRAME). the child dialog (CMainDlg) should fall into the centre of IDC_SUBFRAME. In CMyDlg::OnInitDialog(), I embedded the child dialog with following code:
CRect frameRect, childRect;
(GetDlgItem(IDC_SUBFRAME))->GetWindowRect(&frameRect);
pMainDlg = new CMainDlg();
pMainDlg->Create(IDD_MAIN_DIALOG, this);
pMainDlg->GetWindowRect(&childRect);
pMainDlg->SetWindowPos(this, frameRect.left + ((frameRect.Width() - childRect.Width())/2),
frameRect.top + ((frameRect.Height() - childRect.Width()) / 2),
childRect.Width(), childRect.Height(), SWP_NOZORDER);
pMainDlg->ShowWindow(SW_SHOW);
I found the child dialog was sitting in the Group Box frame, but not quite at the centre. Through the debug, I found the values of the CRects are quite strange:
frameRect {top=150 bottom=472 left=13 right=600}
childRect {top=30 bottom=132 left=4 right=517}
How come the frame's top and left are larger than the child dialog's, when the child dialog actually sits IN the frame when initialised. To better illustrate, the big box below is the frameRect and the small box within is the childRect.
---------------------
| |
| --------------- |
| | | |
| --------------- |
---------------------
From my understanding, GetWindowRect returns the coordinations in relation to the display (monitor). If so, wouldn't the frame's top and left values be smaller than the child dialog's?
Could anyone help me on this?
Thanks
|
|
|
|
|
I sympathize with you one this because I was doing the same thing last week only with more "layers" of windows and it got real confusing. Key points to remember:
1) Use GetClientRect to get the original size of the parent window
2) After you have resized with MoveWindow calculate the difference in width and height and store it somewhere for later use
3) Use GetWindowRect for the child window and MAKE SURE THE FIRST PARAMETER IS THE PARENT WINDOW...this is a common mistake that's easily overlooked.
4) Convert the rect.left and rect.top coordinates you just got with ScreenToClient to get client coordinates relative to the parent window
5) Final step, use SetWindowPos for the child windows with the difference in size (calculated earlier). eg.
// Apply the new height
lNewHeight = (rcTab.bottom - rcTab.top); // The original height calculate from GetWindowRect
lNewHeight += lDifference; // Add the difference calculated from the change in dimensions of the parent window. This will work regardless if the window became smaller or larger.
I hope I didn't confuse you more
|
|
|
|
|
georgiek50 wrote:
3) Use GetWindowRect for the child window and MAKE SURE THE FIRST PARAMETER IS THE PARENT WINDOW...this is a common mistake that's easily overlooked.
Thanks you for the reply georgiek50,
however, GetWindowRect for me does not taken two parameter, with the compiler error,
'CWnd::GetWindowRect' : function does not take 2 parameters
I found the variant of GetWindowRect in Platform SDK, but how do I use it. Also, from the descriptions, I cannot see how the additional parameter affects the coordinate values copied.
Thanks again
|
|
|
|
|
The "variant" I guess can only be used in Win32. If you mean the additional parameter being HWND it affects the values because it is getting the values relative to the values of of the window "below" it, just like GetWindowRect of the main dialog gets the values relative to the window (in this case the monitor/screen) "below" it. I'm sorry I can't explain this better than words, a drawing would be appropriate.
|
|
|
|
|
It's perfectly clear, thanks alot georgiek50
My development is under MFC, if considering my situation, GetWindowRect always get the values relative to the monitor/screen, correct? And as illustrated in my original post, how come the childRect left and top values are smaller than the frameRect's, when the display of the app actually has the child dialog sitting INSIDE the subframe. It does not seem to make sense.
|
|
|
|
|
It is smaller because: your main window rect.top = 150, correct, and your child is 30 correct? So relative to the top of your MONITOR, the main window is at 150 and the child is at 180 (150+30)...but relative to your main window it is only 30...do you see now? GetWindowRect apparently in MFC needs only one paramater because it uses the owner of the child window for reference/starting point coordinates.
|
|
|
|
|
Hi georgiek50,
thanks for the reply. My drawing turns out to be a little misleading. frameRect and childRect are values for the SUBFRAME (a Group Box) and child dialog respectively, so neither of them is the main dialog (main window). The SUBFRAME placed inside the main dialog is used a reference box which the child dialo later created needs sit at the centre of it. In this case, to guess what you mean, the 150 now will be the "top" value of the SUBFRAME relative to the main window, correct? And the 30 will be the "top" value of the child dialog relative to the SUBFRAME?
If my guess is right, to let the child dialog to sit at the centre of the SUBFRAME, shouldn't it just be
pMainDlg->SetWindowPos(this, frameRect.left + ((frameRect.Width() - childRect.Width())/2),
frameRect.top + ((frameRect.Height() - childRect.Height()) / 2),
childRect.Width(), childRect.Height(), SWP_NOZORDER);
in the main dialog's OnInitDialog(). pMainDlg is the pointer to the child dialog.
Sorry for the trouble, appreciate any further help.
EDIT: further obersve the CRect value of the main dialog from
GetClientRect(&mainRect)
mainRect {top=0 bottom=465 left=0 right=606}
|
|
|
|
|
Ok, after another long look, I think the way I have done it is correct. As to why the child dialog always appear not at the centre, but slightly towards the bottom part of the SUBFRAME (as illustrated), I do not know. Has it got something to do with the fact the child dialog's Border property is set to None and Control to True? Or the nature of the Group Box which always leaves a siginifcant large "top" margin?
|
|
|
|
|
I have run into a situation that has me a bit confused. I have a dialog in my app which has a tab control in it, and each different tab has a modeless dialog in it. I am trying to get keyboard functionality for the modeless dialogs (eg. using TAB to switch between button controls) but with no success. I have declared a global HWND hDlgModeless and put it into my main message loop like so:
while (GetMessage (&msg, NULL, 0, 0))
{
if ( hDlgModeless == NULL || !IsDialogMessage(hDlgModeless, &msg) )
{
if ( !TranslateAccelerator(hwnd, hAccel, &msg) )
{
TranslateMessage(&msg) ;
DispatchMessage(&msg) ;
}
}
}
return msg.wParam;
I create each modeless dialog from within the WM_INITDIALOG of the modal dialog (which has the tab control) setting the parent window to be the modal dialog and a common dialog procedure for all the modeless dialogs. When I process TCN_SELCHANGE I just set hDlgModeless to equal the current modeless dialog the user has selected from the tab. Everything works great except for keyboard functionality. Is my approach in dealing with messages or in general, the setup completely wrong?
|
|
|
|
|
What am I doing incorrect. I am trying to check if the first
letter of the string is lower, if so convert to upper.
string title
if (islower(title[0]))
{ static_cast<char>(toupper(title[0]));};
|
|
|
|
|
Upper and lower alpha ASCII characters differ by 32. One solution is to add or subtract 32.
Kuphryn
|
|
|
|
|
like this?
static_cast<char>(toupper(title[0])-32)
|
|
|
|
|
The conversion is not inplace; it returns an uppercase character. I wouldn't even bother checking the case since toupper does it for you. Just do:
title[0] = (char) toupper(title[0]);
Anyone who thinks he has a better idea of what's good for people than people do is a swine.
- P.J. O'Rourke
|
|
|
|
|
Hi all gurus ,
I'm modifying existing code of "GinaDll" for touchscreen computers, lacking hardware keyboard. On logon window one would enter username and password with virtual keyboard, which would be part of the logon window. Before getting logon window I should boot with Ctrl-Alt-Del, but, as you understand I have no "real" keyboard. So, I encountered problem of emulating Ctrl-Alt-Del key sequnce .
I searched extensively the net for this problem with no success .
Any valuable suggestion will appreciated .
meridian22ca@yahoo.com
|
|
|
|
|
Is ExitWindowsEx() out of the question?
Five birds are sitting on a fence.
Three of them decide to fly off.
How many are left?
|
|
|
|
|
I found, ha ha ha, I'm happy
After some days of struggling I used in WlxSasNotify, dwSasType =WLX_SAS_TYPE_CTRL_ALT_DEL (indicates that user has typed the standard CTRL+ALT+DEL SAS) and solve the ptoblem.
Anyway, thank you folk thinking on my problem.
meridian22ca@yahoo.com
|
|
|
|
|
I'm trying to send a paste command to another application. A simple
SendMessage(hWnd, WM_PASTE, 0, 0);
works if the target is a CEdit or CCombo or similer. More specifically,
I can paste to notepad.exe and few other simple applications, but msvc6, msvc7 msword refuse to obey.
I tried something like this:
SendMessage(hWnd, WM_KEYDOWN, VK_CONTROL, 0x01);
SendMessage(hWnd, WM_KEYDOWN, 'V', 0x00);
SendMessage(hWnd, WM_KEYUP, 'V', 0x01);
SendMessage(hWnd, WM_KEYUP, VK_CONTROL, 0x01);
to simulate ctrl-V, but I only get two V characters.
I found this curious snippet somewhere in the web:
#define CTRL_V_PASTE 22
SendMessage(hWnd, WM_CHAR, CTRL_V_PASTE, 0);
but it doesn't work at all.
Any ideas?
|
|
|
|
|
Ok, FWIW, this is the only alternative I got working:
INPUT shift_insert[4];
memset(ctrl_v, 0, sizeof(shift_insert));
shift_insert[0].type = INPUT_KEYBOARD;
shift_insert[0].ki.wVk = VK_SHIFT;
shift_insert[0].ki.dwFlags = KEYEVENTF_EXTENDEDKEY;
shift_insert[1].type = INPUT_KEYBOARD;
shift_insert[1].ki.wVk = VK_INSERT;
shift_insert[1].ki.dwFlags = KEYEVENTF_EXTENDEDKEY;
shift_insert[2].type = INPUT_KEYBOARD;
shift_insert[2].ki.wVk = VK_INSERT;
shift_insert[2].ki.dwFlags = KEYEVENTF_KEYUP | KEYEVENTF_EXTENDEDKEY;
shift_insert[3].type = INPUT_KEYBOARD;
shift_insert[3].ki.wVk = VK_SHIFT;
shift_insert[3].ki.dwFlags = KEYEVENTF_KEYUP | KEYEVENTF_EXTENDEDKEY;
SendInput(4, shift_insert, sizeof(shift_insert[0]));
ctrl-V didn't seem to work even with SendInput().
|
|
|
|
|
Uh, a typo: replace ctrl_v with shift_insert in the above snippet.
|
|
|
|
|
The problem is the following:
The text of inserted items do not appear if and only if i call DeleteAllItems() before inserting them. Something like this:
CTreeCtrl* pTreeCtrl = ( CTreeCtrl* ) GetDlgItem( IDC_TREE );
if ( !pTreeCtrl ) return;
if ( !pTreeCtrl->DeleteAllItems() ) return;
pTreeCtrl->InsertItem( "testing" );
pTreeCtrl->InsertItem( "testing1" );
If i remove the DeleteAllItems() function call everything works as it should.
Any tip ? Thanks
|
|
|
|
|
This is a known issue. There is a MS article about that.
The problem can be resolved by calling SetRedraw(TRUE).
Example:
DeleteAllItems();
SetRedraw(TRUE);
InsertItem(...);
The problem is that DeleteAllItems resets internal counter (number of items) to -1 instead of 0.
|
|
|
|
|
Problem solved! Thanks
|
|
|
|
|
I want to disable or enable all the controls on a form, but i don't want to use the classwizard to create control variables for each of them (since there are many controls). I've tried to disable the CFormView itself (EnableWindow), but that didn't work Does anybody have any ideas?
Thanks.
Er zit een korstje op mijn aars.
|
|
|
|
|
Its not the best way :
Knowing their IDs you can call
GetDlgItem( int nID )->EnableWindow (MODE) for each
or if your resource file is correctly numbered you can do a loop and disable them.
Hope it helps,
Papa
while (TRUE)
Papa.WillLove ( Bebe ) ;
|
|
|
|
|