|
or an array of int pointers.
|
|
|
|
|
 To make sure, use an array of int pointer pointers, each member pointing to the corresponding
member in the int pointer array, whose members point to the actual ints!
"Posting a VB.NET question in the C++ forum will end in tears." Chris Maunder
|
|
|
|
|
Sure that'll work.
Another alternative - make a "smart int" class, wrapping an int with some flag indicating
its initialized status  Then you wouldn't need the added indirection of a pointer.
Mark
"Posting a VB.NET question in the C++ forum will end in tears." Chris Maunder
|
|
|
|
|
A dynamic array as std::vector<int> doesn't fit your needs?
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.
|
|
|
|
|
You need to use a different value and initialize the array to that. Since you want to allow 0 to be placed in the array then use -1 to initialize it. That is fill the array with -1 and check for that. If that is not an option, and there is no other value you can use, then you have a real problem.
INTP
"Program testing can be used to show the presence of bugs, but never to show their absence."Edsger Dijkstra
|
|
|
|
|
Hi Guys,
I am developing an Encrypted VoIP application for PocketPC(Windows Mobile 5.0). The VoIP part is ready and I am looking for a AES encryption algorithm to encrypt/decrypt my RTP Payload/Packets for PocketPC Windows Mobile5.0.
Anybody knows of such an implementation ?
Thanks in advance,
Best Regards,
Gaurav
|
|
|
|
|
Just google for source code for AES if you want to roll your own. However, I believe the built-in MS crypto providers have a certified implementation of AES. I can't double check now, since I'm not at work, but I know I used the built-in AES for a previous customer who was rather anal about certified algorithms. That was XP however. It's been too long since I worked on the Mobile Windows variants to know if the full crypto is supported in those OSes. Worth checking before writing your own.
Judy
|
|
|
|
|
hey,
thanks for the suggestion .. for the time being i have found an AES implementation that worked for me .. but its a gud idea to luk for built in
support of AES in Windows Mobile .. wud do tht ..
do you think built in imlementations would be faster than the googled ones ...
|
|
|
|
|
Hello,
I am desesperate! I know that you post about AES encryption for windows mobile a long time ago... But I would be so grateful if you could tell me how do you solve your problem and how do you implement the encryption on WM.
Thanks in advance! I hope you can help me.
|
|
|
|
|
I've a tab control inside a Dialog that I would like to resize.
After getting unexpected results I created this sample code:
GetWindowRect(&Screen1);
Client1 = Screen1;
ScreenToClient(&Client1);
GetClientRect(&m_ClientRect);
SetWindowPos(NULL, m_ClientRect.left, m_ClientRect.top, m_ClientRect.right, m_ClientRect.bottom, SWP_NOCOPYBITS || SWP_NOOWNERZORDER || SWP_NOREDRAW);
GetWindowRect(&Screen2);
GetClientRect(&Client2);
Result:
Screen1 {top=0x000001ca bottom=0x000002ef left=0x00000253 right=0x0000035e}
Screen2 {top=0x000001c5 bottom=0x000002ea left=0x000001be right=0x000002c9}
Client1 {top=0x00000000 bottom=0x00000125 left=0x00000000 right=0x0000010b}
Client2 {top=0x00000000 bottom=0x00000125 left=0x00000000 right=0x0000010b}
m_ClientRect {top=0x00000000 bottom=0x00000125 left=0x00000000 right=0x0000010b}
Getting the window pos (Screen1) and converting to Client Pos (Client1) gives the same result like directly retriving the client position (m_ClientRect).
Also getting the client position after the SetWindowPos (Client2) gives the same results like before.
Nevertheless the window has moved since the screen coordinates before/after calling SetWindowPos (Screen1/Screen2) are totally different.
Where does this behaviour come from, what can I do to avoid it?
Regards
Leo
|
|
|
|
|
Chilli71 wrote: Where does this behaviour come from
It comes from the fact that you're getting the client rect when you're calling GetClientRect(), and then you're telling Windows to use this rect as the new windows rect. They are not the same - window rects includes borders, client rects do not. If you want to set a new window rect, call GetWindowRect().
|
|
|
|
|
I suppose you are telling the right thing and pointing out the wrong function.
A dc is also available. Maybe I should take some dc position functions?
I thought GetWindowRect returns the coordinates in screen coordinate system while GetClientRect returns the coordintaes relative to the parent window.
That's what I wanted to proof by using ScreenToClient to confirmn that the result is the same.
The description of SetWindowPos tells to use client coordinates. That's why I've choosen to use the GetClientRect.
According to what I understood from you answer this should work
GetWindowRect(&Screen1);
Client1 = Screen1;
ScreenToClient(&Client1);
GetClientRect(&m_ClientRect);
SetWindowPos(NULL, Screen1.left, Screen1.top, Screen1.right, Screen1.bottom, SWP_NOCOPYBITS || SWP_NOOWNERZORDER || SWP_NOREDRAW);
GetWindowRect(&Screen2);
GetClientRect(&Client2);
delivers
Screen1 {top=0x00000140 bottom=0x00000265 left=0x000001cf right=0x000002da}
Screen2 {top=0x0000027b bottom=0x000003a0 left=0x00000309 right=0x00000414}
Client1 {top=0x00000000 bottom=0x00000125 left=0x00000000 right=0x0000010b}
Client2 {top=0x00000000 bottom=0x00000125 left=0x00000000 right=0x0000010b}
m_ClientRect {top=0x00000000 bottom=0x00000125 left=0x00000000 right=0x0000010b}
Again the window is moved.
Greetz
Leo
|
|
|
|
|
From MSDN on CWnd::SetWindowPos(): All coordinates for child windows are client coordinates (relative to the upper-left corner of the parent window's client area). So your code would work the way you expect if you used Client1 instead of Screen1 in SetWindowPos().
|
|
|
|
|
If you look at my original posting and compare the results of the variables you see that is does not work.
thx
Leo
|
|
|
|
|
The description of the SetWindow/MoveWindow functions is correct when it says you have to use client corrdinates.
However it does not tell you that you move you child window within the client space of the parent window and therefore need to give the coordinates in the parent window client space format.
This is one possible solution:
inline void CMyWnd::MoveWindowRelative(RECT* Displacement, BOOL bRepaint)
{CWnd* pParCWnd;
RECT WndCoor;
pParCWnd = GetParent();
ASSERT (IsKindOf (RUNTIME_CLASS(CWnd)));
GetWindowRect(&WndCoor);
pParCWnd->ScreenToClient(&WndCoor);
WndCoor.left += Displacement->left;
WndCoor.top += Displacement->top;
WndCoor.right += Displacement->right;
WndCoor.bottom += Displacement->bottom;
MoveWindow(&WndCoor, bRepaint);
}
top + left of Displacement specify the amount you want to shift the window, bottom + rightod Displacement specify how you want to shrink or enlarge the window.
Regards
Leo
|
|
|
|
|
hi
i write a Tetris. i have completed it about 60%. main problem is that how can i bound the border of windows that block can't pass it.
another problem is their moving. They shouldn't collision with together.
how can i do that?
sorry for poor english
#Mojtaba Karimi#
|
|
|
|
|
both questions have one answer:
i guess you re-draw tetris blocks each time they move, using rectangles (RECT structure) of the block parts. so what you have to do is to check if left-most,right-most and bottom-most rectangles are inside the main window rectangle. also, the block should stop moving when the bottom-most rectangle of it touches the top-most block's rectangle on the same game column (each block part is one column wide).
you can get the rectangle of the main window using GetWindowRect() function.
but don't forget to use, ClientToScreen() and ClientToParent() functions when needed, they save more than just time.
|
|
|
|
|
Maybe the IntersectRect function (see here [^]) or the MFC flavor CRect::IntersectRect ([^]) will be useful.
Good luck.
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.
|
|
|
|
|
Hi everyone,
I've been digging up for a way to handle key presses (specifically CTRL+A KeyDown) for the EditBox in the ComboBoxEx in my IE toolbar and have failed everytime.
I tried to handle the WM_KEYDOWN events but I just couldn't. The ComboBox won't fire any event and I want to select all the text within the EditBox when user presses CTRL+A.
There must surely be a way but what could that be?
|
|
|
|
|
|
I checked out the article but there's something I just can't catch:
The ComboBoxEx does not recieve any WM_KEYDOWN events from the EditBox within. I used Spy++ to see that the event doesn't even get past the ComboBox control inside the ComboBoxEx. So, how can I catch the WM_KEYDOWN event when I can't catch it on the parent?
|
|
|
|
|
Not sure if this helps but you need to use this code to get return keys in your derived class. Maybe the same for your probem?
UINT CEdit_xx::OnGetDlgCode()
{
return( CEdit::OnGetDlgCode() | DLGC_WANTALLKEYS );
}
|
|
|
|
|
CRect stbRect;
CString cs2;
staticTextBox.GetClientRect(stbRect);
staticTextBox.GetWindowTextW(cs2);
CSize textSize = staticTextBox.GetDC()->GetTextExtent(cs2);
cs2.Format((_T("%d - %d")), textSize.cx, stbRect.Width());
AfxMessageBox(cs2,0,0);
cs2 fits the width of the static control
MessageBox reports
260 - 178
because the text is the same width as
the static control I was expecting
size.cx == stbRect.Width()
Where am i going wrong ?
-- modified at 11:19 Wednesday 16th May, 2007
|
|
|
|
|
Sorry but I was unable to locate GetWindowTextW function ,and size is variable of which class ?
|| ART OF LIVING ||
|
|
|
|
|
CSize textSize = staticTextBox.GetDC()->GetTextExtent(cs2);
If the static control is from a dialog, it may use a different font.
staticTextBox.GetDC() is returning a DC for the control but you've selected no font into it
before calculating the text extents.
Mark
"Posting a VB.NET question in the C++ forum will end in tears." Chris Maunder
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
