|
Jeffry J. Brickley wrote:
However, those of us who are using massive amounts of memory are accustomed to applications failing on us.
He he. I can think we can safely categorize this as a corner case. If someone comes to me after having pushed their PC to within an inch of its limits and then some, and then complains that the colours in my program go a bit funny, well, that bug report goes straight to the bottom of the pile 
The two most common elements in the universe are Hydrogen and stupidity. - Harlan Ellison
Awasu 2.1.2 [^]: A free RSS reader with support for Code Project.
|
|
|
|
|
Is it possible to set environment variables on the client machine in an install project? And if so, could someone point me in the direction of some useful information on the subject. I am using VC++ 7.1.
Thanks in advance,
Charles
|
|
|
|
|
Okay...
Calling SetEnvironmentVariable has no effect on the system environment variables. The user can add or modify system environment variables using the Control Panel. To programmatically add or modify system environment variables, add them to the HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Session Manager\Environment registry key, then broadcast a WM_SETTINGCHANGE message. This allows applications, such as the shell, to pick up your updates. Note that environment variables listed in this key are limited to 1024 characters.
|
|
|
|
|
Hi all..i am right now involved in an application where i need to show the user some information.i need this information show up to be similar to when we login into yahoo messenger if we have some mail then at the right bottom a screen will scroll up slowly showing a dialog sort of message box with info you got 5 mails and after a period of time it will scroll down and vanish..any idea how this can be achieved
|
|
|
|
|
arun srinivasan v wrote:
...at the right bottom a screen will scroll up slowly showing a dialog sort of message box...
I think those are called "toaster windows."
"One must learn from the bite of the fire to leave it alone." - Native American Proverb
|
|
|
|
|
Look here[^]
And here[^]
"Success is the ability to go from one failure to another with no loss of enthusiasm." - W.Churchill
|
|
|
|
|
test
"Success is the ability to go from one failure to another with no loss of enthusiasm." - W.Churchill
|
|
|
|
|
Hi everyone,
I am having following problem.
I have a function
char* foo()
{
char c[ARRAY_SIZE] = "some text";
return c;
}
and now i want to print the text this function returns
int _tmain(int argc, _TCHAR* argv[])
{
char * tmp =foo();
for(int i=0; i<ARRAY_SIZE; i++)
{
cout<<*(tmp);
tmp++;
}
return 0;
}
and in output i get text where first symbols is 's' and other's are
some other strange symbols.
In debugger i see that tmp really points at the text
tmp (0x0012fdd4 "some text")
, but right after the cout operator is invoked tmp changes its value to strange symbols 
What am i doing wrong???
thanks for help
"Success is the ability to go from one failure to another with no loss of enthusiasm." - W.Churchill
-- modified at 9:07 Wednesday 21st September, 2005
|
|
|
|
|
Giorgi Moniava wrote:
What am i doing wrong???
The memory that the variables in foo() point to goes away when the function exits. An alternative would look like:
TCHAR *foo( void )
{
TCHAR *c = new TCHAR[ARRAY_SIZE];
_tcscpy(c, _T("some text"));
return c;
}And remember to free the memory using delete [].
"One must learn from the bite of the fire to leave it alone." - Native American Proverb
|
|
|
|
|
thanks david for your fast reply
i was surprised when in my code even after the function foo() ended up in debugger , tmp was still pointing at that text (tmp 0x0012fdd4 "some text") now i understand that it pointed to freed memory.
but as i see only memory block 0x0012fdd4 still existed as the 's' symbol was printed in the output. and next 8 blocks were destroyed . right yes ?
"Success is the ability to go from one failure to another with no loss of enthusiasm." - W.Churchill
-- modified at 9:24 Wednesday 21st September, 2005
|
|
|
|
|
Giorgi Moniava wrote:
i was surprised when in my code even after the function foo() ended up in debugger , tmp was still pointing at that text (tmp 0x0012fdd4 "some text")
Don't be surprised. Until Windows has a need to put something else at that memory location, it could remain there indefinitely.
Try this. In foo(), make a note of the memory address pointed to by c. Back in main() after foo() returns, make a call to IsBadStringPtr(). It should give you a non-zero return value indicating that you do not have read access to that location.
"One must learn from the bite of the fire to leave it alone." - Native American Proverb
|
|
|
|
|
Not necessarily.
Where malloc and free or new and delete are concerned, only if the underlying memory manager has decomitted and released the virtual memory block. Otherwise, it is still a valid memory block for reading and writing as far as the OS is concerned, but not as far as the underlying memory pool manager is concerned. After it is 'freed' it is probably marked with a header and added to the internal memory manager free list.
IsBadStringPtr will only work if there is no NUL byte encountered before you get to the end of the underlying virtual memory block.
He might have been be able to find out it is not valid my calling something else, except that this particular memory was from the stack, so that makes it even more interesting. It depends upon how much the stakc had actually grown and where a NUL byte might be coincidentally located if the IsBadStringPtr will trigger or not.
|
|
|
|
|
Blake Miller wrote:
IsBadStringPtr will only work if there is no NUL byte encountered before you get to the end of the underlying virtual memory block.
If that was the case, then IsBadReadPtr() should be used instead. Yes?
"One must learn from the bite of the fire to leave it alone." - Native American Proverb
|
|
|
|
|
To test an exact amount of memory, yes, the IsBadReadPtr() should be used. The IsBadStringPtr() will stop at the first NUL it encounteres, therefore not necessarily testing the specified range of memory.
|
|
|
|
|
Blake Miller wrote:
The IsBadStringPtr() will stop at the first NUL it encounteres, therefore not necessarily testing the specified range of memory.
But since Giorgi was dealing with a nul-terminated string in memory, range was not an issue. For ANSI strings, they won't have more than one nul character so IsBadStringPtr() will work. I can't say the same for Unicode strings, however.
"One must learn from the bite of the fire to leave it alone." - Native American Proverb
|
|
|
|
|
What I was reying to imply was the following:
1. He has address of string that was on the STACK of a function which has already returned.
2. If he calls IsBadStringPtr() he will get an answer depending upon if the data happens to hit a NUL byte or not before reaching the end of the stack memory. If he limits the range to the size of the orignal stack variable, it might still return as 'okay', even though we already know technically it is not.
3. The answer should be BAD, but it won't necessarily be bad because that stack memory would probably still be valid AND he might have a NUL byte in there.
So, my final answer is that IsBadStringPtr will let you know if it is truly bad, but it should not ever be used as a test that it is good. In this case it would imply the memory is okay to use, but indeed it is not - you will be overwriting your stack,a nd if you are only reading, you are probably reading code and local variables of another function by now.
|
|
|
|
|
You might find this code snippet I developed interesting:
You can call this to find out if the address is a member of the local stack memory pool or not.
If not, it might be a local function of another thread’s stack, or from the memory allocation pool.
<br />
<br />
BOOL WINAPI IsOnStackOrNot(LPCVOID pObject)<br />
{<br />
BOOL bRetVal = FALSE;<br />
<br />
if( pObject ){<br />
<br />
LPVOID pStack;<br />
MEMORY_BASIC_INFORMATION TheMemoryInfo;<br />
<br />
_asm mov eax, esp;<br />
_asm mov pStack, eax;<br />
<br />
if( sizeof(TheMemoryInfo) <= VirtualQuery(pStack, &TheMemoryInfo, sizeof(TheMemoryInfo)) ){<br />
if( ((DWORD)pObject >= (DWORD)TheMemoryInfo.BaseAddress) &&<br />
((DWORD)pObject <= ((DWORD)TheMemoryInfo.BaseAddress + (DWORD)TheMemoryInfo.RegionSize) ) ){<br />
bRetVal = TRUE;<br />
}<br />
}<br />
}<br />
<br />
return bRetVal; <br />
}<br />
<br />
If you also compared address to CURRENT value of ESP and EBP, you could probably deduce if it is a local variable, a parameter, or something from a PREVIOUS function call's stack.
|
|
|
|
|
In function foo, the pointer you are returning points to a temporary stack string that goes out of scope when the function returns. You need to allocate memory on the heap using new and then return this pointer. Of course, now you'd need the caller to manually delete the string.
|
|
|
|
|
"some text" gets placed on the stack. it will remain there until the next function call. when cout is called, it places the arguements on the stack and will overwrite part of "some text". if you make the array a const or static it will go in the code or data segment (not the stack) and it will remain.
Just livin a dream.. dont wake me!
|
|
|
|
|
I'm writing an app that I want to be able to dynamically move some controls around on my dialog box. I was thinking of simply using ::GetWindowRect() and ::MoveWindow() to do that, but for those functions I need the window handle (HWND). Can the member variable connected to those controls work as the window handle, or houw can this be done?
Danny
|
|
|
|
|
bugDanny wrote:
Can the member variable connected to those controls work as the window handle, or houw can this be done?
Why not just use CWnd::GetWindowRect() and CWnd::MoveWindow()? No handle required.
"One must learn from the bite of the fire to leave it alone." - Native American Proverb
|
|
|
|
|
You can use control variable associated with it.Alternatively ,Use GetDlgItem() for getting control windows and use those.
|
|
|
|
|
Depending on what you want to do, there is also some nice articles on here for dynamically moving all controls when resizing dialogues.
I tend to map controsl to control variables and use their own move methods, eg:
m_btnOK.MoveWindow(...);
Rather than:
pWnd = GetDlgItem(IDOK)
if(pWnd != NULL)
pWnd->MoveWindow(...)
Mapping variables to the controls uses less code and no need to worry about correct id values, null pointers etc.
HTH.
Andrew
|
|
|
|
|
Most controls are directly derived from CWnd, in which case you can use the CWnd member function of ::GetWindowRect() and ::MoveWindow(), meaning :
RECT rect;
m_mycontrol.GetWindowRect(&rect);
If you absolutley want to use the upper scope functions, you can retrieve the HWND using GetSafeHwnd()
HWND hWnd = m_mycontrol.GetSafeHwnd()
BTW, you might want to consider also GetClientRect(), as well as ScreenToClient() and ClientToScreen() to play around moving controls, because I am afraid that the two functions you mentioned will not be sufficient.
Hope this helps,
~RaGE();
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
