|
does your failing .cpp file include all necessary .h files?
|
|
|
|
|
since it is a small tapi app so im including in MyClass.cpp
stdafx.h
tapi.h
if I include
MyProjDlg.h
I get error: C2065
|
|
|
|
|
overloaded Name wrote: I get error: C2065
then solve that. Not including a necessary header never is the solution.
|
|
|
|
|
Hi
how do i use XlTable format in DDE server application? to connect excel client.
Zo.Naderi-Iran
|
|
|
|
|
I am trying to create a simple to program to encrypt a file but I am having a lot of trouble with accessing the file. Firstly, whenever I try to access the file fstream's fail() always returns true.
If I take the check to fail() from my code it works fine encrypting the file but when I go to decrypt it there are artifacts in the file (2 extra bytes in my test file).
here is the code in question:
#define macro_encrypt (int) Byte + 25
#define macro_decrypt (int) Byte - 25
void fn_Decrypt()
{
char oldFilename[200];
char newFilename[200];
cout << "Enter Filename: ";
cin >> oldFilename; cout << endl;
cout << "Enter new Filename: ";
cin >> newFilename; cout << endl;
ifstream infile;
ofstream outfile;
char Byte;
infile.open(oldFilename, ios::in | ios::binary);
outfile.open(newFilename, ios::out | ios::binary);
while (!infile.eof())
{
char NewByte;
Byte = infile.get();
NewByte = macro_decrypt;
outfile.put(NewByte);
}
infile.close();
outfile.close();
fn_start();
}
I input a text file:
hello encryption
I get this (notepad output):
~……ˆ9~‡|‹’‰‚ˆ‡
And when I go to decrypt that file I get this:
hello encryptionÿæ
What makes this all the more frustrating is that when I compile the code this is based on it works fine. I can't see why it would work and mine won't, they are functionally identical (from what I can see).
Does anyone know why this is happening and/or how to fix it?
|
|
|
|
|
The artifacts are due to the way you're controlling the loop. Check what std::istream::get actually returns. Note that your cyphertext already has an extra character in it so your encrypt is part of the problem.
Just out of interest, as you're programming in C++ and not C:
- get rid of all the explicit opens/closes, you don't need them, destructors are wonderful things
- instead of letting a user crash your code by entering a filename of longer than 200 characters use std::strings and std::getline
- don't use macros, a pair of functions would have worked as well and enabled you to use the same code for encryption and decryption (the same goes for C BTW)
I'd also consider splitting the encrypt/decrypt bits of your code from all the guff asking for filenames, then you'd have something you can unit test without all the nuts ache of entering files all the time.
Cheers,
Ash
|
|
|
|
|
So a value declared int in C++.
Is signed.
However if I choose unsigned and assigned a negative value.
It should be zero.
Instead I get a large value, based on the most significant bit being 1 (representing the sign value).
And whatever was the original value being assigned is deducted from that value.
So -0, if nothing is to be deducted.
Someone should it be doing this?
|
|
|
|
|
C++ does no checking at runtime when doing automatic conversions. The bits from the signed int are simply crammed into the unsigned int. A negative integer has the high bit set so in the unsigned world it looks like a large number. If you set the warning level to 4, a good idea in general, with VC++ you'll get a signed/unsigned mismatch warning at compile time. You should look at all warnings to make sure you're not shooting yourself in the foot accidentally and fix them with proper casts, etc, so your compiles are totally clean. That will save you a lot of work in the long run looking for subtle bugs like the wrap around you're mentioning.
Once you agree to clans, tribes, governments...you've opted for socialism. The rest is just details.
|
|
|
|
|
Yes, it should most definitely be doing this!
What you are assigning to a variable is a bit pattern - not a value. Whether the variable is signed or not is a question of interpretation. Your interpretation! Assigning a negative constant to an unsigned variable is perfectly legitimate. As Tim Craig pointed out, you should trust your beloved and most obedient servant - the compiler. All compilers will warn you about signed/unsigned mismatch.
- turin
|
|
|
|
|
Just FYI, if you want to be sure that the author gets this message, reply to the author's post and you can refer to Craig's post, as you did in the text. The author didn't get the email, Tim Craig did.
|
|
|
|
|
Fareed Rizkalla wrote: It should be zero.
this requirement exists only in your mind.
C/C++ does not work that way
|
|
|
|
|
Hi all,
I am drawing a rectangle using LineTo(HDC hdc,x,y).
Now i planning to move or change the rectangle using mouse.
For example:If i click the mouse on the rectangle line,then i can drag the rectangle line using mouse.
Any idea will be helpful
Thanks
Raj
|
|
|
|
|
You need to capture the mouse co-ordinates as you drag and then use those values in your paint routine to redraw the rectangle either at a new position in your window or as a new size, depending on how your program is designed.
It's time for a new signature.
|
|
|
|
|
Firstly, you do not need to use LineTo to draw a rectangle.
Use the Rectangle function instead.
Secondly, you can achieve the same behavior using the CRectTracker class if you're using MFC.
|
|
|
|
|
Hi,
Thanks for your reply.The reason i used LineTo is.
I have to draw to a rectangle and rotate with the given degree.I found it hard with Rectangle function.
I am calculating the axis with the given degree and values first, and then drawing the lines with that axis to complete the rectangle.
Now i want is : If i click the mouse on any of the line on rectangle.Mouse has to ba activated so that i can move the line and resize the rectangle.'
I am confused ,how to start it.
thanks
Raj
|
|
|
|
|
hello guys...I have a strange problem. I wrote a function against a button but afterwards deleted it due to some reason in vc++.net. Now I get these errors.
error LNK2001: unresolved external symbol"public void __thiscall....."
fatal error LNK1120: unresolved externals
How do I remove them without making new app
|
|
|
|
|
The message is fairly clear, you are making a call in your code to a function whose name cannot be resolved at link time. Fix your code and rebuild.
It's time for a new signature.
|
|
|
|
|
I need more information, plast all error tip, what about the information follow "..._thiscall? "
I think maybe you delete your functions in cpp file, but you didn`t delete the declare in the *.h
maybe you declare the function as a normal function,but you implement it as call back function.
|
|
|
|
|
Carlos_never wrote: I think maybe you delete your functions in cpp file, but you didn`t delete the declare in the *.h
thanx...exactly this was the problem. I mistaken double clicked a control and then deleted it but did not know that we should delete it from the *.h file as well.
|
|
|
|
|
I am trying to access BITMAP bmBits and I can get the first member of the BYTE array.
Sort off, I am not sure if it is the real value of the color.
However, when I try to increment the pointer I get “unknown size of void*” error.
The bmBits member of BITMAP is declared (standard) as LPVOID and should point to array of bytes.The BITMAP structure was filled using
(HBITMAP)GetClipboardData(CF_BITMAP).
Could someone please explain to me what am I missing here and how to fix it.
This works:
BYTE bmp = (BYTE) pDoc->bitmap[iBITMAP].bmBits;
And this code gives me the void* error
bmpBYTE = (BYTE) pDoc->bitmap[iBITMAP].bmBits++;
Any constructive help is as always appreciated.
Thanks for reading,
Vaclav
|
|
|
|
|
A void pointer can be used to point to anything, but the compiler cannot calculate an increment size for it as there is no way of knowing what it will point to at run time. You just need to create a BYTE pointer to this array, cast the void pointer to it and use that to iterate through it thus:
PBYTE pBmBits = (PBYTE) pDoc->bitmap[iBITMAP].bmBits;
bmpBYTE = *pBmBits++;
...
It's time for a new signature.
|
|
|
|
|
Thank you for your explanation. Now I know more ( about casts) and therefore I am more dangerous to myself.
I guess in the case of BITMAP the LPVOID pointer could have been just char *
since it points to byte array anyway. But it makes it more challenging for weekend programmers like me.
Thanks again
Vaclav
|
|
|
|
|
Vaclav_Sal wrote: the LPVOID pointer could have been just char *
Yes but I think this is to allow a general structure which can contain a pointer to any format of bitmap in the future and not just a simple BYTE array.
It's time for a new signature.
|
|
|
|
|
what if you wanted to put this in to a bitfield. I have a bit map that has one bit per pixel and measures 7x70
|
|
|
|
|
Sorry, I'm not sure I understand your question.
I must get a clever new signature for 2011.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
