|
You can use ShowWindow with any window handle, but what window do you need to hide these items?
|
|
|
|
|
I have trouble displaying text that is in shift-jis, is there something special that i have to do to display it correctly?
Also is it possible to display an unsigned char into a textbox without casting it as a char?
|
|
|
|
|
Hi. This is not a Visual C++ question. Also, it'd be great if it worked under ANSI C.
In this function I'm writing, strings start to come up and need to be saved on a big char* one next to the other, say:
"yellow", "one", "banana" -> "yellowonebanana"
thing is that final length is unknown, it could be 1000b as well as it could be 0b. so I looked it up from Google and only solution found was to do the algorythm twice, where in the first one I calculate length, then malloc, then do again and start storing.
Is there any way to allocate and resize allocation dynamically?
Thx in advance. Mariano Lopez-Gappa.
|
|
|
|
|
|
realloc works just fine. However, it is best if you use some type of doubling algorithm on the buffer size. Thus you reduce the number of reallocations.
Tim Smith
I'm going to patent thought. I have yet to see any prior art.
|
|
|
|
|
You could create a file on the local drive and store as much as the drive would hold. There would be no need for any memory allocation or re-allocation. If you don't need speed, its an option.
|
|
|
|
|
Many thanks to all 3 answers. I'm gonna go for the realloc as it looks like it fits best my needs. Speed is not really an issue but I can't use disk. Thanks again. Case closed. 
|
|
|
|
|
Can't you do this:
1. Read in the string to a temporary max-length memory location.
2. Allocate the strings' memory using the strlen() function.
3. Use strcpy() to move the string into it's position
4. Repeat steps 1-3 until you are done
5. Deallocate the temporary string.
That's the easiest way I can I see doing it straight-forward and using only ANSI-C commands.
|
|
|
|
|
Mariano Lopez-Gappa wrote: thing is that final length is unknown, it could be 1000b as well as it could be 0b.
Is that the only difference? Memory is cheap these days. Unless you are talking about several MB of allocations, just allocate 1KB for each instance and be done with it. Yes, there might be some waste here and there, but that's a whole lot more efficient than reallocating memory.
"Take only what you need and leave the land as you found it." - Native American Proverb
|
|
|
|
|
LOL. I misread. If he is only talking about 1000b > a > 0b, then I agree with you. Start with a large 1000b buffer. If you run out of room, double the size and try again. When done, return a new allocated buffer of the final size (not a required step if memory isn't an issue).
Tim Smith
I'm going to patent thought. I have yet to see any prior art.
|
|
|
|
|
Hi,
I am using the try catch in my DLL. When i run the application in debug build it is catching the exception but application couldn't crash. When i dp the same thing in release build my application crashed inside the catch block because i am logging all the error. Can you please help me to find out the reason behind this.
catch ( _com_error &e )
{
if (e.ErrorInfo())
{
TCHAR logmsg[200];
_stprintf( logmsg, _T("Error: %lx"), e.Error() );
TGTTRACE(llItemMedium, lLogError, L"Query Data Failed - %s", logmsg);
}
return E_DATA;
}
It is crashing at return E_DATA.
Thanks
-- modified at 17:34 Tuesday 8th November, 2005
|
|
|
|
|
what are those first two parameters for TRACE ?
(ok. now you've changed your code)
Cleek | Image Toolkits | Thumbnail maker
-- modified at 20:59 Tuesday 8th November, 2005
|
|
|
|
|
that is for logging purpose related to the severity.
|
|
|
|
|
i assumed that much. but TRACE, as i know it, starts off with a strng pointer, and then a variable number of parameters. it doesn't take two parameters and then a format string and then the varargs.
Cleek | Image Toolkits | Thumbnail maker
|
|
|
|
|
Try this instead:
CString strLogMsg;
strLogMsg.Format(_T("Query Data Failed - Error: %lx"), e.Error());
TRACE(strLogMsg);
"Take only what you need and leave the land as you found it." - Native American Proverb
|
|
|
|
|
I can't use the MFC class
|
|
|
|
|
Are you sure that logmsg is large enough?
"Take only what you need and leave the land as you found it." - Native American Proverb
|
|
|
|
|
yes i tried by increasing the size. Before this i was thinking that we will never get crash in application by using try catch block however this is strange observation and it's happenning with release build only.
|
|
|
|
|
itkid wrote: this is strange observation and it's happenning with release build only.
It's probably happening in both but because of the extra stuff that is added to a Debug-build, it goes unnoticed.
"Take only what you need and leave the land as you found it." - Native American Proverb
|
|
|
|
|
A buffer with a length of 200 chars is more than large enough for a format specification of Error: %lx.
The crash is also happening outside of the try/catch block - it is happening when you return from the function. IME, a crash on return from a function is due to a fulblungered return address. Generally, this is due to stepping on your stack somehow. you can poke around by increasing the stack used both in the function and around any buffers populated by the function.
For example, add TCHAR __caCrashBuf1[ 1024 ] at the top of the function, and something like TCHAR __caCrashBufzyx[ 1024 ] around any buffers used by the function. If you do that and the crash stops or changes, you can narrow down the location that is stepping on the stack.
I would also be investigating that TGTTRACE(...) function. FWIW, it also looks like you can get rid of the logmsg buffer by building the error string in the TGTTRACE(...) function (no need to build strings twice):
TGTTRACE( llItemMedium, lLogError, L"Query Data Failed - Error: %lx", e.Error() ); Peace!
-=- James
If you think it costs a lot to do it right, just wait until you find out how much it costs to do it wrong!
Tip for new SUV drivers: Professional Driver on Closed Course does not mean your Dumb Ass on a Public Road!
DeleteFXPFiles & CheckFavorites (Please rate this post!)
|
|
|
|
|
Two questions:
1) What is the definition of the TGTTRACE macro? Is it defined in the release build?
2) Is this a Unicode build? Seems odd to mix the _T(..) and L... constructs.
|
|
|
|
|
TGTTrace is use to log the error into the file. It's unicode release
-- modified at 11:47 Wednesday 9th November, 2005
|
|
|
|
|
Hello,
Arn't trace macro's removed in release builds?
Anyway, maybe your stack gets corrupted by a non NULL terminated string. Use _sntprintf() instead. You can specify the max number of characters. This way you won't corrupt the stack.
Hope this helps.
Behind every great black man...
... is the police. - Conspiracy brother
Blog[^]
|
|
|
|
|
Hello,
ok my problem is that i don't know how to parse a config file. The file is read line by line into a char[255]. The config file looks like this:
some_proberty = some_value
test2 = test3
url = www.codeproject.com
So there is always the name an then = and then the value. In Visual C++ I would use CStrings which have the Trim, Left, Right Functions, etc. But it seems there are no such functions for the char. So how can I read my config file ?
With best regards,
Benedikt
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
