|
Heloo,
does anyone know what to put in the next instruction to stay the picture fixed in the text?
oShapes.AddPicture("c:\\FOTO.jpg", vtFalse, vtTrue, vtOptional, vtOptional, vtOptional, vtOptional, vtOptional);
Thanks.
Sebas
|
|
|
|
|
Hiya can someone tell me where I can get a free copy of Unix OS to mess around with my c++ programs??
Thanks.
|
|
|
|
|
|
Linux has been mentioned. Somewhat different but if you want to work in Windows, Microsoft now gives Services for Unix away free. It is a unix-like subsystem that runs under Windows.
|
|
|
|
|
|
Ok confused now. Is Linux a part of Unix or separate product?? I really wanted to learn Unix not Linux, and be able to run my c++ programs on unix.
This is basically the story. I want to learn Unix and its commands. When I say learn, I want a basic understanding of it and its commands.
How can I do this on my XP OS pc?? If I do a dual-boot system, does the other OS have to be on a completely separate drive??
What is the simpliest way to do this??
|
|
|
|
|
I have a problem. I have a project that include three form. I added an external header file (for example ****.h) in my project. When I add a picture box on one of the forms and select a picture for picture box, the compiler gives me an error "GetObjectA is not a member of System::ResourceManager::Resources" ( I think the error number is C2039 but I am not certain). I can't control this.
Please help me at least time.
turkish
|
|
|
|
|
Managed C++, #using and Windows header macros don't mix too well. The file you've included has redefined GetObject to GetObjectA, so when you try to use Resources::GetObject, the preprocessor rewrites GetObject to GetObjectA, which doesn't exist.
The preprocessor is basically dumb.
The culprit appears to be WinGDI.h, which is included from Windows.h. It may seem odd to have two different entry points for GetObject, since it doesn't take any string parameters, but this controls whether calling GetObject on a font object handle returns a LOGFONTA or a LOGFONTW (and hence whether the lfFaceName string is ANSI or Unicode).
About all you can do is find the call to Resources::GetObject, and either ensure that it occurs before WinGDI.h is included (not practical) or use #undef to undefine GetObject.
|
|
|
|
|
I am writing an MFC application. When I try to make a value variable and a control variable for the same edit box, they conflict with each other and neither one of them works. Is there a way around this such that I can have the two variables for the same edit box? Any help is appreciated.
-Dev578
|
|
|
|
|
|
Possible or not but i guess two member variables for one control doesnt sound good, you can even do away with the control member variable by using GetDlgItem(..)
"When death smiles at you, only thing you can do is smile back at it" - Russel Crowe (Gladiator)
|
|
|
|
|
Mr.Prakash wrote:
you can even do away with the control member variable by using GetDlgItem(..)
In fact, the control variables were introduced to hide the ugly and error prone GetDlgItem with its Long and capitalized resource name.
Repent, and return to the true path of usiing control variables 
"We trained hard, but it seemed that every time we were beginning to form up into teams we would be reorganised. I was to learn later in life that we tend to meet any new situation by reorganising: and a wonderful method it can be for creating the illusion of progress, while producing confusion, inefficiency and demoralisation."
-- Caius Petronius, Roman Consul, 66 A.D.
|
|
|
|
|
jhwurmbach wrote:
, the control variables were introduced to hide the ugly and error prone GetDlgItem
humm, never had any problem with it, but i agreee that GetDlgItem can not be always.
But i will certainly disagree to 2 member variables for a control.
"When death smiles at you, only thing you can do is smile back at it" - Russel Crowe (Gladiator)
|
|
|
|
|
Mr.Prakash wrote:
But i will certainly disagree to 2 member variables for a control.
I often use one menber of type CString and one of type CEdit for one control. As the CString gets filled by the utterly crappy DDX-mechanism of MFC, I tend not to rely on it.
For every more complicated dialog behaviour, you need to code by hand using the control variables anyway.
"We trained hard, but it seemed that every time we were beginning to form up into teams we would be reorganised. I was to learn later in life that we tend to meet any new situation by reorganising: and a wonderful method it can be for creating the illusion of progress, while producing confusion, inefficiency and demoralisation."
-- Caius Petronius, Roman Consul, 66 A.D.
|
|
|
|
|
Dev578 wrote:
Is there a way around this such that I can have the two variables for the same edit box?
Yes. The two variables must either be of a different category (i.e., value control), or you have to bypass ClassWizard and add the second one manually.
A rich person is not the one who has the most, but the one that needs the least.
|
|
|
|
|
Hi!
I just need to get the size of a file. The file is given by path (i.e: 'c:\thefile.txt'). I've been dealing with this for days, but I always bump into troubles.
May I ask someone to write me a very simple function, which queries the size of a file. That would show me how to get the size, and then I'd know what am I doing wrong. @win32/vc++ 6.0
Thx in forward.
|
|
|
|
|
The first arguments should be:
const char *path - the routine shouldn't be modifying the text.
const CString &path - Same thing again but also avoids an extra copy constructor.
const std::string &path - Same thing as with const CString &path.
Tim Smith
I'm going to patent thought. I have yet to see any prior art.
|
|
|
|
|
Off the top of my head.
if ((hFile = CreateFile (filePath, GENERIC_READ,FILE_SHARE_READ,NULL,OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL,(HANDLE)NULL)) == (HANDLE)(-1))
{
return 0;
}
DWORD dwFileSize = GetFileSize (hFile, NULL);
return dwFileSize;
Michael
But you know when the truth is told,
That you can get what you want or you can just get old,
Your're going to kick off before you even get halfway through.
When will you realise... Vienna waits for you? - "The Stranger," Billy Joel
|
|
|
|
|
There are various ways, but you probably want one of the following:
GetFileSize()
GetFileSizeEx() (For sizes larger than a DWORD value)
Anyone who thinks he has a better idea of what's good for people than people do is a swine.
- P.J. O'Rourke
|
|
|
|
|
thank you both for the help, anyway I've managed to figure it out myself, however due to a netsplit I couldn't access codeproject.com, I made a func almost similar you described.
btw. it's possible to get the size of a file with GetFileSize, as if it puts the high dword to the DWORD pointed by the second argument.
|
|
|
|
|
hi,
i read that a virus copies itself onto a exe/com file;some part in the front and some in the middle or back something like this.
file: FF
virus: VV
infected file: VFVF
with the first part of the virus taking care of the original exe/com running etc etc.
my question is --
how does it (virus) account for the extra file size on the disk.the os will have already a record of the different parts of the file according to its original conents.
then how can the infected file load correctly?
virus demolishacus
PS: sorry if this is off topic but this is a popular board with many people visiting!!
|
|
|
|
|
Anonymous wrote:
how does it (virus) account for the extra file size on the disk
Back in the DOS days, some viruses would have a memory-resident part that hooked various DOS calls (int 13 and/or int 21), and if a call was made to, say read or get the size of an infected file, the virus would modify the returned data to try and hide itself.
These days I doubt virus writers go to that much trouble, since no one keeps mental track of file sizes, and it wouldn't gain much.
--Mike--
Personal stuff:: Ericahist | Homepage
Shareware stuff:: 1ClickPicGrabber | RightClick-Encrypt
CP stuff:: CP SearchBar v2.0.2 | C++ Forum FAQ
You cannot stop me with paramecium alone!
|
|
|
|
|
yeah , back in dos times the virus wirters tried to make their code as small as possible or make it multiples of 100 so that they dont modifty the last 2 digits of the original file size as it would be very obvious that something has changed.
Now a days virus are about 20k compared to 1 or 2 kb in dos days.
"When death smiles at you, only thing you can do is smile back at it" - Russel Crowe (Gladiator)
|
|
|
|
|
Most viruses/works/trojan horses these days just replace a good with with an infected file. The OS looks for a program by filename only so svchost.exe (infected) and svchost.exe (clean) look the same, until the AV software kicks in.
A rich person is not the one who has the most, but the one that needs the least.
|
|
|
|
|
can you give me some code samples or good advice?
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
