|
Oh perfect. It works now!
BUT:
While testing, I used a string that was 442 chars long, so not longer than those 500!
And no, I couldnt easily convert the string to LPCSTR, cause the string is an own written class (not by me), but I found out that there is a c_str method in this class. And now, it works!
Amazing. Thanks so much, this was a very clear answer, and I can learn alot from it, on how to code better!
DKT
|
|
|
|
|
Glad to help.
Cheers
Steen.
"To claim that computer games influence children is ridiculous. If Pacman had influenced children born in the 80'ies we would see a lot of youngsters running around in dark rooms eating pills while listening to monotonous music"
|
|
|
|
|
Windows has always let you change the colour depth of the desktop e.g. XP lets you choose between 32- and 16-bit colour quality.
But what's the point? Once upon a time, speed and memory might have been an issue but that's hardly relevant now. I'm going nuts trying to make sure my app renders toolbars and other images correctly by supplying bitmaps and icons with different colour depths but is it even necessary?
Do people actually run at a lower colour depth any more?
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.
|
|
|
|
|
|
Chris Losinger wrote:
yes
Um, OK. Why? Other than corner cases such as running Windows in safe mode, the only reason I could think of was lack of memory or graphics processing power. But surely that's almost a non-issue these days.
The reason I ask is that I'm trying to decide if it's worth wasting spending time supporting multiple colour depths in my app. Currently, I use 32-bit images (where my GUI toolkit supports them, 24-bit otherwise) and fallback to 8-bit when the colour depth is less than 32. Testing shows that my app looks more or less acceptable at lower colour depths but there are one or two places where it's completely wrong (black blocks) and I can't seem to fix them. I'm want to just forget about them say it's not worth spending the time trying to fix them since nobody runs at a lower colour depth 
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.
|
|
|
|
|
Taka Muraoka wrote:
Why?
low-powered graphics cards on cheap/older laptops.
Taka Muraoka wrote:
The reason I ask is that I'm trying to decide if it's worth wasting spending time supporting multiple colour depths in my app
personally, i wouldn't bother.
Taka Muraoka wrote:
there are one or two places where it's completely wrong (black blocks)
how are you doing your RGB 16<->RGB 32 conversion ?
Cleek | Image Toolkits | Thumbnail maker
|
|
|
|
|
Chris Losinger wrote:
low-powered graphics cards on cheap/older laptops.
That's what I figured. People running that kind of hardware are only going to be using the free version of my software anyway
Chris Losinger wrote:
how are you doing your RGB 16<->RGB 32 conversion ?
The problem only occurs when I'm trying to draw 8-bit images on a 16-bit display under W2K (for example. XP is OK).
I don't draw the image myself, I just pass it to my GUI toolkit. BCGSoft's toolkit is generally pretty good but I've already hit one or two rendering bugs (on non-XP systems) so I'm not sure if this problem is being cause by BCG's toolkit, something I'm doing wrong or a problem in the image file.
I've noticed odd things when working with the image file. I fill the background to RGB(255,0,255) but when I reopen the file, many (but not all) of the pixels are RGB(254,0,254). IIRC, 8-bit images have a colour palette but I haven't got a tool that lets me examine the palette. But when I switch in another image file that works, I still get the same problem so I'm somewhat confused 
Given that things work OK under XP at all colour depths, I'm suspecting it's a problem with BCG.
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.
|
|
|
|
|
There are some gotchas when converting to a paletted format. First off (in Windows anyway) you don't get a whole 256 color palette - windows reserves a number of colors for drawing UI elements when the video card is in 8-bit mode. Second, you don't necessarily get 8-bits of precision for each color channel even in the palette - when the hardware is in 16-bit mode, you'll get 5-6-5 or some such division among RGB, while in 8-bit mode, the palette (on older hardware at least) will only support 18-bits for each entry.
It is possible to write a conversion routine that takes this into account, and still produces reasonably good results (tell me if you want code). But you're generally better off using a program where you can hand-tune the results. The free GIMP lets you manually edit the palette of 8-bit images, while the excellent (but not free) PaintShop Pro supports the Windows palette directly. For icons, Microangelo does it all.
|
|
|
|
|
Taka Muraoka wrote:
Um, OK. Why? Other than corner cases such as running Windows in safe mode, the only reason I could think of was lack of memory or graphics processing power. But surely that's almost a non-issue these days.
I wish it was a non-issue.... However, those of us who are using massive amounts of memory are accustomed to applications failing on us. 
I have a 256Mb state of the art graphics card, and 2 gig of memory, and still paging off of disk because of earth datasets relative to about 50gig of total data. I normally run at 32bit color, except when we have a particular large dataset that I don't mind sacrificing color depth to display more of the dataset, then I will cut to 16bit color and double my available graphics memory.
My boss promised a new card, but he is holding out for a 512mb current series. I'll have it abused beyond the year end.
Taka Muraoka wrote:
I'm want to just forget about them say it's not worth spending the time trying to fix them since nobody runs at a lower colour depth
I would say check with your user base. Like I said those of us who have strange needs are used to strange failures because of them.
_________________________
Asu no koto o ieba, tenjo de nezumi ga warau.
Talk about things of tomorrow and the mice in the ceiling laugh. (Japanese Proverb)
|
|
|
|
|
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.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
