|
The depicted behavior is not so strange...
George_George wrote: 1. For string array, dereferencing it will result in the string itself, but for int array, dereferencing it will result in the address of the array;
In fact the behavior is quite similar: the name (or the address-of operator & applied on the name, remembering past posts...  ) of the int array returns the address of the memory containing the integer values as well the name of the character array returns the address of the memory containing the character values;
you find a noticeable difference in the output only because a (C-like) string is nothing more than the pointer to the memory holding the zero-terminated character sequence, hence whenever wcout finds a (wide) character pointer, it prints the characters belonging to the pointed memory.
George_George wrote: When dereferencing it twice (operator **), why the result is always the 1st element in both string array sample and int array sample?
Again, nothing strange here. Given a int pointer, say int *p, deferencing it means: "take the content of the pointed memory", namely the integer value at address p (that coincide with the first int element of the array). The same point applies to the character array.
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 CPallini,
What makes me confused is, in my test program before, the address of a string array should be the same as the string array itself. For example below, buf is the same as &buf.
int main()
{
char buf[] = "Hello World \n";
_ASSERT (buf == &buf);
return 0;
}
I think in the code posted in the question, me2_ptr = &me, and it is the same as me, without dereferencing it, if we simply wcout << me2_ptr, result should be the same as wcount << me? Why we need to dereferencing it by operator * in order to get the same output of wcout << me?
regards,
George
|
|
|
|
|
Because you defined (correctly) it as pointer to an array address (i.e. another pointer), i.e.
*me2_ptr contains the address of me (the same address returned by &me).
Hence me2_ptr isn't a pointer to w_chars, but instead a pointer to a pointer of w_charss (added: that turns out to be the same address...).
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.
modified on Tuesday, December 11, 2007 5:41:54 AM
|
|
|
|
|
Hi CPallini,
If you have Visual Studio at hand, you can debug my sample program, and you can find that me is the same as me2_ptr (you can watch it), so me2_ptr is the same as me, I do not know why *me2_ptr is also the same as me?
regards,
George
|
|
|
|
|
You're right. *me2_ptr and me2_ptr both hold the same address (but are different types, this way wcout behaves differently on them), this probably is related to the fact that dereferencing an array name (i.e. *me2_ptr) should return the same address returned by the array name itself.
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.
|
|
|
|
|
Thanks CPallini,
I think you mean,
1. *me2_ptr is value of array type, and wcout is overloaded to print out the string array;
2. me2_ptr is address of array type, and wcount will print the address of array.
Right?
regards,
George
|
|
|
|
|
Technically the ostream extraction operator << is overloaded, but, poorly speaking the answer is yes.
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.
|
|
|
|
|
Cpallini has already explained at some length (to me too!) how the address of an array has the same value for convenience to printf (and it's relations).
The two bits of code you've shown do the same thing with derefencing. The only difference is that the wcout is clever enough to go "oh, I won't give a number, I'll give a lump of text - aren't I helpful?".
The short answer to question 2
BECAUSE.
Longer answer...
Because it has been defined that way by people cleverer than us.
Is this feature causing you problems?
Iain.
|
|
|
|
|
Thanks Iain,
My question is answered.
regards,
George
|
|
|
|
|
Hi,
I am using WM_CTLCOLOR to make the static text transparent and change the font and colour. Please can you tell me how to do the font-clean-up action if any is required here?
HBRUSH CF4_NewEstimate::OnCtlColor(CDC* pDC, CWnd* pWnd, UINT nCtlColor)
{
HBRUSH hbr = CResizableFormView::OnCtlColor(pDC, pWnd, nCtlColor);
CFont *m_pFont = new CFont;
m_pFont->CreateFont(12,0,0,0,600,0,0,0,0,0,0,ANTIALIASED_QUALITY,0,"MS Sans Serif");
CFont *pOldFont = NULL;
switch (nCtlColor)
{
case CTLCOLOR_STATIC:
pDC->SelectObject(m_pFont);
hbr = (HBRUSH)::GetStockObject (HOLLOW_BRUSH);
pDC->SetBkMode (TRANSPARENT);
pDC->SetTextColor(RGB(255,128,0));
break;
}
return hbr;
}
Thanks.
Fortitudine Vincimus!
|
|
|
|
|
Tara14 ase CTLCOLOR_STATIC: pDC->SelectObject(m_pFont);
This is not the correct way to change the font of a window. You should call the SetFont() function to change the font and this need to be done only once( in OnInitdialog() or OnIntitialUpdate() function etc ).
|
|
|
|
|
I want to add a 16-bit color cursor.
But when I insert a new cursor, there is a default monochrome one, and LoadCursor will use that one by default. How to use 16-bit cursor?
|
|
|
|
|
Just design your cursor in the resource editor, give it a IDC_NAME and use ::LoadCursor and ::SetCursor.
if you load it but not set it active...
Greetings.
--------
M.D.V. 
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
Help me to understand what I'm saying, and I'll explain it better to you
“The First Rule of Program Optimization: Don't do it. The Second Rule of Program Optimization (for experts only!): Don't do it yet.” - Michael A. Jackson
|
|
|
|
|
setted, but the monochrome one using the same ID takes effect
|
|
|
|
|
This is to set the normal white arrow that is always in all MFC-Win32 app by default.
HCURSOR m_hCursor;
;
m_hCursor=AfxGetApp()->LoadStandardCursor(IDC_ARROW);
if (m_hCursor)
::SetCursor (m_hCursor);
And here I set my own drawn cursor
m_hCursor=AfxGetApp()->LoadCursor(IDC_SELPOINT);
if (m_hCursor)
::SetCursor (m_hCursor);
Note that the ID that I use to load my own cursor is the ID that I give to the cursor in my resources editor.
What are you making?
Greetings.
--------
M.D.V.
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
Help me to understand what I'm saying, and I'll explain it better to you
“The First Rule of Program Optimization: Don't do it. The Second Rule of Program Optimization (for experts only!): Don't do it yet.” - Michael A. Jackson
|
|
|
|
|
That's just what I do.
The problem is that I added a "16-bit color" cursor, not the default monochrome one. But LoadCursor will load the monochrome one instead of the "16-bit color" one. They have the same ID.
|
|
|
|
|
How can one determmine if a given floating point variable is a mathematical integer (1,2,3,4,5...)? I figured I could divide by one and check for zero as a remainder. Doesn't work.
float fNumber = 861;
float one = 1;
fmod(fNumber, one)
modf(fNumber, one)
Both of these return a value of .9998936354755 (or some other decimal very close to 1).
I've tried various combinations of float and double, but get the same results.
Ideas? Thanks.
|
|
|
|
|
It's floating point inaccuracy occured on every common pc.
Control it manually.
For example:
float f=861;
When you assin 861, it could be a little more or a little less than it,
like 860.99999 or 861.00001
You can do like this:
f+=0.00001f to make sure it is a little more than 861
...
|
|
|
|
|
followait wrote: float f=861;
When you assin 861, it could be a little more or a little less than it,
This is not true, the floating point standard guarantees that integer representation is perfect, so
float f = 861;
will result in f being 861 precisely. Integer arithmetic also is precise if it stays integral, so
f = float(1722)/float(2);
results in f being 861 precisely. Once your expression moves away from being able to be represented exactly then the sorts of precision errors you mention occur. e.g.
f = (float(10)/float(3))*float(3);
should be 10 but you will see rounding errors.
Peter
"Until the invention of the computer, the machine gun was the device that enabled humans to make the most mistakes in the smallest amount of time."
|
|
|
|
|
I don't know of a simple test, but you can use floor(), ceil() or fmod() to help. e.g.
if (f == floor(f)) {}<br />
<br />
if (f == ceil(f)) {}<br />
<br />
float intPart;<br />
if (fmod(f,&intPart) == 0) {}
I don't know what is most efficient if speed is important.
Peter
"Until the invention of the computer, the machine gun was the device that enabled humans to make the most mistakes in the smallest amount of time."
|
|
|
|
|
Hi,
My project is written in C++ using MFC and VC++ .NET 2005.
My problem is this:
When I run my program on any computer that has .NET 2005, it seems to work fine. However, if I move it over to a computer without any IDE (like a fresh WinXP SP2 install) it crashes whenever I try to call an application-specific dll file.
So it's like this, let's say a part of my application uses a dll file called utils.dll. Utils.dll normally is used to start up a "utility" thread which accesses a database that contains various useful information. Normally the application runs fine, however, if I move it to another computer (along with all of the dlls I can think of that it might possibly need) it will crash as soon as I try to call a function from utils.dll (utils.dll IS in the folder with the program where it should be, and I know it's loading because I can still call static functions from it).
Any idea of what might be happening?
I have all the dlls included that I could think of (mfc80.dll, msvcr80.dll, etc etc) but I feel like maybe I'm missing one somehow and I don't know how to tell what it could be.
Sorry if I made this sound overly complicated, but it's a very irritating problem.
Thanks!
KR
|
|
|
|
|
I am using installsheild dev studio 9. I have a install program that looks for a serial number when you enter it in a blank field. At the time of purchase, our customers receive the serial and need to enter it when they install. The problem is that the serial number has dashes and 25% of our customers cant figure out to use the dashes.
I came up with the Idea of (same as windows vista style) of having the program automatically insert the dash or have 3 boxes that automatically change focus. How is this done??
|
|
|
|
|
Trey5498 wrote: I came up with the Idea of (same as windows vista style) of having the program automatically insert the dash or have 3 boxes that automatically change focus. How is this done??
For the former, check out masked edit controls.
For the latter, handle the EN_CHANGE message for each edit control. Each time that notification is received, check to see how many characters are in the control. If three, send the window a WM_NEXTDLGCTL message.
"Normal is getting dressed in clothes that you buy for work and driving through traffic in a car that you are still paying for, in order to get to the job you need to pay for the clothes and the car and the house you leave vacant all day so you can afford to live in it." - Ellen Goodman
"To have a respect for ourselves guides our morals; to have deference for others governs our manners." - Laurence Sterne
|
|
|
|
|
Hi, this one is for the MFC aces:
I got a rather complicated CListCtrl (owner draw and owner data) with a 100 entries, though I don't think that should matter for this issue.
Calling SetItemState(...) takes me about 30 ms on my rather new PC (maybe half the time in release mode), when it has to alter an item state. When the item state stays the same, it returns instantly.
Calling SetItemState(-1, ...) takes about the same time as any other SetItemState(...) call, even if it alters all items.
It doesn't really make a difference if the ListCtrl is SW_SHOW or SW_HIDDEN and setting ListCtrl.SetRedraw(false) doesn't help either.
When just a couple of items are changed at the same time, I get a noticeable break. Has anybody experienced something similar or knows a work-around? (I'm just asking before starting to write test cases)
Thanks in advance,
Andy
|
|
|
|
|
Doc Lobster wrote: I got a rather complicated CListCtrl (owner draw and owner data) with a 100 entries, though I don't think that should matter for this issue.
Calling SetItemState(...) takes me about 30 ms on my rather new PC (maybe half the time in release mode), when it has to alter an item state. When the item state stays the same, it returns instantly.
It sounds like the list control is sending messages to announce the state change before it returns. I'm not sure there is any way to disable that.
Nathan
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
