|
Hi. I've been quite a while out of C++, wasn't expert before either. But right now, I got a really strange problem with strcpy. Maybe somebody can help? : )
<br />
char cBuffer[256];<br />
char cTemp[260];<br />
<br />
<br />
char ch = cBuffer[0];
strcpy(cTemp, "R");
strcpy(cTemp, &ch);
So what should I do to put ch in cTemp???
Thank you in advance...
|
|
|
|
|
If you just want to copy the first character from cBuffer to cTemp , then just do:
cTemp[0] = cBuffer[0]; If you want to copy the entire string, then:
strcpy(cTemp,cBuffer); From your example, remember that ch is only a single character. There is no space for a terminating '\0' , so the strcpy is terminating on whatever random garbage follows the ch variable in the stack.
Software Zen: delete this;
|
|
|
|
|
This is really weird. Watch this! I will give you the relevant pieces of code where cTemp and cBuffer are involved. This is really strange for me.
<br />
<br />
char cTemp[260];
char cTemp2[260];
char cBuffer[256];
<br />
GetModuleFileName(0, cTemp, 249);<br />
<br />
ReadFile(hFile, cBuffer, sizeof(char)*256, &dwNumRead, NULL);<br />
<br />
strcpy(cTemp2, cBuffer);
strcpy(cTemp, cBuffer);
<br />
HOWEVER!!! If I move the declaration for cTemp2 straight before the strcpy, it works!!! Like this:
<br />
char cTemp2[260];
strcpy(cTemp2, cBuffer);
sTemp = cTemp2;<br />
Why does it work !?!?!?!?!? What does anything have to do with where I declare the variable !??!!?
I'll give you the full code, maybe there's something there I missed. There are some things here which you won't understand, but try not to get stuck in my local program logic. ASDANSIString is a class I made to work easier with strings. It's a wrapper over a char*, quite similar to the String class in .Net, it has lots of parsing methods incorporated in it.
<br />
<br />
int APIENTRY WinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance, LPSTR lpCmdLine, int nCmdShow)<br />
{<br />
ASDANSIString sTemp;
HANDLE hFile;
MSG msgPump;
DWORD dwNumRead;
long lCounter;<br />
char cTemp[260];
<br />
char cBuffer[256];
<br />
bReady = false;
lTimerID = SetTimer(0, 0, 1000, (TIMERPROC)TimerProc);
<br />
GetModuleFileName(0, cTemp, 249);
sTemp = cTemp;
sTemp = sTemp.SubStringA(0, sTemp.IndexOfRev("\\", 0));
sTemp += "\\Window Name.txt";
<br />
hFile = CreateFile(sTemp, GENERIC_READ, FILE_SHARE_READ, NULL, OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, NULL); <br />
ReadFile(hFile, cBuffer, sizeof(char)*256, &dwNumRead, NULL);<br />
CloseHandle(hFile);<br />
<br />
char cTemp2[260];
strcpy(cTemp2, cBuffer);<br />
sTemp = cTemp2;<br />
<br />
MessageBox(0, sTemp, "Test", 0);<br />
<br />
while (!bReady && GetMessage(&msgPump, NULL, 0, 0))
{<br />
TranslateMessage(&msgPump);<br />
DispatchMessage(&msgPump);<br />
}<br />
<br />
return 0;<br />
}<br />
<br />
|
|
|
|
|
Remember that ReadFile() is not a CRT function - it makes no guarantees about nul-terminating the data it reads. Try this, it will probably work:
char cBuffer[256] = { 0 };
|
|
|
|
|
Indeed you are right. This solved all the strange problems I've been seeing, even though I still can't explain why (in the above post) declaring a char just before the strcpy did not crash. Well, too much to do today to busy myself with finding that out : (... guess it'll remain to be checked out in the future : D. Thank you very much. You're in the "Thanks To..." list : D. You'll soon see where (in what software... but don't worry, it's free, you made a good deed).
EDIT:
I've been thinking about this and maybe it's perhaps when I declare the char[] before reading from that file, the char is initialized by C++ while when declaring it after reading from the file it is not? Hmmmmmm. Doesn't make much sense. Hrmph... whatever...
|
|
|
|
|
Axonn Echysttas wrote: ReadFile(hFile, cBuffer, sizeof(char)*256, &dwNumRead, NULL);
Try this:
ReadFile(hFile, cBuffer, sizeof(char)*256, &dwNumRead, NULL);
cBuffer[dwNumRead] = '\0';
strcpy(cTemp2,cBuffer); As mentioned elsewhere, ReadFile simply reads bytes from a file. It does not guarantee that a terminator is placed in the destination. The line I've added places a '\0' terminator after the data read, so that it's safe later on to perform the strcpy .
Software Zen: delete this;
|
|
|
|
|
While a char* is often called a "string" in C, they are not the same thing. A "string" is a specially-formatted array of chars. Taking the address of one single char doesn't make it a string.
|
|
|
|
|
Hello,
I want to map a particular partition into memory using CreateFileMappingA.
<br />
_dev = CreateFileA(<br />
"\\\\.\\Z:",<br />
GENERIC_ALL,<br />
0,<br />
NULL,<br />
OPEN_EXISTING,<br />
FILE_ATTRIBUTE_NORMAL,<br />
NULL<br />
);<br />
<br />
_devMap = CreateFileMappingA(<br />
_dev,<br />
NULL,<br />
PAGE_READONLY,<br />
0,<br />
0,<br />
NULL<br />
);<br />
<br />
Opening the driver with CreateFileA works fine,
but CreateFileMappingA returns NULL.
I get the error code 87 which is the following:
ERROR_INVALID_PARAMETER
87 The parameter is incorrect.
Since it's a 64bit application there shouldn't be any problems with
mapping large files into memory.
Thanks in advance.
|
|
|
|
|
I believe CreateFileMapping requires an actual file.
|
|
|
|
|
You are passing CreateFileMapping() a handle to something that is not a file, thus the invalid parameter message.
|
|
|
|
|
<emp>
<name>biswa</name>
<adress>marathahli</adress>
<id>9888</id>
</emp>
coding in vc++ but looks like above
biswajit nayak
|
|
|
|
|
Will you stop spamming the forums ?
If you want a decent answer, you first have to provide a decent question. I don't see any question at all in your message. It is just a piece of XML and one sentence.
And, BTW, somebody already gave you a correct answer if you want to do XML with C++ in one of your (too many) previous post.
|
|
|
|
|
Some people never learn. I just hope he doesn't get hired to implement an air traffic control system.
|
|
|
|
|
|
elephants
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt, 1997 ----- "...the staggering layers of obscenity in your statement make it a work of art on so many levels." - Jason Jystad, 10/26/2001
|
|
|
|
|
Hi,
I want to do magnification on my window. I set the window extension to doubled. When I draw one line, actually it draws a 2-pixel line on the window. If that line is around the border of the window, it is possible only 1-pixel shown up. Now, if I size the window, windows doesn't invalidate the other pixel of that line which it thinks it was already shown. In other words, windows only invalidate the area by logical coordinate, it doesn't know there are some pixels in that coordinate are missed and need to invalidate again. How do I work it around? Thanks a lot.
|
|
|
|
|
I'm not sure I'm following you but when you say "around the border of the window" are you referring to the edge of the client area? Or do you mean the edge of the window? And if so, inside or outside the window?
How are you scaling? MM_ANISOTROPIC, MM_ISOTROPIC, or some custom modification that synthesizes this effect?
Are you using a double-buffering, offscreen buffering technique (i.e. memDC)?
Are you drawing the line using GDI or GDI+? Are you performing Antialiasing?
Which function are you using to invalidate with?
|
|
|
|
|
Thanks for your help.
I use memory DC to draw some bitmaps on the client area and offset the viewport origins (if I scroll the window). The line is actually the part of the bitmap around the edge of the client area.
I didn't use any graphics techniques, just create a window and set mapping mode by SetMapMode(GetDC(hwnd), MM_ISOTROPIC), its extension by SetWindowExtEx(GetDC(hwnd), 100, 100, NULL) and SetViewportExtEx(GetDC(hwnd), 200, 200, NULL).
After resizing the window, I got WM_PAINT messages. I analyze the invalidate rectangles, then found this problem.
I use GDI, win32. Maybe no antialiasing. I'm not sure if it was double-buffering.
|
|
|
|
|
When you change the viewport and window extents, you will suffer from "off by one" errors. This is inherent in how non MM_TEXT mapping modes work and the algebra used for the metric translations. Those errors become evident when you apply offscreen buffering techniques such as described by Petzold, Jones, and in Keith Rule's article here on codeproject. His example claims to support MM_ANISOTROPIC but if you examine his source code, you will find he leaves the viewport and window extents at 1 which is effectively the same as MM_TEXT and when applied to the algebraic equations will not cause off by one errors. Obviously, MM_ANISOTROPIC and MM_ISOTROPIC would be useless if used without setting the extents as this is what provides the scaling. (By the way, that's not a bash on the authors as their code helps greatly, just a matter of factly statement)
If you are using a variant of one of the published authors memDC and using MM_ISOTROPIC, this is likely what you are suffering from or will find you are suffering from later.
One way to verify this is to turn on "Show windows contents while dragging" in the display properties/appearance tab/effects button. Drag the help/about box from your application over your client area in random paths and if it "smears" or "smudges" your drawings then you are suffering from this.
It basically involves the calculation of the clipping rectangle and the fact that there is a LPtoDP and a DPtoLP involved explicitly and indirectly by the windows API functions. If your familiar with the "pigeon hole principle" then you already understand the fact that a round trip could cause a loss of data. Hence the off by one error that leaves a single pixel width not refreshed on the edge of the clipping rectangle.
Some people never notice it because they have the "Show windows contents while dragging" turned off so as they resize the window or drag something over it, they only see a tracker rect and not the leftover non refreshed edges. I posted a reply in Keith's article linking to a helpful MSDN article that helped me realize how get past this (somebody didn't like my response there, got a 2 vote probably because I didn't post the code or something). In a nutshell, you need to calculate the rectangle that is used for the bitmap and the blit without any LPtoDP or DPtoLP round trips. here[^]
|
|
|
|
|
Thanks for your help. I think it was useful and I'll try it. And, I also made one mistake: I used OWN_DC style for my window(I feel shame for it). I guess that's why I usually got incorrect clipping rectangles, since they were already rounded by windows.
|
|
|
|
|
Hi All .
How is it possible to distinguish that the thread is in suspend mode or resume(running) ?
Thanks a'lot.
|
|
|
|
|
You'll need to keep track of that yourself.
It may help to take a look at the .NET Thread class ThreadState property and ThreadState
enumeration for hints on a way to track thread state.
Mark
"Posting a VB.NET question in the C++ forum will end in tears." Chris Maunder
|
|
|
|
|
First let me apologize that I did not keep good records about this.
My machine got invaded and I lost few things during the rebuild.
There is a registry key that integrates VC6.0 with VSS.
Could anybody send me this information, please.
It would save me reinstall time and further aggravation.
Thanks a lot Vaclav
|
|
|
|
|
Okay... I have embedded a manifest in my project:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
<assemblyIdentity
version="1.0.0.0"
processorArchitecture="X86"
name="Meh! Test"
type="win32"
/>
<description>Program Description</description>
<dependency>
<dependentAssembly>
<assemblyIdentity
type="win32"
name="Microsoft.Windows.Common-Controls"
version="6.0.0.0"
processorArchitecture="X86"
publicKeyToken="6595b64144ccf1df"
language="*"
/>
</dependentAssembly>
</dependency>
</assembly>
I have added as a resource:
CREATEPROCESS_MANIFEST_RESOURCE_ID RT_MANIFEST "Meh! Test.exe.manifest"
I have called InitCommonControlsEx for every ICC_x there could be:
INITCOMMONCONTROLSEX iex;
iex.dwSize = sizeof(INITCOMMONCONTROLSEX);
iex.dwICC = ICC_LISTVIEW_CLASSES|ICC_TREEVIEW_CLASSES|ICC_BAR_CLASSES|ICC_TAB_CLASSES|ICC_UPDOWN_CLASS|
ICC_PROGRESS_CLASS|ICC_HOTKEY_CLASS|ICC_ANIMATE_CLASS|ICC_WIN95_CLASSES|ICC_DATE_CLASSES|
ICC_USEREX_CLASSES|ICC_COOL_CLASSES|ICC_INTERNET_CLASSES|ICC_PAGESCROLLER_CLASS|
ICC_NATIVEFNTCTL_CLASS;
InitCommonControlsEx(&iex);
InitCommonControls();
But I still have the win95 edit control.
(All other common controls are styled correctly though)
Any help would be well apreciated...
PS: I am using Visual Studio C++ Express 2005 with Updates
PSS: Yes, I have included commctrl.h and 'commented in' comctl32.lib
|
|
|
|
|
You could maybe include the manifest as a separate file in the directory which your application is in - call it [your application name including .exe].manifest (for example, if your application was called test.exe, the manifest would be called test.exe.manifest). Also, when you say "all other common controls are styled correctly", have you tried all of the controls, because some controls (for example scroll bars) have the XP styles applied whether or not you use a manifest, so maybe the manifest resource hasn't loaded properly.
Hope this helps!
--PerspX
|
|
|
|
|